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

Jay Balunas tech4j at gmail.com
Wed Nov 12 20:00:21 EST 2008


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 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/JBOSSTS_4_2_3_GA_SP/atsintegration/classes/com/arjuna/ats/jbossatx/jta/TransactionManagerDelegate.java?view=markup

  - 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/transaction/TransactionInterceptor.java?r1=8626&r2=9552&u=-1&ignore=&k=

http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/util/Work.java?r1=9221&r2=9550&u=-1&ignore=&k=
-----------------------------------
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20081112/1ad06715/attachment.html 


More information about the seam-dev mailing list