Jmeter multiple concurrent users in single thread group

1
votes

I have 1 thread group and I have defined 100 threads and 1 Iteration with a single HttpSampler. Basically I am testing a single GET API.

enter image description here

enter image description here

Now, Jmeter should start 100 threads and then they should fire request to my server which have the API. The server can respond to 100 requests concurrently. So, basically at any point in time I should have 100 concurrency.

But that is not what is happening when I checked through Blazemeter. I get a max users of 37 and total users as 100 which means max concurrency during the test was 37.

This can be possible only if Jmeter did not executed the threads parallel. So where am I wrong ?

I want all threads to execute parallel after they all are created and fire requests at once so that maximum concurrency is 100 for 1 iteration.

4
javajmeterperformance-testingload-testingblazemeter
JMeter fire the request as soon as the Thread are created, you have kept the Ramp Up as 0, so JMeter will try to create the Thread ASAP and fire it, but no where we are specifying JMeter to hold it or to achieve N Hits Per Second. That is the reason you are seeing the unwanted Hits, but this is JMeter behaviour. How to control Threads and Hits Per Second is provided in the answer. – SAIR
@SAIR I am keeping ramp up as 0 but still not all 100 requests are fired simultaneously – Number945
Yes it will not fire 100 Requests concurrently with your setting, for that please refer answer section. – SAIR

4 Answers

3
votes

If you need more control and accuracy use Ultimate Thread Group JMeter plugin (instead of regular Thread Group)

Set Start Thread Count as 100, with 0 initial delay and 0 Startup Time, with positive Hold time, your thread will hold 100 max users

General example:

If your computer can't handle generating load, you may need distributed testing setup

2
votes

It is not suggested to use Ramp-Up period as 0.

I think you are making confusion between concurrency (Related to virtual users) and simultaneous (Related to requests or samplers).

To hit requests simultaneously, use the Synchronizing Timer as a child of your requests. It will pause X number of threads and then released at once. And before that, to maintain the concurrency at 100 users, try to use the ramp-up time accordingly (i.e 10 seconds). So it will take 10 seconds for 100 users alive on the server and then hit the requests for 100 users simultaneously.

It doesn't matter which thread group you use but if you maintain the concurrency for more period of time (hold that concurrency), then use Ultimate Thread Group or you can use the loop count accordingly.

If you want to perform spike testing, then the regular Thread group is fine. But you have to remember that, some of your threads might already finish their work and were shut down so you won't see the expected number of the concurrent user.

Here are the example screenshots for 1 minute Test duration (100 users ramp-up time 30 sec + hold load time 20 sec + 10 sec for ramp downtime)

Ultimate Thread Group Config:

enter image description here

Test Results (100 requests at once):

enter image description here

enter image description here

Test Results (100 Concurrent users):

enter image description here

Hope it helps you to understand.

1
votes

To achieve this, you can use Synchronizing_Timer. Add Synchronization Timer as a child of your GET Request.

The purpose of the SyncTimer is to block threads until X number of threads have been blocked, and then they are all released at once. A SyncTimer can thus create large instant loads at various points of the test plan.

enter image description here

Secondly, to keep a constant load of 100 Request Per Second/Hit Per Second for a time duration, you can use Throughput Shaping Timer. Make sure, you add the Loop Count to Forever and Duration accordingly in Thread Group.

enter image description here

1
votes

JMeter acts as follows:

  1. The number of threads specified in the Thread Group is being kicked off during the ramp-up period
  2. Each thread starts executing Samplers upside down (or according to the Logic Controllers)
  3. When thread doesn't have any more Samplers to execute or loops to iterate it's being shut down

Assuming all above you may run into the situation when some threads have already finished their work and were shut down and some haven't yet been started. Check out JMeter Test Results: Why the Actual Users Number is Lower than Expected article for more comprehensive explanation if needed

Therefore the solutions are in:

  • Provide more "iterations" on Thread Group level to let your users loop over, this way you will have 100 concurrent users
  • If you need to perform some form of Spike Testing and don't want/cannot increase the number of loops just use Synchronizing Timer, this way JMeter will pause the threads until the desired amount is reached and release them at exactly the same moment