esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Pollak <>
Subject Re: First mass user tests results
Date Tue, 17 Nov 2009 21:36:03 GMT

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.



On Tue, Nov 17, 2009 at 1:25 PM, Markus Kohler <>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
Beginning Scala
Follow me:
Surf the harmonics

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message