Hi Andrey,
Thank you for offering your help. I am not sure how easy it is going to be to change the Stepping Thread Group. But still am mentioning my idea of how it can be augmented to add more flexibility. The Stepping Thread Group style that I tried is in the screenshot below. [cid:[email protected]] You will notice that the 100 user ramp-up is immediate at each step in the image below. It ideally should be a slow ramp-up of each group, so that the server is not overwhelmed at the sudden 100 user jump, and then allow some hold period when the server is allowed to stabilize at that load. During this stabilizing hold period we can see how the server behaves at that load. And then the next set of users are added slowly for the next user load level. We continue this stepped rampup until the server breaks at a certain threshold load level. I have added a few hours of stabilizing period after each ramp up, where I will try and monitor the server behavior at that level. Instead of the single row ramp-up parameters, I would prefer something like a grid entry mode, so that multiple lines can be added as required. -This group will start [500] threads: ----First wait for [15] seconds, --------Then, Start [100] threads, Ramping-up Over [600] seconds, Hold load for [3600] seconds (at 100 users test for 1 hrs) --------Then, Start [100] threads, Ramping-up Over [900] seconds, Hold Load for [7200] seconds (at 200 users test for 2 hrs) --------Then, Start [100] threads, Ramping-up Over [1200] seconds, Hold Load for [7200] seconds (at 300 users test for 2 hrs) --------Then, Start [100] threads, Ramping-up Over [1500] seconds, Hold Load for [10800] seconds (at 400 users test for 3 hrs) --------Then, Start [100] threads, Ramping-up Over [1800] seconds, Hold Load for [14400] seconds....(at 500 users test for 4 hrs) --------<<ADD MORE ROWS BUTTON>> ----Then work for 14400 seconds, <<this can be removed, as the previous row would mention the execution period>> -Finally, stop [10] threads every [20] seconds. So I am first adding 100 users over 10 mins, then observing the server for 1 hour, then add another 100 users over 15 mins, then again observing the server for 2 hours at the 200 user load, then adding another 100 users over 20 mins. Notice that the rampup time of subsequent steps is slower as the server is under more user load at that point, so I am allowing for a slower load increase mode. Also at higher load levels, we will require more stabilizing time for the server. Regards, Sudip Kumar Bhattacharya -----Original Message----- From: Andrey Pohilko [mailto:[email protected]] Sent: Tuesday, May 18, 2010 5:11 PM To: 'JMeter Users List' Subject: RE: How to achieve controlled ramp-up of users? Hi, Sudip! How can I improve Stepping Thread Group to meet your requirements? С уважением, Андрей Похилько -----Original Message----- From: Bhattacharya, Sudip [mailto:[email protected]] Sent: Tuesday, May 18, 2010 3:13 PM To: JMeter Users List Subject: How to achieve controlled ramp-up of users? Hi Friends, Please tell me if this is possible in JMeter or not. I have a test plan like this: +Thread Group 1: ++Components + Thread Group 2 ++Components +Thread Group 3 ++ Components +Thread Group 4 ++Components +Thread Group 5 ++Components Each thread group has 100 unique users which will be picked from a separate CSV file per thread group. I want to start off the plan with only 20 users in each thread group, so that a total of 100 users are emulated, distributed evenly over the 5 use case thread groups. If the server is able to handle the load for 1 hour, I want to add 20 more users per TG, so that the total user count goes to 200. This way, I want to increase the users by 100 for each step, see if the server can handle the load for 1-2 hours, and if it can hold, increase it by another 100 users, until the server breaks. I have seen in LoadRunner that you can increase the users manually in between a test, and pause the ramp-up dynamically if required. Is this possible in JMeter? I tried the Stepping Thread Group, but it is limited in what it offers. ______________________________ Sudip Kumar Bhattacharya This e-mail (and any attachments), is confidential and may be privileged. It may be read, copied and used only by intended recipients. Unauthorized access to this e-mail (or attachments) and disclosure or copying of its contents or any action taken in reliance on it is unlawful. Unintended recipients must notify the sender immediately by e-mail/phone & delete it from their system without making any copies or disclosing it to a third person. --------------------------------------------------------------------- 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] This e-mail (and any attachments), is confidential and may be privileged. It may be read, copied and used only by intended recipients. Unauthorized access to this e-mail (or attachments) and disclosure or copying of its contents or any action taken in reliance on it is unlawful. Unintended recipients must notify the sender immediately by e-mail/phone & delete it from their system without making any copies or disclosing it to a third person.
