I don't know the answer to your specific question, as I think it involves some industrial strength statistical math. But ... I'll tell you what we did.
Our application needed to be load tested to ensure performance within certain times at up to 50 users. (We actually tested to 100 users, just for grins ... load testing is fun :-) We created a functional test using HttpUnit and JUnit to represent our primary usecase. Ours is a control system and this usecase was time critical, while the other usecases were deemed not time critical, so we just load tested with the one usecase. Then, using JUnitPerf, by the wonderful and talented Mike Clark (http://www.clarkware.com/), we drove the test at up to 100 simultaneous users, each running a number of the functional tests back to back (25 to 50 times per simulated user). This created a worse case load test (think slashdot effect :-). Personally, I liked this, as I wanted to know when the application would run out out of steam. Obviously this test is unrealistic, but it did give us plenty of confidence that we could handle anything that was expected to be thrown at us. So, in your situation, I would create functional tests that represented the most common and most time critical usecases for your system. Then open the flood gates and send a tidal wave of traffic against the system. I'm sure that realistically simulated usage is wonderful, but for the rest of us, just hammer the system until it begs for mercy and then you'll know what it can take. :-) Simon >-----Original Message----- >From: Nicolas De Loof [mailto:[EMAIL PROTECTED] >Sent: Wednesday, June 23, 2004 7:57 AM >To: Struts Users Mailing List >Subject: [OT] load testing > > > >Hi all, > >I've to make some load tests on my app. > >Our customer wants the appli to handle "300 simultaneous >users". To translate this requirement into request per second, >how many time do you consider an 'active web user' to wait >between 2 request ? > >Nico. > > > >Our name has changed. Please update your address book to the >following format: "[EMAIL PROTECTED]". > >This message contains information that may be privileged or >confidential and is the property of the Capgemini Group. It is >intended only for the person to whom it is addressed. If you >are not the intended recipient, you are not authorized to >read, print, retain, copy, disseminate, distribute, or use >this message or any part thereof. If you receive this message >in error, please notify the sender immediately and delete all >copies of this message. > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
