Fairly new to JMeter and I have the requirement to start a new thread (Usercall) based on a poisson timer. I figured out how to create a poisson timer but not how to start a new thread based on a poisson timer. When I add the poisson timer in a dummy sampler at the start of the threadgroup it still executes the treads in parallel of course.
Goal would be to control the amount of threads by manipulating the poisson timer.
Edit:
So I would set the Poisson timer so that most calls will happen between 0 and 7 seconds. It would start a thread which would then execute a business case on the system. Next thread should be again started between 0 and 7 seconds and run in parallel with the first one. After the threads would run thru they close. This way it should not result in 1000 open threads and you can control the threads dynamically with the timer
If you're looking for a way to start threads with random delays I'm afraid that the only way is doing it using JSR223 Test Elements and Groovy language. Take a look at ThreadGroup.addNewThread() function.
Example code:
ctx.getThreadGroup().addNewThread(org.apache.commons.lang3.RandomUtils.nextInt(0, 7), ctx.getEngine())
However I fail to see why just not to go for the Poisson Random Timer, even if you start all the threads at the same time if you put the timer as a child of the 1st sampler the threads won't execute anything as the timer will add the delay.
Related
Fairly new to JMeter and I have the requirement to start a new thread (Usercall) based on a poisson timer. I figured out how to create a poisson timer but not how to start a new thread based on a poisson timer. When I add the poisson timer in a dummy sampler at the start of the threadgroup it still executes the treads in parallel of course.
Goal would be to control the amount of threads by manipulating the poisson timer.
Edit:
So I would set the Poisson timer so that most calls will happen between 0 and 7 seconds. It would start a thread which would then execute a business case on the system. Next thread should be again started between 0 and 7 seconds and run in parallel with the first one. After the threads would run thru they close. This way it should not result in 1000 open threads and you can control the threads dynamically with the timer
If you're looking for a way to start threads with random delays I'm afraid that the only way is doing it using JSR223 Test Elements and Groovy language. Take a look at ThreadGroup.addNewThread() function.
Example code:
ctx.getThreadGroup().addNewThread(org.apache.commons.lang3.RandomUtils.nextInt(0, 7), ctx.getEngine())
However I fail to see why just not to go for the Poisson Random Timer, even if you start all the threads at the same time if you put the timer as a child of the 1st sampler the threads won't execute anything as the timer will add the delay.
I have created a performance test script as below. I am running 4 Thread Groups in parallel (Even though there are 14 Thread Groups, only 4 are enabled and I am running only those enabled 4 Thread Groups). I have used default Thread Groups.
I have used Flow Control Action to simulate the user think time and set it as 3 seconds.
My requirement is to achieve Throughput as 6.6/seconds. What is the best way to achieve it? Also, does user think time creates any impact on Throughput?
As per JMeter Glossary:
Throughput is calculated as requests/unit of time. The time is calculated from the start of the first sample to the end of the last sample. This includes any intervals between samples, as it is supposed to represent the load on the server.
The formula is: Throughput = (number of requests) / (total time).
So basically throughput is the number of requests which JMeter was able to within test duration time frame. If you introduce artificial delay of 3 seconds - it will make the overall throughput lower
Other (and the main factor) is your application response time because JMeter waits for previous request to finish before executing new one so there could be 2 options:
The amount of threads in your Thread Groups is not sufficient to create the desired throughput. If this is the case - just add more threads (virtual users) in Thread Group(s)
The amount of threads in your Thread Groups is too high and you're getting higher throughput that you expect. If this is the case you can pause JMeter even more by adding Constant Throughput Timer and specifying the desired number of the requests per minute you want to have. If you need 6.6 requests per second it will mean 396 requests per minute
Also remember that JMeter itself must be able to send requests fast enough so make sure to follow JMeter Best Practices
My suggestion is to consider using the Arrivals Thread Group. This TG will allow you to configure the desire average throughput (ATP); the TG will instantiate the required threads needed to achieve the ATP goal.
As for the Think Time (TT), it should be a business requirement that emulates the pauses that users take when using the application in the real world.
I have recorder a simple flow using jmeter. I have multiple http requests under one thread group. I am trying to run this thread group for 50 concurrent users in blazemeter. But when ever i try to run the jmx file i can see that htis/s is around 3 sec. Though my rampup time is 0 & thread is 50. My understanding is if the users are concurrent & each user (thread) have 3 requests to make, then minimum hits/s should be 50.
I have added a constant throughput timer at the bottom of the thread group & a throughput controller. In the timer target throughput is set to 300 & in the throughput controller throughput is set to 100 with percent execution.
How do i achieve maximum hits/s in blazemeter? Or am i missing something here. Thanks in advance.
I think that you're misusing Constant Throughput Timer.
Throughput of 300 requests per minute gives 300/60 = 5 requests per second
Constant Throughput Timer works on minute level so make sure that your tests lasts longer than 1 minute
Each JMeter thread representing virtual user executes nested samplers upside down, when thread has nothing more to do it is being shut down. Make sure that you have enough job for threads and if not - make sure that you provide enough loops (see point 2 as well)
Constant Throughput Timer cannot kick off any new threads, it is capable of throttling (pausing) current active threads to limit load to throughput defined. So try increasing threads count.
For more information refer to How to use JMeter's Throughput Constant Timer guide
You may also like to use Throughput Shaping Timer instead, it provides a little bit more flexibility than JMeter's CTT.
Are the simulation loops separate? With separate I mean that JMeter waits for all threads to be done to begin a new iteration of the loop. Or does JMeter just let every thread do a request X time, without stopping?
Additional question: Could one change the number of threads dynamically? Doing a simulation for a range of number of thread (e.g. 100-1500) would be nice.
Each thread is completely independent. So when you have loop set, if a thread is finished its first loop of execution, it goes for another round (as per the loop count) irrespective of the completion of other threads.
You can use a variable for the number of threads & set the number via property files etc. But when the test is running, you can not change the no of threads for the test.
Hope it is clear!
In addition to vIns answer:
You CAN change load dynamically during execution. Threads count is static, but their fire rate is something you can impact.
Look into combination of Beanshell Server and Constant Throughput Timer.
I would like to run the test with the given execution rate per second. The next iteration should start asynchronously at 2nd second without waiting for completion of first iteration.
I tried with Constant Throughput Timer but it doesn't proceed to next iteration until
it finish getting response of first iteration threads.
You can use 2 separate Thread Groups for this (make sure that you have Run Thread Groups Consecutively box unchecked at Test Plan level.
Also check your Constant Throughput Timer configuration Calculate Throughput based on field, you may wish to have separate timer for each Thread Group.
By the way, there is more advanced Throughput Shaping Timer element available via plugin which provides easy-readable graph demonstrating the load pattern.
If you will be considering using separate Thread Groups remember that JMeter Variables have scope local to the Thread Group where they are defined. To use them across different Thread Groups you'll need to cast them to JMeter Properties which have "global" scope. See How to Use Variables in Different Thread Groups guide for how to implement it.
A single thread can only handle one request at a time. You'll need more than one thread for what you're asking for. The constant throughput timer can indeed do what you're asking as long as you have enough threads.
In order to achieve what you're asking for (lets say 1 request every second, regardless of how long the request takes) you could I would suggest using a large number of threads and using the CTT for 60 requests per second.