On Wed, Jan 7, 2009 at 11:28 PM, Hirsch, Richard <[email protected] > wrote:
> Once Daniel has composed the figures, I will blog about them on > blog.esme.us. > > Anyone got any problems with that? That a good thing. > > > D. > > ________________________________ > > From: Daniel Koller [mailto:[email protected]] > Sent: Thu 1/8/2009 08:21 > To: [email protected] > Subject: Re: Details from Stax Load test > > > > Good morning. > > I want to give you a short overview about the load test I did yesterday > evening: > > e...@stax was approached by up to nine parallel Java applications threads, > which used the REST api to logon, to post a message and then to logoff > again. This happens for each of the threads about 250-500 times. This test > is shown in the pic attached by Dick: it is the high level plateau shown at > process memory. I measured the time for each of the mentioned steps, and > also the total time for the call. > > I'll post facts and figures, when I compiled them and changed the test > scripts, but here are the first > Observations: > - We had the exceptions Dick mentioned, besides from these errors the > response times were on the same (good) level for a long time. > - Sometimes there are subsequent calls which take longer (about 3-5x), but > performance comes back to the previous level after short time. The reasons > for these longer function calls has to be investigated. (maybe related to > the mentioned Scala topics in Davids mail before) > - During earlier tests, I found that the performance of the ESME Web UI > goes > down under heavy REST load. > > Next steps: > - I will include in the test scripts a test step to simulate a call the the > Web UI (to get the complete picture of ESME performance) > - Yesterday I tested one user which is logging in over and over again, but > this user is not followed by anybody. Also the receiving messages step is > not tested. --> this means creation of a test script, which impersonates > more different users, which are also followed by a different number of > other > users. > - Also receiving messages hast to be incorporated into the test script. > > That's it for now, > > Daniel > > > > > > On Thu, Jan 8, 2009 at 6:32 AM, David Pollak > <[email protected]>wrote: > > > Dick, > > Tomcat is a less than optimal platform for high concurrent load. It does > > not have the same continuations mechanism that Jetty has. All my high > load > > tests are done on Jetty. With that being said, ESME's long polling for > the > > HTTP APIs does not take advantage of Jetty's continuations yet. That's > on > > my to-do list, but to date has not been a high priority. > > > > Another issue is that there's a problem with Scala Actors and memory in > > Scala 2.7.2. The Scala team is releasing Scala 2.7.3 this week or next > to > > cure the memory problems. > > > > Also, the continuations that Jetty currently supports are part of the > > Servlet 3.0 spec and should be part of NetWeaver this year. > > > > Thanks, > > > > David > > > > On Wed, Jan 7, 2009 at 8:54 PM, Hirsch, Richard > > <[email protected]>wrote: > > > > > Here are some details for a very first performance test on Stax for the > > > ESME server. Daniel tried with 1000 concurrent connections and then the > > > server started having some problems. Take a look at the enclosed stack > > trace > > > and you will see that towards the end there were problems with the > > threads. > > > I'm also enclosing a picture of the Stax performance indicators. I > don't > > > know the exact dimensions of the test but I'm sure Daniel will provide > > them > > > soon. > > > > > > Load tests are critical if we are to succeed in enterprises. They are > > also > > > critical when customers need sizing information. I assume that they > > should > > > also be useful for the lift framework. > > > > > > D. > > > > > > ________________________________ > > > > > > From: Spike Washburn [mailto:[email protected]] > > > Sent: Wed 1/7/2009 23:13 > > > To: Hirsch, Richard > > > Subject: Re: Stax account > > > > > > > > > The activity died back down for a bit, but then the app started sucking > > up > > > memory and CPU like it was stuck in a loop. When we checked the logs, > we > > > saw it was throwing out of memory exceptions. Since the app was > clearly > > in > > > a death spiral, we took a JVM stack dump and then restarted the app. I > > have > > > attached the last part of the appserver log if you want to review it. > > > > > > Also I noticed from the log that your app is getting warnings about > > > including the servlet-api-2.5.jar in WEB-INF/lib. This is not necessary > > > since the Servlet API classes are part of the classpath provided by the > > > appserver. > > > > > > Before your app died we were seeing upwards of 1000 concurrent > > connections > > > to your app. Please let me know if you were expecting this load or if > it > > > was some kind of external attack against your app. > > > > > > Thanks, > > > Spike > > > > > > > > > On Wed, Jan 7, 2009 at 1:09 PM, Spike Washburn <[email protected] > > > > > wrote: > > > > > > > > > Hi Dick, > > > > > > We just noticed a major spike in activity on your application > (id: > > > DickHirsch/esmecloudserver). I just wanted to check with you to see if > > you > > > were doing some load testing or if this was some kind of external > attack > > on > > > your webapp. > > > > > > Thanks, > > > Spike > > > > > > > > > > > > > > > > > > -- > > Lift, the simply functional web framework http://liftweb.net < > http://liftweb.net/> > > Collaborative Task Management http://much4.us <http://much4.us/> > > Follow me: http://twitter.com/dpp > > Git some: http://github.com/dpp > > > > > > -- > --- > Daniel Koller > Jahnstrasse 20 > 80469 München * [email protected] > > > -- Lift, the simply functional web framework http://liftweb.net Collaborative Task Management http://much4.us Follow me: http://twitter.com/dpp Git some: http://github.com/dpp
