[jboss-jira] [JBoss JIRA] (AS7-6583) Performance regression comparing to previous release

[Tomas Remes (JIRA)]

    [ https://issues.jboss.org/browse/AS7-6583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12755956#comment-12755956 ] 

Tomas Remes edited comment on AS7-6583 at 2/22/13 6:45 AM:
-----------------------------------------------------------

I actually think that both could be helpful. Anyway check the mentioned commit once again and notice the really first change in LoggingExtension class (omitting import stuff) from ContextClassLoaderLogContextSelector to ClassLoaderLogContextSelector. These classes resides in org.jboss.logmanager (1.4.0.Final). Now look at the implementation of getLogContext method in both. I guess this method is the crucial one, because is called pretty often. IMHO the for cycle from this method from ClassLoaderLogContextSelector is the clue. You can also check that in attached jprofiler6 snapshots. For the good version I simply replaced method's implementation with the ContextClassLoaderLogContextSelector's one. The snapshots are taken locally and are corresponding to one Numberguess game. At the end some numbers (time is in microseconds):

||-||-||Total time||Invocations||Average time||
|old|org.jboss.logmanager.ClassLoaderLogContextSelector.getLogContext()|24638|1130|21|
|new|org.jboss.logmanager.ClassLoaderLogContextSelector.getLogContext()|424546|1082|392|

I am going to verify this once again in big load of 2000 sessions, but I am pretty sure.
                
      was (Author: tremes):
    I actually think that both could be helpful. Anyway check the mentioned commit once again and notice the really first change (omitting import stuff) from ContextClassLoaderLogContextSelector to ClassLoaderLogContextSelector. These classes resides in org.jboss.logmanager (1.4.0.Final). Now look at the implementation of getLogContext method in both. I guess this method is the crucial one, because is called pretty often. IMHO the for cycle from this method from ClassLoaderLogContextSelector is the clue. You can also check that in attached jprofiler6 snapshots. For the good version I simply replaced method's implementation with the ContextClassLoaderLogContextSelector's one. The snapshots are taken locally and are corresponding to one Numberguess game. At the end some numbers (time is in microseconds):

||-||-||Total time||Invocations||Average time||
|old|org.jboss.logmanager.ClassLoaderLogContextSelector.getLogContext()|24638|1130|21|
|new|org.jboss.logmanager.ClassLoaderLogContextSelector.getLogContext()|424546|1082|392|

I am going to verify this once again in big load of 2000 sessions, but I am pretty sure.
                  
> Performance regression comparing to previous release
> ----------------------------------------------------
>
>                 Key: AS7-6583
>                 URL: https://issues.jboss.org/browse/AS7-6583
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CDI / Weld, Logging
>    Affects Versions: 7.2.0.Alpha1
>         Environment: 7.2.0.Final (prerelease-1 tag) 
>            Reporter: Tomas Remes
>            Assignee: James Perkins
>            Priority: Critical
>              Labels: performance
>         Attachments: AS7-snapshot-good.jps, AS7-snapshot-wrong.jps
>
>
> There is significant performance regression in 7.2.0 prerelease. I discovered it in my Weld performance load tests (testing simple Weld numberguess example application), but I am quite sure that's not Weld issue at all. I did some investigations and it seems that problem occurred in org/jboss/as/logging module.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira