Re: [seam-dev] Performance Review of current Seam trunk fo 2.1.1

Thanks Jay, Just to be clear, did you mean that each individual request is now taking 100+ seconds as compared to 3 seconds previously? Jay Balunas wrote: > Performance Review of current Seam trunk fo 2.1.1 > -------------------------------------------------------- > > Working with the latest trunk from today (r9557) and testing the > performance changes that were made. Previous tests were done with (r9017). > Just as a refresher my baseline test uses the wiki example with all of the > sfwk.org <http://sfwk.org> data up to July 31st 2008. > For these tests I use JBoss AS 4.2.3 with JDK5 on my linux machine. > Jmeter is used to load test and calculate the results and graphs. I then > use JProfiler to to identify either blocking threads, call graphs, and CPU > usage. > Unfortunately the results were not good. I was using a mixture of 25 and > 50 users - hitting the server 25 times each. As before they were accessing > the first page of the user forum. > > With r9017 the 25 user x 25 requests averaged 3 seconds a request. With > trunk they were 100+ seconds. Thinking something was wrong with the system > I replaced the 9557 wiki.war with the 9017 and reran with all other > variables the same. Again the 9017 saw about 3 seconds for the average over > the 625 requests. > > I then profiled the server under load as I did before. The methods below > appear to be the primary offenders although as with most blocking threads > there are some others waiting on the same monitor. I'll follow up this > email with the stack traces, and more information from my investigation. > > ----------------------------------- > 1) com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate.findLock(..) > - This appears to be the biggest issue. Every requests are generating > many of these calls. > - > http://viewvc.jboss.org/cgi-bin/viewvc.cgi/labs/labs/jbosstm/branches/JBO... > - It looks like every interaction with any transaction causing > synchronization issues with this call. > - We'll need to find a way to limit these calls. > - I'm guessing some of the changes made for JBSEAM-3519 may be the cause > although I have not had time to look deeper. > - See : > http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/transa... > http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/transa... > > > > http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/util/W... > http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/util/W... > > > ----------------------------------- > 2) org.jboss.naming.ENCFactory.getObjectInstance() > javax.naming.Context.lookup(java.lang.String) > > This appears to be the second biggest offender and it looks like we are > no longer blocking on retrieving the InitialContext, but now blocking on > performing the lookups using the context. > ----------------------------------- > 3) > org.jboss.resource.connectionmanager.CachedConnectionManager.unregisterConnection() > > org.jboss.resource.connectionmanager.CachedConnectionManager.registerConnection() > > This is the third biggest issue, but much less than the others. 1 or 2 > dozen blocks on 60 requests. These are all related to hibernate calls and > database access from what I've seen so far. > ----------------------------------- > I'll follow up this email tomorrow with the typical stack traces seen for > each of these. > > Shane could you review, and I'll get more information on these tomorrow. > Thanks, > -Jay > > -- > blog: http://in.relation.to/Bloggers/Jay > ------------------------------------------------------------------------ > > _______________________________________________ > seam-dev mailing list > seam-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > >