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

[Jay Balunas]

Yes when run under load (25 users) the system seems to becomes
unresponsive.  The requests do eventually return - jmeter was reporting an
average request time of 100+ seconds.   When accessed during the warm up
requests (my manual requests to prime the application) the application
functioned just fine.

-Jay

On Wed, Nov 12, 2008 at 8:20 PM, Shane Bryzak <shane.bryzak at jboss.com>wrote:

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


-- 
blog: http://in.relation.to/Bloggers/Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20081112/04f159f6/attachment.html