[
https://jira.jboss.org/jira/browse/JBSEAM-3712?page=com.atlassian.jira.pl...
]
Jay Balunas commented on JBSEAM-3712:
-------------------------------------
I have narrowed down the issue to r9196 <
http://fisheye.jboss.org/changelog/Seam/?cs=9196 > this is a wiki specific change to
the WikiPluginMacro.java class
The good news is that this is most likely a wiki specific issue and not an issue with seam
core. The bad new is that is may be effecting the wiki application now, plus all the time
wasted on this issue.
The wiki code needs to be profiled specifically for this to determine the root cause - my
guess is excessive CPU cycles in the equals() and hashcode() but I am not sure (and they
don't look bad). I'll ping Christian on this and see what he thinks.
However, what I really think needs to happen first is that we need to setup the dvdstore
example for perf/load testing as discussed this morning. This will provide an easier way
for dev and users to run the same tests, and will provide a second performance benchmark
to avoid this type of issue in the future.
I'll wait until Shane or Christian gets a chance to look at this issue before
resolving.
Seam performance regression from 2.1.0.SP1 to 2.1.1.CR1
-------------------------------------------------------
Key: JBSEAM-3712
URL:
https://jira.jboss.org/jira/browse/JBSEAM-3712
Project: Seam
Issue Type: Bug
Components: Core, Platform interoperability
Affects Versions: 2.1.0.SP1
Environment: Fedora 8
JDK 5
Reporter: Jay Balunas
Assignee: Shane Bryzak
Priority: Blocker
Fix For: 2.1.1.CR2
Attachments: Test Plan.jmx
Working with the latest trunk (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. 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.
-----------------------------------
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/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.
-----------------------------------
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira