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