Ultimate Thread Group to Finish all samplers in a thread

[Roman Yefimets]

If my understanding of the Ultimate Thread Group plugin code is correct, all threads are scheduled at the beginning of a test with a start time and end time based on ramp up, hold load and cooldown. 

However, when a thread is scheduled to end, it just receives a shutdown signal and the thread does not complete (all the samplers in an iteration of the thread did not run).

In my use case, I need all samplers to be allowed to complete. For example:

1. [Sampler1] Start Call
2. [Sampler2] Speak

3. [Sampler3] DTMF

4. [Sampler4] End Call

From what I've seen, many threads will simple just stop anywhere in this sequence because that is when they were scheduled to stop. So my server won't receive an end call request for those thread iterations.

I have played around with tearDown threads but with 20K+ scenarios (calls in this case), it does not seem feasible to collect data for all calls that never ended and tear them down.

Any suggestions on how Ultimate Thread Group can be modified to achieve these results?

TL;DR: Need a solution where Ultimate Thread Group all samplers within a thread iteration to finish even if thread was scheduled to shutdown early. 

[Dmitri T]

You don't need to "modify" anything to "achieve these results". 

Just put your requests under While Controller and use the following __groovy() function as the condition:

${__groovy((System.currentTimeMillis() - (vars.get('TESTSTART.MS') as long)) < your-desired-test-duration-here,)}

This way you will get confidence that all the Samplers from your transaction will be executed before thread is shut down.

[Roman Yefimets]

I'm not sure this solves my problem. 

Imagine a hold load of 3 min, and the scenario mentioned above:

1. [Sampler1] Start Call
2. [Sampler2] Speak
3. [Sampler3] DTMF
4. [Sampler4] End Call

Say samplers 1-4 take 1 min to complete. Once a thread completes this, it will restart and loop through 1-4 again until hold load is met. Once hold load is met, the thread can stop at any of these steps.
The while condition you mentioned will unsure that the whole test runs for a specific time, but it does not ensure that a thread completes all samples on say the 3rd iteration.

Example:

[What I am seeing]
Start thread:
1
2
3
4
1
2
3
4
1
2
Stop Thread:

[What I Want]
Start thread:
1
2
3
4
1
2
3
4
1
2
3
4
Stop Thread:

[Roman Yefimets]

In my script thread schedules are controlled by `jpgc Ultimate Thread Group`. Once the thread schedule is configured (start thread count, startup time, hold load, shutdown time), they will receive a shut down signal when their time is up. This will ignore any while loops or conditions. I understand how your solution would work if I was not using the Ultimate Thread Group and controlling the test duration, but unless I'm missing something, it wont work in this case. 

[Dmitri T]

Imagine a hold load of 30000000000 minutes in the Ultimate Thread Group and setting the desired test duration in the While Controller

${__groovy((System.currentTimeMillis() - (vars.get('TESTSTART.MS') as long)) < (3L * 60L * 1000L),)}

[Roman Yefimets]

Again, this does not solve my problem. A thread is not going to keep running just because it contains a while loop. Once the ultimate thread group sends a signal for it to shutdown, it will shutdown regardless of the samplers within 

--
You received this message because you are subscribed to a topic in the Google Groups "jmeter-plugins" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jmeter-plugins/qOfXg8yYiC0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jmeter-plugin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jmeter-plugins/3d199b7e-270c-42ec-813f-c9e59851e839n%40googlegroups.com.

[Dmitri T]

I was higher opinion of Microsoft employees. Please use online translation tools or language models like ChatGPT to translate the following simple stanza into Russian or whatever is your native language:

In the Thread Group set test duration to forever or to next year and use the While Controller's condition to control the duration of your test.

[Roman Yefimets]

Dmitri, I appreciate your help but come on now, there is no need for rudeness. I've been speaking English fluently for 25 years and have a CS degree. Perhaps consider that you are not fully understanding my question. If it is due to poor explanation on my part, then I apologize. 
My ultimate goal here is not for the test to run for a minimum amount of time. This is achieved easily enough with startUpTime + holdLoad + shutDownTime. What I need is for the last iteration of each thread to complete every sampler. I have no idea how long each iteration will take, as it varies. 

I suppose that I can utilize your solution so that each thread is guaranteed to run for rampUp + holdTime amount of time, and then send a shutdown signal to that thread myself once all samplers have been completed
I already have a similar solution using this logic to determine when a thread is scheduled to be shut down, and to not run the iteration if it cannot complete within {insertMagicNumber}. This however impacts the call concurrency since threads are scheduled to be shut down way to early.

I will give your approach a try.

To view this discussion on the web visit https://groups.google.com/d/msgid/jmeter-plugins/facb9096-34a3-47bf-be24-aaafa5076bc7n%40googlegroups.com.

[Roman Yefimets]

I think my issue is mostly resolved. The trick was (as Dmitri pointed out) to NOT let Ultimate Thread Group control the thread duration, but do that calculation yourself within the script. To do this:

1. Set the Hold Load to something very high (1000000 seems to cause a stack overflow so i used 100000). This ensures the thread group schedules the threads to end far in the future. 
2. Create an If controller within your thread group with the condition ${__groovy(vars.get("shutDownThread") != "true",)}
3. Within that If controller, place the samples that need to be executed 
4. At the very end of the If controller add a JSR223 Sampler that does the thread schedule calculations that are done within the Ultimate Thread Controller. This will give you the startTime and endTime that the Ultimate Thread Controller was planning on scheduling.
1. then do another calculation. if (System.currentTimeMillis() >= endTime) vars.put("shutDownThread", "true"); 
2. when the thread loop restarts, it will uses these calculation to ensure that the thread ran at least till endTime, and then it will exit the loop. 

Thanks again for your suggestions Dmitri