[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]
Re: [OT] load testing
This is application/context dependent. Ebay users may have a wait time of 2-20 seconds, where the low end results from scanning a page and dismissing it out of hand and the high end is the result of an auction with a REALLY long/detailed/funny description. Other web applications may have incredibly complex pages that result in a user parking on that page for 60-6000 seconds. What I suggest is that you convene a group of representative users (could be internal analysts and/or QA members) and record their use sessions. A little statstical analysis on the wait times should provide you with enough data to confidently randomize wait times. Dennis Nicolas De Loof [EMAIL PROTECTED] 06/23/2004 08:56 AM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To Struts Users Mailing List [EMAIL PROTECTED] cc 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]
RE: [OT] load testing
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]
Re: [OT] load testing
Thanks for replies, We are using Loadrunner to create load. As dennis suggested, I'm going to analyze wating time for a 'real' user to get an avarage request/second/user. Nico. 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] 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]
