You could use ConstantThroughputTimer.
Quote from JMeter help files below:
18.6.4 Constant Throughput Timer
This timer introduces variable pauses, calculated to keep the total throughput (in terms of samples per minute) as close as possible to a give figure. Of course the throughput will be lower if the server is not capable of handling it, or if other timers or time-consuming test elements prevent it.
N.B. although the Timer is called the Constant Throughput timer, the throughput value does not need to be constant. It can be defined in terms of a variable or function call, and the value can be changed during a test.
For example I've used it to generate 40 requests per second:
<ConstantThroughputTimer guiclass="TestBeanGUI" testclass="ConstantThroughputTimer" testname="Constant Throughput Timer" enabled="true">
<stringProp name="calcMode">all active threads in current thread group</stringProp>
<doubleProp>
<name>throughput</name>
<value>2400.0</value>
<savedValue>0.0</savedValue>
</doubleProp>
</ConstantThroughputTimer>
And thats a summary:
Created the tree successfully using performance/search-performance.jmx
Starting the test @ Tue Mar 15 16:28:39 CET 2011 (1300202919244)
Waiting for possible shutdown message on port 4445
Generate Summary Results + 3247 in 80,3s = 40,4/s Avg: 18 Min: 0 Max: 1328 Err: 108 (3,33%)
Generate Summary Results + 7199 in 180,0s = 40,0/s Avg: 15 Min: 1 Max: 2071 Err: 378 (5,25%)
Generate Summary Results = 10446 in 260,3s = 40,1/s Avg: 16 Min: 0 Max: 2071 Err: 486 (4,65%)
Generate Summary Results + 7200 in 180,0s = 40,0/s Avg: 14 Min: 0 Max: 152 Err: 399 (5,54%)
Generate Summary Results = 17646 in 440,4s = 40,1/s Avg: 15 Min: 0 Max: 2071 Err: 885 (5,02%)
Generate Summary Results + 7199 in 180,0s = 40,0/s Avg: 14 Min: 0 Max: 1797 Err: 436 (6,06%)
Generate Summary Results = 24845 in 620,4s = 40,0/s Avg: 15 Min: 0 Max: 2071 Err: 1321 (5,32%)
But I run this test inside my network.
Firstly, short definition of each parameter:
Number of Threads: simulates the number of users
Ramp up period : how much time Jmeter takes to get all threads started
Loop count: number of times each thread performs the test case
Duration in scheduler: the duration for which the test is to be run. In this case, the value in the end-time field shall be ignored and the relative end-time will be calculated from the start-time and duration
A important thing to understand here is that the Ramp-up period has no relation to the Loop count. It is only related to the Number of Threads. If there are 10 threads and a ramp-up time of 100 seconds, then each thread will begin 10 seconds after the previous thread started, for a total time of 100 seconds to start all threads in the thread group.
Now the answer to each Thread Group Case:
Thread Group 1: # of threads:1, ramp up period:0, loop count:5, no scheduler
Thread Group 2: # of threads:5, ramp up period:0, loop count:1, no scheduler
Thread Group 3: # of threads:1, ramp up period:1s, loop count:5, no scheduler
Thread Group 4: # of threads:5, ramp up period:5s, loop count:1, no scheduler
Thread Group 5: # of threads:1, ramp up period:1s, loop count:forever, duration in scheduler:5s
Thread Group 6: # of threads:5, ramp up period:5s, loop count:forever, duration in scheduler:5s
Q1. Is there any difference between thread group 1 and 2?
Thread Group 1 has a single thread that will repeat the same test 5 times i.e. as one test finishes repeat the test till a loop count of 5 is reached
Thread Group 2 has 5 threads that will start simultaneously as the Ramp-up Period is 0, so there it shall mock 5 users simultaneously on the system
Q2. How long is the time cap between each loop?
The time cap is a factor of the ramp-up period that is divided equally between the number of threads in the thread group. Loop is a continuous process that shall continue till the loop count is reached. "Time cap" is not a term used in the JMeter docs, but assuming what you mean, it can be set between loops by using Test Action or other JMeter mechanisms if you need fine-grained control.
Q3. Is there any difference among thread group 3, 4, 5 and 6?
Yes, all the parameters are different, so as described above, the behavior is different.
Q4. Should group 3, 4, 5 and 6 all take 5 seconds to finish sending all requests? Should the total # of results be 5 in each group?
No, it is all subjective to each condition.
In Thread Group 3, a single thread shall execute the same thread 5 times, so no control over time
In Thread Group 4, there are 5 thread and based on the ramp-up period, each thread shall start 1 s after the other, so it will take at-least 4-5 seconds to complete the test (after the last test)
Thread Group 5 and 6 shall each only run for a duration for 5 seconds. If the test is completed before that then fine, otherwise the test shall be terminated and stopped
Q5. When I tried thread group 5, I got around 83 responses, why is there not just 5 responses? Does this mean the ramp up period is not working?
Why should there be only 5 responses??? Thread Group 5 shall create a single thread that shall execute the test in loop for ever. If the duration was not defined the test would run in an infinite loop. Since the duration is defined, the test shall only run for the duration period.
Note to All: The loop count is thread specific. It specifies the number of times the test should be repeated for each thread. The ramp-up period is related to the #Thread (User) and has no relation to the loop count
Best Answer
I researched this today and came to this conclusion: The Loop Count setting is a complete misnomer. It doesn't actually loop in any sort of chronological sense, even if your Test Plan has Run Thread Groups consecutively checked. What it does do is multiply your thread group and run all multiples concurrently. Therefore, the Ramp-Up Period is only respected once, and NOT once per "loop" - there is no temporal loop!
An explanation with graphs can be found here: http://pro-programmers.blogspot.com/2009/07/jmeter-max-threads-with-rump-up-and.html