On Tue, Nov 17, 2009 at 7:36 PM, Richard Hirsch <[email protected]>wrote:
> @Markus: > > Thanks a lot for performing these tests. They are really important for > ESME. > > I have created a wiki page for performance tests: ( > http://cwiki.apache.org/confluence/display/ESME/Performance+tests > ).Take a look at it and tell me what I'm missing > > Send me the attachments to my gmail account and I will post them to > the ESME wiki. For some reason attachments are never included when > submitting to esme-dev list. > > For your new tests on stax, you could always use the old snapshot of > the DB on stax. This would allow you to recreate the db from this > initial tests. > > Once we have decent performance with the existing one-machine > environment on stax (which we currently share with other applications > in the stax environment, we could move to a dedicated server in the > amazon cloud or even try more than one server. > > @David: I'll do a new deplyoment on stax this morning. > You might want to hold out for a little time... there's nasty just floating around in Lift. > > D. > > > On Tue, Nov 17, 2009 at 10:44 PM, Markus Kohler <[email protected]> > wrote: > > Hi, > > If Richard deploys the latest version, it's no problem to repeat the > test. > > Anyone can see the png's? They show up normally in my gmail. > > Regards, > > Markus > > > > On Tue, Nov 17, 2009 at 10:36 PM, David Pollak < > > [email protected]> wrote: > > > >> Markus, > >> > >> Interesting information. > >> > >> I found a bug in the Lift Actors (fix checked into master this morning) > >> where the Actor thread pool would grow unbounded. Given the amount of > >> message passing in ESME, I think threads were being created rather > queuing > >> messages. I'd be interested to see if a build of ESME made with the > >> current > >> SNAPSHOT of Lift exhibits the same thread explosion issue. > >> > >> Also, I don't think the attachments made it through. > >> > >> Thanks, > >> > >> David > >> > >> On Tue, Nov 17, 2009 at 1:25 PM, Markus Kohler <[email protected] > >> >wrote: > >> > >> > Hi all, > >> > Yesterday night I finally got some tests running. > >> > I still focused on single threaded (serial) tests using Selenium RC > Java > >> to > >> > control one firefox browser. > >> > *Test 1, Creating Users* > >> > The first test would create the 300+x users, using a CSV file I > generated > >> > from my twitter followers. The test script enters User data including > the > >> > url for the avatar and then logs out. Basically that means that during > >> the > >> > test only one user is logged on at any given point in time. Sorry > didn't > >> > make any screenshots of the Stax monitor. Learned in the meantime this > >> would > >> > have been a good idea. > >> > The number of threads went up to 130, which I find surprising, given > >> that > >> > there were no users on the system in parallel. > >> > > >> > *Test2, Logon each user* > >> > In the second test I logon each user and do not logout afterwards. The > >> idea > >> > was to see what the memory overhead of one user is. I achieved this > with > >> > one browser by clearing the cookies after the user has logged on. > >> > The memory_allUsers attachment shows that the number of threads > increased > >> > dramatically beyond 1000. > >> > > >> > The memory also went up, but this is not at all an issue atm. Compared > to > >> > what I've seen so far at Enterprise apps it's very low! > >> > > >> > After the test was run, I tried with one browser whether everything > would > >> > work still fine. This caused an unexpected behavior of the server. See > >> > cpu_allUsers and memory_allUsers2 attachments. > >> > The system load went up dramatically and stayed there for while. When > >> > entering a message, this message would appear only very slowly or not > all > >> in > >> > the users timeline. The number of threads would go down after a while, > >> but > >> > there was a second peak.Not sure where it came from. > >> > > >> > What's also interesting is that the number of classes grew overtime. > >> > I would assume that full GC's where running so they should have been > >> > reclaimed, if they would have been only of temporary nature. > >> > > >> > Note that Stax seems to run on Tomcat 6 without the async/Comet > support > >> of > >> > the Servlet 3.0 API. > >> > The will wait for 7.0 to support that. > >> > > >> > As soon as I have some time, I will rerun the test on my local > machine, > >> > where I have more tools to check what is going on. > >> > I will also first run it on Jetty to see whether it performs better. > >> > > >> > Still I would assume that NW CE will show the same issues and sooner > or > >> > later we will have to figure out the root cause. > >> > > >> > > >> > Greetings, > >> > Markus > >> > > >> > > >> > > >> > > >> > > >> > > >> > >> > >> -- > >> Lift, the simply functional web framework http://liftweb.net > >> Beginning Scala http://www.apress.com/book/view/1430219890 > >> Follow me: http://twitter.com/dpp > >> Surf the harmonics > >> > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics
