[ https://issues.jboss.org/browse/AS7-3371?page=com.atlassian.jira.plugin.s... ] Tomas Remes commented on AS7-3371: ---------------------------------- Well first worsening occurs after increasing JBoss Web version from 7.0.4.Final to 7.0.5.Final. After that stress test gets down from 4100 sessions to just 2500. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3371?page=com.atlassian.jira.plugin.s... ] Tomas Remes commented on AS7-3371: ---------------------------------- This test is sending http requests to the simple Weld web application called "Numberguess" and validating its responses. The "Numberguess" application is available (in its basic form) at https://github.com/weld/core/tree/master/examples/jsf/numberguess. In this stress test we added some next Weld functionality (Interceptors, Decorators, Alternatives, Qualifiers, Bean scopes) to the example. Maybe I am wrong, but I still don't think it is the Weld issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3371?page=com.atlassian.jira.plugin.s... ] Stuart Douglas commented on AS7-3371: ------------------------------------- Without more info and profiling results from both runs there is not really anything I can do with this. Nothing has changed in weld so I really doubt that this is the issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3371?page=com.atlassian.jira.plugin.s... ] Jason Greene commented on AS7-3371: ----------------------------------- Tomas, Can you try setting native="false" in the web config? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3371?page=com.atlassian.jira.plugin.s... ] Remy Maucherat commented on AS7-3371: ------------------------------------- I know you guys are afraid of native (esp Andrig), but this is not going to be the problem. OTOH, between 7.0.4 and 7.0.5, I rebased on Tomcat 7 EL (which had improvements, since there are some expressions I didn't handle well, lots of needed updates, etc), which is a more likely source of problems that would be specific to JSF. The bad news is that I'll have problems doing much about it, unless it's something obvious that can be fixed (waiting for more info). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3371?page=com.atlassian.jira.plugin.s... ] Jason Greene commented on AS7-3371: ----------------------------------- The reason I suggested it is because it is one of the largest variables between the two versions. If nothing else it will eliminate some kind of bug in our APR usage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3371?page=com.atlassian.jira.plugin.s... ] Jason Greene commented on AS7-3371: ----------------------------------- Tomas just pinged me on IRC: tremes: jgreene: ok. without these native libs is performance of that stresstest back to 2500 sessions from 900 sessions. I'll comment on the issue. tremes: jgreene: but there is still something wrong, because Beta1 did 4100 So half of the perf degradation is the switch to native by default. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3371?page=com.atlassian.jira.plugin.s... ] Jason Greene commented on AS7-3371: ----------------------------------- Yeah ideally the stress test would be testing at a range of load levels instead of just picking one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3371?page=com.atlassian.jira.plugin.s... ] Remy Maucherat edited comment on AS7-3371 at 1/26/12 7:51 AM: -------------------------------------------------------------- The test is having too much concurrency and not enough idling. Adding some would be useful, but that's probably not the point here (test basic raw performance, no need to be realistic). The default thread pool rejects requests when it's out of threads (128 here). So I'd recommend a thread pool with a queue to be able to use native with the test (increasing the thread count too much wouldn't be good, but it could be higher than 128 for sure, up to 256 or 512 would do fine probably). Alternately, the default internal pool can be configured to block until a thread is available by setting the "org.apache.tomcat.util.net.WAIT_FOR_THREAD" system property to "true". was (Author: rmaucher): The test is having too much concurrency and not enough idling. Adding some would be useful, but that's probably not the point here (test basic raw performance, no need to be realistic). The default thread pool rejects requests when it's out of threads (128 here). So I'd recommend a thread pool with a queue to be able to use native with the test (increasing the thread count too much wouldn't be good, but it could be higher than 128 for sure, up to 256 or 512 would do fine probably). Maybe it's a concurrency thing in the Tomcat EL impl and the huge amount of concurrency the test is using isn't helping. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3371?page=com.atlassian.jira.plugin.s... ] Andrig Miller commented on AS7-3371: ------------------------------------ Tomas, since you set the WAIT_FOR_THREAD to true, now try making the thread pool larger. If its waiting for a thread to process its request, then that wait time is affecting the throughput. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3371?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-3371: ---------------------------------- Component/s: Web -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3371?page=com.atlassian.jira.plugin.s... ] Remy Maucherat commented on AS7-3371: ------------------------------------- So the regression is real in your micro benchmark, but is caused by the more compliant EL code that I pulled from Tomcat. Not something I can really do something about. I am switching the default for identifier checking to false, which should be in 7.1.1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3371?page=com.atlassian.jira.plugin.s... ] Remy Maucherat commented on AS7-3371: ------------------------------------- This doesn't look like real performance (peaks at 1800req/s) but rather queueing requests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3371?page=com.atlassian.jira.plugin.s... ] Jason Greene updated AS7-3371: ------------------------------ Fix Version/s: 7.1.1.Final (was: 7.1.0.Final) This is going to require more investigation/research, so I am rescheduling to 7.1.1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3371?page=com.atlassian.jira.plugin.s... ] Remy Maucherat edited comment on AS7-3371 at 2/7/12 9:56 AM: ------------------------------------------------------------- I consider the issue fixed after dropping the identifier check by default in 7.1.0 (a not very useful functionality), unless you find something more specific. Scalability in this sort of test is going to be up to the thread pool settings for the most part. As I also said, a regression is to be expected in EL method invocation after the rebase on the Tomcat code, since it checks a lot more than simply the method name (which was of course faster, but isn't quite the right thing to do). was (Author: rmaucher): I consider the issue fixed after dropping the identifier check by default (a not very useful functionality), unless you find something more specific. Scalability in this sort of test is going to be up to the thread pool settings for the most part. As I also said, a regression is to be expected in EL method invocation after the rebase on the Tomcat code, since it checks a lot more than simply the method name (which was of course faster, but isn't quite the right thing to do). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira