What does Startup Time and Shutdown Time indicates in the Thread group???

Hi,

It means one group will take N1 seconds to start the threads group and N2 seconds to stop it. So in the first line of this sample, the first group of 100 threads will take 10 seconds to start (ie 10 threads per seconds) and 5 seconds to stop all threads (ie 20 threads per second)

Thanks Stephane for such a nice and detailed explanation. Following is my understanding from your post: Startup Time ~ Ramp Up Time i.e Amount of time in which all the VU's(Virtual users) or Threads got ramped up successfully to the server

Shutdown Time ~ Ramp Down Time i.e. Amount of time in which all VU's (Virtual users) or Threads gets ramped down.

Please correct me if I misunderstood anything. Thanks. :)

Yes you got it.

Thanks again..!! :). And 'HOLD LOAD FOR Sec' field is the amount of time for whcih load will sustain continously on the server ryt..?? Is it also gets divided by no. of threads..? means.. as in above e.g you entered 60 sec under 'Hold load field' and threads count is 100, so will the time be 60 or 100/60..? Well I suppose it shiuld be 60 only...!!! But still can you please confirm this...??

Hi,

No, hold load for sec means the 100 started thread (vuser) will execute the scenario during N seconds. EG. If the scenarion is 'login > navigate to page X > logout' the 100 threads will loop in this scenario during N seconds.

Many Thanks Stephane..!! :) You really explains the things very well...!! I have sent you the request on gmail as well...!!

Hi Stephane,

Do you have any idea on how to test perl,shell scripts using Jmeter.?? Thanks.

Hi, I never tried this.

ok...!!

Hi, May be my understanding of this is not correct but here is what I was trying I configured 10 rows expecting them to send 550 requests in 100 seconds as each of my thread is sending only 1 request but I noticed that there were 28141 requests sent out here is the jmx i am using.

 <?xml version="1.0" encoding="UTF-8"?> <jmeterTestPlan version="1.2" properties="2.1">

<hashTree>
<TestPlan guiclass="TestPlanGui" testclass="TestPlan" testname="Test Plan" enabled="true">
<stringProp name="TestPlan.comments"></stringProp> <boolProp name="TestPlan.functional_mode">false</boolProp> <boolProp name="TestPlan.serialize_threadgroups">true</boolProp> <elementProp name="TestPlan.user_defined_variables" elementType="Arguments" guiclass="ArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true">
<collectionProp name="Arguments.arguments"/>
</elementProp> <stringProp name="TestPlan.user_define_classpath"></stringProp>
</TestPlan> <hashTree>
<kg.apc.jmeter.threads.UltimateThreadGroup guiclass="kg.apc.jmeter.threads.UltimateThreadGroupGui?" testclass="kg.apc.jmeter.threads.UltimateThreadGroup" testname="testScheduler" enabled="true">
<collectionProp name="ultimatethreadgroupdata">
<collectionProp name="15743845">
<stringProp name="10">10</stringProp> <stringProp name="20">20</stringProp> <stringProp name="30">30</stringProp> <stringProp name="40">40</stringProp> <stringProp name="50">50</stringProp> <stringProp name="60">60</stringProp> <stringProp name="70">70</stringProp> <stringProp name="80">80</stringProp> <stringProp name="90">90</stringProp> <stringProp name="100">100</stringProp>
</collectionProp> <collectionProp name="1002355779">
<stringProp name="0">0</stringProp> <stringProp name="10">10</stringProp> <stringProp name="20">20</stringProp> <stringProp name="30">30</stringProp> <stringProp name="40">40</stringProp> <stringProp name="50">50</stringProp> <stringProp name="60">60</stringProp> <stringProp name="70">70</stringProp> <stringProp name="80">80</stringProp> <stringProp name="90">90</stringProp>
</collectionProp> <collectionProp name="-1117719391">
<stringProp name="10">10</stringProp> <stringProp name="10">10</stringProp> <stringProp name="10">10</stringProp> <stringProp name="10">10</stringProp> <stringProp name="10">10</stringProp> <stringProp name="10">10</stringProp> <stringProp name="10">10</stringProp> <stringProp name="10">10</stringProp> <stringProp name="10">10</stringProp> <stringProp name="10">10</stringProp>
</collectionProp> <collectionProp name="1751132257">
<stringProp name="0">0</stringProp> <stringProp name="0">0</stringProp> <stringProp name="0">0</stringProp> <stringProp name="0">0</stringProp> <stringProp name="0">0</stringProp> <stringProp name="0">0</stringProp> <stringProp name="0">0</stringProp> <stringProp name="0">0</stringProp> <stringProp name="0">0</stringProp> <stringProp name="0">0</stringProp>
</collectionProp> <collectionProp name="1751132257">
<stringProp name="0">0</stringProp> <stringProp name="0">0</stringProp> <stringProp name="0">0</stringProp> <stringProp name="0">0</stringProp> <stringProp name="0">0</stringProp> <stringProp name="0">0</stringProp> <stringProp name="0">0</stringProp> <stringProp name="0">0</stringProp> <stringProp name="0">0</stringProp> <stringProp name="0">0</stringProp>
</collectionProp>
</collectionProp> <elementProp name="ThreadGroup.main_controller" elementType="LoopController" guiclass="LoopControlPanel" testclass="LoopController" testname="Loop Controller" enabled="true">
<boolProp name="LoopController.continue_forever">false</boolProp> <intProp name="LoopController.loops">-1</intProp>
</elementProp> <stringProp name="ThreadGroup.on_sample_error">continue</stringProp>
</kg.apc.jmeter.threads.UltimateThreadGroup> <hashTree>
<kg.apc.jmeter.samplers.DummySampler guiclass="kg.apc.jmeter.samplers.DummySamplerGui?" testclass="kg.apc.jmeter.samplers.DummySampler" testname="Dummy Sampler" enabled="true">
<boolProp name="SUCCESFULL">true</boolProp> <stringProp name="RESPONSE_CODE">200</stringProp> <stringProp name="RESPONSE_MESSAGE">OK</stringProp> <stringProp name="RESPONSE_DATA">tetst</stringProp> <stringProp name="RESPONSE_TIME">100</stringProp>
</kg.apc.jmeter.samplers.DummySampler> <hashTree>
<ResultCollector guiclass="SimpleDataWriter" testclass="ResultCollector" testname="Simple Data Writer" enabled="true">
<boolProp name="ResultCollector.error_logging">false</boolProp> <objProp>
<name>saveConfig</name> <value class="SampleSaveConfiguration">
<time>true</time> <latency>true</latency> <timestamp>false</timestamp> <success>false</success> <label>false</label> <code>true</code> <message>false</message> <threadName>false</threadName> <dataType>false</dataType> <encoding>false</encoding> <assertions>false</assertions> <subresults>false</subresults> <responseData>false</responseData> <samplerData>false</samplerData> <xml>false</xml> <fieldNames>true</fieldNames> <responseHeaders>false</responseHeaders> <requestHeaders>false</requestHeaders> <responseDataOnError>false</responseDataOnError> <saveAssertionResultsFailureMessage>false</saveAssertionResultsFailureMessage> <assertionsResultsToSave>0</assertionsResultsToSave> <idleTime>true</idleTime> </value> </objProp> <stringProp name="filename">C:\Jmeter-test\responsedata.csv</stringProp> </ResultCollector> <hashTree/> </hashTree> </hashTree> </hashTree> </hashTree> </jmeterTestPlan> 

Hi,

The hold factor of N seconds means the scenario will be played and looped during N seconds. After N seconds, the thread will be stopped during the ramp down. So it is normal you have a lot of requests.

Stephane

Thanks Stephane for quick response. May be I am not using this a right way I am trying to do this. I want jmeter to send requests and simply retrun the response back without holding the load. So I set the hold time to "0" seconds. I need the response data when the request are hitting at the rate of Step 1 - 1 request per second need to continue this for 10 seconds Step 2 - 2 requests per second need to continue this for 10 seconds and continue up to Step 10 - 10 request per second need to continue this for 10 seconds Is the JMX i created (pasted in last comment) correct for this case?

Sameer

Hi,

You should use stepping thread group. Start 10 threads, 1 new every 10 sec, hold load for 10 sec, and finally close 10 threads in 1 sec.

Stephane

Thanks Stephane I will try that.

hi this is amazing...It solved alot of my problems..... Thanx alot...Just want to know if you can do something for the automatic saving of listener results like average graph table...because in file the values saved are not how i want n need to do calculation & arranging which is very time consuming... thanx rashmi

I have a problem with this plugin. I have a load test defined as a simple controller inside a disables "Modules" simple controller. And I run this test using Modules controller inside an UltimateThreadGroup and inside a good old ThreadGroup?. I disable one of them to use a different threading strategy.

The problem is that on a very same total amount of threads (3000) the simple ThreadGroup? works fine, but the UltimateThreadGroup throws an OutOfMemoryError?: GC overhead limit exceeded.

Hi,

Increase the memory allocated to the JVM... What are your current settings?

1 gig. I can't really have any more. I am concerned that I have tried up to 7k threads using plain ThreadGroup? on 512 mb, it did not fail with OutOfMemory?. UltimateThreadGroup fails on 3k.

I am going to do a little more experimentation with the numbers to find out which is the max number of threads for UltimateThreadGroup on my test

Can you give the values for TG and UTG? (TG: nb of threads, rampup time, loop count ; UTG: count, delay, startup time, hold load, shutdown time)

Thanks

Hi again,

I would like to use (global) variables for the schedule (for example Hold Load for, sec = ${RunTime?}). Any possibility for this?

Kind Regards (again), Sander

No, Sander, Because JMeter processes Thread Group settings before calculating any variables, as I know. Maybe some properties would work.

Well, I have used the following before in my scripts and it works:

In testplan define: name=LoopCount? with value=${P(looping,5)} Thread Group define: loop count=${LoopCount?}

If run the script with the GUI then the variable LoopCount? has default value 5. If I want to run the script with loop count 10 I just add -Glooping=10 to the command line.

Found the article where I got it from: http://jmeter-tips.blogspot.com/2010/01/tip-4-using-jmeter-properties.html

Sounds like an bug issue. Could you file one at Issues tab?

Hi Stephane,

Is it possible to repeat the configured load pattern automatically?

We will be running the load test for more than 2 days. It will be tedious task to configure the load pattern for such a long test.

It would be great if we have some option to repeat the same pattern again and again.

Thanks, Yuvaraj

Hi Stephane,

I tried out jmeter plugin for server hits per sec so can plz help me out and can u plz explain me in detail what is the relation between ramp period and loop count how i calculate n what will executed first like thread group -> then loop count -> thread group or thread group -> then loop count as i want to run test scenario with 100 users hit per sec for 10 min.

Thanks Geetika

Hi Stephane,

This is a super plug-in, and just in time for a traffic model that I need to test. I am wondering if I am using it correctly though.

Is the produced graph ("Expected parallel users count") meant to be precise, or is it rough?

I find if I use for example the following values:

the estimate graph looks like:

• it hits 10 threads after what looks like 9 seconds, not 10
• it then holds for about 20 seconds, not 30
• it then bypasses 120 threads, and ramps straight to 180 threads, again in what looks like 9 seconds

Thanks

I tried setting up your schedule, it graphs it correct. Make note that severy record in schedule starts from test begin, not from the end of previous record. This leads to sum of active threads from different records in every second. Threads will work exactly how you see on graph.

Thanks, I take your points, but if I reduce the Threads Schedule down to just:

It's clear in the graph that it ramps up in 9 seconds not 10. Can I send you a screenshot?

Please, send it. It is interesting issue

If you look at your sample, you can see it is more a problem of the labels of the x axis. the actual schedule is good. In your exemple, you have x axis labels: 0:00 0:04 0:09 ... so 4 sec for 1st range, 5 sec for 2nd, which is not good as all ranges have the same values.

I just verified this. The 00:09 you see as label is in fact something like 00:09.900, but we do not display milliseconds in the x label for better readability. So nothing to worry about, you can test your example using DummySampler with resp time = 1 ms, and using the Active Thread Over Time listener you will verify the ramp up is actually 10 sec.

Ok that explains why the Expected graph is slighty skewed.

So I'm looking to:

1. Ramp up to 60 threads gradually over 10s
2. Hold for 30s
3. Repeat (i) and (ii), up to 120, 180 etc

I have this working for up to 120 threads, but when I add the third row to the schedule, the expected graph doesn't look how I expect (it begins stopping threads at 120). See screenshothttp://tinypic.com/view.php?pic=29gbvhg&s=7 ) Also from the looks of the values I extracted from Active Threads Over Time (see valueshttp://pastebin.com/4ARRi56A ) the holds are 16s and not 30.

I've probably misundestood the operation of the this thread group, but can you explain what's going on here?

I understand why you're confused - because you don't know how threads work. Threads stop after all time specified for startup+hold load+stop. So if you want to have some kind of stepping graph, you should have first record working for 180 sec, second record working for 120 sec, third working for 60 sec. And startup delay 0-60-120 will move this steps forward in time. Is that what you want to achieve?

OK, thanks to your explanation, I now have stepping working.

Yet for some reason, even though the preview graph and the Active Threads Over Time listener show me that my hold value is 30s (which is what I want) http://tinypic.com/view.php?pic=2zfkhhs&s=7 , when I look at the exported timestamps, the hold is 26 seconds http://pastebin.com/SmcmP2H5

Is the thread group considering the times from (timestamp 7 to timestamp 8) and (timestamp 21 to timestamp 22) as part of the hold (which would total 30s)?

If you see Active Threads Over Time graph correct, then provided load is correct. Maybe there's some issue with export to csv. Also I see that you've set granulation time to 2000ms, this may lead to some corrections also. Try setting it to 1000ms.

When I change granularity to 1000ms, the apparent hold is now 28ms (based on the exported values). So it looks like the hold period is being calculated as:

Hold load for, sec - (Group Timeline Values for x 2).

Does something need to be fixed here with the export functionality? I appreciate that the Thread Group is now behaving how I am asking it to, but since I will be using the exported values (not the graph) to ultimately report my results, they will not 100% reflect the scerario that was tested.

Please provide the csv export and the original graph produced by the listener.

Ok no need to send anything everything is fine, please check by yourself, there is no diff between visualizer and csv

Am I correct in saying that due to the nature of the Thread group's stepping action, it is not possible to stop all threads immediately and at the same time? E.g. in this http://tinypic.com/view.php?pic=zsmmg7&s=7 traffic model, it's not possible to stop all 900 threads at the same time?

Actual threads stop behavior strongly depends on samplers present in thread. But if you set Ultimate Thread Group to stop all threads at once, it will try to stop them and algorithm is pretty simple and robust. All differences in real stop time is because of some delays in thread interruption. It's all because of Java, you know...

Is it possible to allow the thread to complete all the last sampler before shutdown? Example: Login > do something 1 > do something2 > logout. when the Hold Load For reaches its limit, thread stops even if it is in say 'do something 1'. Would it be possible to allow it to logout and then stop?

Sorry, but this is JMeter behavior, we can't change it during runtime, because we don't know what thread do. Jmeter core team may change this, but I doubt they will.

Hi, is it possible to use the Ultimate Thread Group for this? I want to increment users (e.g. (n-1) + (n-2) = n users, with n the users to be started next) for unlimited time ( I will stop the test using assertions).

Thanks!

You better use original JMeter's Thread Group for this case. However, you can set up huge numbers in Ultimate and it will be like infinite.

Can Ultimate Thread Group be used with remote testing? If yes: - Is Start Threads Count the number of threads for each machine, or the total for all the machines? - Is there extra tweaking involved in making the Active Threads Over Time listener 'look like' the Expected parallel user count?

Thanks

Yes, it can be used for remote testing, but don't forget to install plugins on remote JMeter folders. Start Threads Count used for each machine.

I didn't get the question about "look like"... No extra tweaking, just displaying JMeter results.

One advice - use ${machineName} as a part of your Thread Group name in distributed testing - it will help you get more clear results of active threads count.

