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 > _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev