I am trying to see if I can simulate a burst mode in JMeter (2.x -- that's the only version I have access in this particular environment and cannot upgrade) with a sustain load, and a fixed duration/flight-time at certain intervals.
For instance, I would like to flood the target with 4 separate thread groups of 80 users, every 30 minutes for around 5 continuous minutes. This is in addition to the existing main thread group that is making 200 simultaneous requests forever (24 hours+).
I tried this answer, however, I am not seeing the desire effect. My JMeter setup is as following:
- A main thread user group (200 users, 5 secs ramp-up, forever loop)
- It contains 4 separate HTTP Requests as its children (they get called as long as the script is not shutdown)
- 1st separate thread group with 80 threads, 5 secs ramp-up, forever loop; as its children:
- "Constant Timer" for interval invocation, e.g. every 30 mins
- "Runtime Controller" for duration/flight-time configuration, e.g. 5 mins continuously
- "Loop Controller" to iteratively executing the requests, set to forever loop (I even tried fixed numbers, e.g. 10)
- An actual `HTTP Request`
- 2nd separate thread group with identical setup except different HTTP Request
- 3rd separate thread group with identical setup except different HTTP Request
- 4th separate thread group with identical setup except different HTTP Request
I tried to play with Ultimate Thread Group but seems like it doesn't create a surge mode, but it does execute it for the set duration. The requests are uniformly distributed in that time period rather than being sent in burst mode to the target server. So it appears that it only subscribes to sending a number of requests equal to the number of thread counts for that duration.
What I want for those threads in these surge thread groups to continuously send requests for the entire configured duration, non-stop, similar to the main load thread group, rather than just sending X amount of requests (equal to the number of threads) once.
Is this achievable with
You might need to switch to a SaaS offering to support that many requests in parallel, such as https://rungutan.com
I don't think Constant Timer is the right option as it creates 30 minutes delay before each HTTP Request sampler in its scope.
If you want to wait for 30 minutes and then release all 80 threads at exactly the same moment:
Add Test Action sampler and configure it to "sleep" for 30 minutes
Add Synchronizing Timer so all 80 threads will "sleep" together as the child of this Test Action sampler
Add HTTP Request sampler which does the real job
Add the same Synchronizing Timer as the child of the HTTP Request sampler
This way you will get 80 users hitting your server each 30 minutes
Related
I am new to jmeter, and I would like to do a test in which I send 500 requests per second, this for 10 seconds
The configuration I have is:
I would like to know if my configuration is correct or it can be done better
Your configuration means:
5000 users will be kicked off in 10 seconds, i.e. each second 500 users will be started
Once started the users will start executing Samplers upside down
The actual number of requests per second will depend on the application response time.
In your case you will only be able to achieve 500 requests per second if your application response time will be 1 second precisely. If it will be more - you will get less requests per second and vice versa.
If you need to send 500 requests per second for 10 seconds sharp I would suggest using Concurrency Thread Group and Throughput Shaping Timer combination.
The Throughput Shaping Timer needs to be set up like this:
And the concurrency thread group like this:
The configuration is for example only, in your case the number of threads required to conduct 500 request per second load might be different and again in mainly depends on the application response time.
Im just begining with stress tests in Jmeter and have following problem. I want to call 50 times at once (50 users) for one endpoint ss1. When I just leave empty "Ramp-up period" these calls have very small delay but still have - intention is to calls it at exactly the same time ss2
If you want the request to be sent at exactly the same moment with 50 users - add a Synchronizing Timer and set the number of simulated users to group by to 50 (or whatever it the number of threads in your Thread Group)
More information: Using the JMeter Synchronizing Timer
I'm having a question about how the requests are processed,
For example:
I have created a test plan, with one thread group.
Set number of users (thread): 10
Ramp-up period: 20
Loop count: Forever
Within this thread group I have created 5 HTTP requests.
When I hit start, I understand that it starts with 1 user, and by 20th second it will have all 10 users.
Does each sampler (http request) get assigned to 1 user? Is each sampler fired in sequential order? Does it fire parallel requests? I am trying to understand overall working.
JMeter starts threads (virtual users) within the bound of the ramp-up period. In your case JMeter starts with 1 user and adds another user each 2 seconds.
When thread (virtual user) is started it starts executing Samplers upside down (or according to Logic Controllers)
When there are no more samplers left to execute the thread starts over (if the number of loops is > 1), otherwise it is shut down.
With regards to concurrency, it mainly depends on the number of threads and application response time, you can observe how many virtual users were online using Active Threads Over Time listener and the delivered load using Server Hits Per Second. The aforementioned listeners can be installed using JMeter Plugins Manager
Each thread is sequential firing HTTP requests based on your flow
But you are executing 10 threads/users in parallel, so the order of the requests in total isn't sequential, but parallel
If you defined loop count as 1, then each sampler (http request) would get assigned to 1 user,
But you are looping endlessly, so samplers can be executed more than once per user/thread
About Loop Count: (asked in comment)
Loop Count - the number of iterations for each Thread.
I am working on stress test, but my first sampler floods server with tons of requests with very little amount of time, so I want to make a delay between each thread using request.
Test structure:
Thread1 - Sampler1 (for example: access login form)
Delay (custom seconds)
Thread2 - Sampler1 (for example: access login form)
Delay (custom seconds)
ThreadN - Sampler1 (for example: access login form)
Delay (custom seconds)
Thread1 - Sampler2
Delay (custom seconds)
Thread2 - Sampler2
Delay (custom seconds)
<...>
Synchronizing Timer
All threads realeased with final sampler (this part works)
I tried to put timers as samplers parents or childs. Probably I am missing something, because non of the timers are working for me.
I've found similar problem solutions, but non of the worked for me:
JMeter - sharing a delay between requests across multiple ThreadGroups
Delays for each thread in Ultimate Thread Group
I would suggest using the stepping thread group via http://jmeter-plugins.org/wiki/SteppingThreadGroup/.
In the 'thread scheduling parameters' section, you'll note you're able to specify the maximum number of threads to run at peak, but you're also also to slowly instantiate threads as you need them.
Very plainly, the setup below says "When I run this test, I'm eventually going to want 100 threads, but when I first start the test, wait 15 seconds, then only start 10 threads. Then add another 10 threads every 120 seconds. Once we reach max threads, keep working for 180 seconds, then slowly peel off 5 threads every 15 seconds.
This should meet your need.
As per your Test Plan description, you can use 1 of the timers mentioned below:
Gaussian Random Timer
Constant Timer
Hope this will help..
Constant Timer would be best option as per your mentioned requirement.
You can use 'Ultimate Thread Group' instead of regular Thread Group. There is 'Initial Delay' in ultimate thread group which will help you to achieve your requirement.
I have a specific use case for my web app where I want to demonstrate the following flow:
Send Type-1 http requests for the first 15 minutes
Start sending Type-2 requests at the 10 minute mark, so they run concurrently with Type-1 requests for 5 minutes. Send Type-2 requests for a total duration of 15 minutes.
I'm having issues formulating my test plan to create this test. Currently I have one thread group with two HTTP requests samplers under it (one for type 1 and one for type 2). I've set the scheduled duration for this thread group to 25 minutes. Under each of the Http Request samplers, I have a throughput shaping timer. The first one is simply set to run for 15 minutes, the second is set to "wait" (rps is .000001 for the first 10 minutes of the test) and then start sending requests at the 10 minute mark for 15 minutes.
I think the second throughput timer is being ignored though. Type-1 and Type-2 requests both start being sent as soon as I start the test, suggesting only the first throughput shaping timer is being used for both samplers. If I remove the first throughput shaping timer, then the second one is used for both http request samplers.
Can you only have one throughput shaping timer per thread group, and if so, how else could I make a test to have the second sampler wait 10 minutes in the same thread group?
Use 2 thread groups, one per request type.
Configure on each the scheduler:
for type 1, start immediatelyvand last 15 minutes
for type 2, start after 10 minutes and last for 15 minutes.