Thanks for the speedy reply.

The "look like" question arises from the fact that when I use Ultimate Thread Group with remote testing the Active Threads Over Time listener does not show the values I expect from the test configuration, more precisely the Expected parallel user count presented when creating the Ultimate Thread Group.

Here is an example of what I mean. Below is the Threads Schedule as defined in the test:

I run this test using 2 remote machines. I check the thread count using the Active Threads Over Time listener, and I expect the graph to look, more or less, like the Expected parallel user count, meaning that it hits the maximum thread count of 100 after 10 seconds, that it holds that thread count for 20 seconds, and then stops all threads in 10 seconds.

The results I get in the Active Threads Over Time listener are completely different. The thread count for each machine is different (not as displayed in the Expected parallel user count), the test goes on longer for one of the machines, and the results are not consistent for repeated test runs. The problem arises only when remote starting all of the machines, starting only one remote machine at a time displays the expected result.

I should mention I am using version 0.4.0 of the plugin. Both machines are using the same version of JMeter, JMeter plugin and Java.

I have tried using ${machineName} as a part of my Thread Group name, but this did not shed more light on the subject, neither thread group nor total look like what I expect.

Hope this makes it more clear.

Appreciate the help, and thanks again.

Sorry, ${__machineName()}

I managed to identify and solve the problem. I was remote starting a localhost and it caused all kinds of trouble (as mentioned in the previous post). Removing it from the remote hosts list solved it.

My Requirement:

Ramp up 30 threads in 2 mins.

Threads should sustain for 5 mins

Each thread should send 10 requests per min so that we can have 300 concurrent requests per minute for 5 mins.

And?

Is possible to set two (or more) Ultimate Thread Group in the same testplan? Currently only the first one is detected. :-( Thanks in advance.

There is  issue 55  currently preventing UTG to work correctly, sorry. We'll fix it in the next release.

Hi Stephane, Great plugin!!!. I would like to test the following scenario. Could you pls suggest the settings which I need to do. Start 5 threads in 1 Sec. The threads should run only once in this duration. Once the call is over, it should automatically shutdown the threads and need not hold for any particular duration. After the first request is over, increment the thread count by 1 for every iteration till Thread count is 100. Thanks in Advance.

Hi, thanks for this great plugin. Is is possible to configure it trough properties like Throughput Shaping Timer uses load_profile=const(10,10s) line(10,100,1m) step(5,25,5,1h) ?

:) I see you liked this load_profile approach...

Sorry, but thread groups have different nature, so they can't be configured like this...

Bharath,

Please, use mailing list for such questions

Hi, removed from here and send it to mailing list. thanks..

Regards,

Bharat

Hi can u pls give me the sceanrio like 10 users - 10 mts 20 users - 15 mts 25 users - 30 mts 20 users - 15 mts 10 users - 10 mts

In th same graph with rampup of the users without stopping the test

Hi ,

Can I simulate mulptiple tenants using this plug-in?

Ex: Tenant1 with 100 loads Tenant2 with ...150 laod ....... Teant50 with 70 users load?

Hi, where do I get full documentaion for this plugin?

Here's the only doc for this plugin.

Hi Friends, I have a scenario 1. Use 18 ultimate thread group. 2. Add dummy sampler in each ultimate thread. 3. First Second - line in each ultimate thread Thread 1 2 4 Thread 2 2 4 Thread 3 2 4 Thread 4 2 4 Thread 5 2 4 Thread 6 2 4 Thread 7 2 4 Thread 8 1 2 Thread 9 1 2 Thread 10 1 2 Thread 11 1 2 Thread 12 1 2 Thread 13 1 2 Thread 14 1 2 Thread 15 1 2 Thread 16 1 2 Thread 17 1 2 Thread 18 1 2

4. Conditions First Column total rampup is 250 seconds. Second Column total rampup is 500 seconds.

5. First 25 users steady state is 30 min. Second 50 user steady state is 1 hr.

6. Remember exactly 30 min and 1 hr. steady state has to be their.

Tell me the solution?

Oh, sorry, I din't get your situation. Could you move your question into mailing list and attach your test plan?