[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-3712) Seam performance regression from 2.1.0.SP1 to 2.1.1.CR1

[Jay Balunas (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBSEAM-3712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12440818#action_12440818 ] 

Jay Balunas commented on JBSEAM-3712:
-------------------------------------

The profiler was of very limited use (can't unfilter java.lang.Object to see when hashCode is called), and to be honest it is not going to tell us anything we do not already know.  The hashCode() method and the super.hashCode() method needs to be optimized - probably through caching the inner hashcode calls since some of the values called within do not appear to change.  Below are the two hashcode methods.  I'll try out some different caching approaches tomorrow morning and see how this affects the perf.

However for this release I do believe that this is blocker, and I'll move it down.  If the fix ( I'll try tomorrow ) is safe and easy we can get it in, otherwise we'll have to wait.  

WikiPluginMacro hashCode:
@Override
    public int hashCode() {
        int result = super.hashCode();
        result = 31 * result + uniqueId.hashCode();
        return result;
    }

WikiTextMacro hashCode (the super of ^^^)
public int hashCode() {
        int result;
        result = (position != null ? position.hashCode() : 0);
        result = 31 * result + name.hashCode();
        return result;
    }


> 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/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.
> -----------------------------------

-- 
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