Hello Jan,
Hmm, it might be still fine ... or not depending on the remaining 10% ... I'd say this setting is pretty much on the edge. Can you try what happens with 1000 tomcat threads without changing any other parameters of the test? --------- Even if I put 1600 tomcat threads it doesn't make any difference. Actually I'm able to hang tomcat with 500 concurrent threads having 800 threads set in tomcat. Seems like 450 concurrent users is a sort of magic figure: magnolia is able to handle less than 450, but hangs when its 500. Will try to download JBoss and deploy Magnolia there. Regards, Denis On Mon, Oct 5, 2009 at 10:42 AM, Jan Haderka <[email protected]>wrote: > > Cool. Thanks for info. > > On Mon, 2009-10-05 at 10:15 -0400, Denis Demichev wrote: > > Hello Jan, > > > > I really appreciate your prompt reply. let me answer some of the > > questions below. > > - Deadlock: I was thinking about this (race condition?) as well. Not > > sure how exactly I would verify if that theory is correct > > If it was a deadlock it would occur rather randomly and with not > necessary correlation to the amount of threads, apart from growing > likelihood for it to occur, but not changing the timings. So if you can > run 10 times with 800 threads and each time it blocks in approx same > time, it is flooding of the queue rather then classic deadlock which > would be more random. > > > Stress test was performed on a public instance against STK project > > pages in a loop: > > /magnoliaPublic/demo-project.html > > /magnoliaPublic/demo-project/about.html > > /magnoliaPublic/demo-project/news-and-events.html > > /magnoliaPublic/demo-project/multimedia.html > > /magnoliaPublic/demo-project/service.html > > all of the above will be cached and being relatively small, they will be > served from the in-memory cache. If you run the test with those only, > only very tiny bit of Magnolia will be still busy (all filters up to > cache filter) but there will be minimal access to the repository. > > > /magnoliaPublic/demo-project/service/search-result.html?queryStr=preceded > > This one will be never cached so that is the only page that will hit the > repo each time, even with cache enabled (default settings). > > > All of them have Gaussian Timeout set to 1000ms offset and 1500ms > > deviation. > > 90% responses are in 954ms, that's why I chose 800 threads to handle > > requests. > > Hmm, it might be still fine ... or not depending on the remaining > 10% ... I'd say this setting is pretty much on the edge. Can you try > what happens with 1000 tomcat threads without changing any other > parameters of the test? > > > - Was content cached? I assume yes, because SQL Admin showed no > > activity during the test - all MySQL connections were idle for a while > > at the moment. > answered above. > > > - I had another application deployed and its not responding during > > that "stall" period. > > That suggests Tomcat queue being flooded rather then anything else. Are > you in position to repeat the same on JBoss and/or Glassfish? > > > But if I deploy that application to tomcat separately (or I can use > > tomcat's JSP samples) the Tomcat instance will handle up to 1000 > > threads with 80% of CPU load. > > This really depends on underlying load ... it involves some processing > to have content stored and served from JCR repository so that doesn't > really mean anything. > > > - I tried with regular GC and other versions (_13, 32-bit) of JDK with > > no success. > > Good to know. Thanks. > > Jan > > > ---------------------------------------------------------------- > For list details see > http://www.magnolia-cms.com/home/community/mailing-lists.html > To unsubscribe, E-mail to: <[email protected]> > ---------------------------------------------------------------- > > ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
