I'm writing a JMeter test plan and facing a problem.
Consider having the following structure:
- Thread group
- Uniform Random Timer (in order to make a global timer for all tests)
- Transaction Controller 1
- Action 1
- Action 2
- Transaction Controller 2 (in this controller, I don't want to have timer between each action)
- Constant Timer (set timer to 0)
- Action 3
- Action 4
Unfortunately, it doesn't work : the "Transaction Controller 2" still got a random timer and my constant timer had no effect
My understanding is that with your structure the Uniform Random Timer will execute after every action. In your case, Action 3 and Action 4 will each execute both the Uniform Random Timer AND the Constant Timer.
My approach for this would be to move the Uniform Random Timer into Transaction Controller 1, and have a different timer in Transaction Controller 2
If you are going to have a universal timer, then as far as I know it will be executed on every action in the test plan, and you can not disable it for individual actions. I think it is better to have individual timers for each transaction. If you want the wait time to be the same for all (or most) of the timers, you can always set up a User Definied Variable so you only have to change the time in once place:
Related
In our application total 500 users I want 10 users hit request same time . How to achieve it?
I also used Synchronizing timer and uniform random timer for delay and waiting for user .
can I use both timer in one group?
If you want to execute a certain request by 10 users at the same time - add a Synchronizing Timer as a child of this request and set "Number of Simulated Users to Group by" to 10
Uniform Random Timer can be used in combination with Synchronizing Timer, it will add the configured delay before each Sampler it its scope so if you want to apply the delay before each request - put the Uniform Random Timer just under the Thread Group
I don't know if I have placed the timer at the correct location. I am not able to get Precise Throughput Timer working.
Any JMeter component needs to be placed according to JMeter Scoping Rules
How do you expect the timer to "work" given you have only one thread and one iteration in the Thread Group especially given your test finishes in 500 milliseconds and you configured the test duration as 500 seconds
If you want to limit your test throughput to 1 request per second for 1 thread and 1 iteration only - I can only think of introducing pacing as none of the existing timers won't be able to do this given that short test duration
I want to send 70000 http requests in JMeter, but I want to do it such that I send 50 requests in one go, then pause for around 6 mins, then send the next 50 and so on until I hit a total of 70000 requests
So far, I have tried a couple different configurations to try this, for eg.
- Thread group (with number of threads = 1, Ramp-up period = 1, Loop Count = 1400)
- Loop Controller (Loop count = 50)
- HTTP Request
- HTTP Header Manager
- Constant Timer (Thread Delay (in milliseconds) = 600000)
But this doesn't seem to work. This just seems to fire one request every 1 min (or 600000 milliseconds).
I have also tried
- Thread group (with number of threads = 1, Ramp-up period = 1, Loop Count = 1400)
- Loop Controller (Loop count = 50)
- HTTP Request
- HTTP Header Manager
- Constant Timer (Thread Delay (in milliseconds) = 600000)
But it gives me the same result.
JMeter's elements are all about scopes and execution hierarchy. In order to achieve your goal, you can place your timer in 2 ways
Use "Flow Action Control" Sampler after your HTTP request or in the scope of your Loop Controller or under the scope of your Thread Group (right click on thread group and select "Add Think Times to Children"
Place the timer inside the HTTP Request before which you want the Timer to be executed
Sample Screenshots
Flow Action Sampler
Timer inside a sampler
Why you are facing an issue
Basically below is the hierarchy in which JMeter executes your elements
Configuration Elements
Pre-Processors
Timers
Samplers
Post-Processors
Assertions
Listeners
Source: https://jmeter.apache.org/usermanual/test_plan.html#executionorder
Since timers have a higher execution priority than samplers, they are bound to get executed before a sampler gets executed. In your particular case, you have placed your timer in the scope of both Loop Controller & Thread Group and hence it is getting executed before each element.
Note that timers are processed before each sampler in the scope in which they are found; if there are several timers in the same scope, all the timers will be processed before each sampler.
Timers are only processed in conjunction with a sampler. A timer which is not in the same scope as a sampler will not be processed at all.
To apply a timer to a single sampler, add the timer as a child element of the sampler. The timer will be applied before the sampler is executed. To apply a timer after a sampler, either add it to the next sampler, or add it as the child of a Flow Control Action Sampler.
Source: https://jmeter.apache.org/usermanual/component_reference.html#timers
How the suggested solution works from Timer perspective
Since I am placing the Timer inside a sampler, it gets invoked only before that particular sampler executes. Hence we avoid the timer being applied to every other element
Also, Flow Action Sampler is a sampler itself and hence it gets executed only in the sequential manner and hence when you place it after your respective HTTP request, it will execute only at that instance and hence it will act as expected
How to be used in your Test Plan
With Loop Controller
For my example I am taking a scenario where I simulate 50 requests, wait for 10 seconds and trigger the next bunch of 50 until 500 requests are reached
Added the Flow Action Sampler inside my loop controller
Defined 50 Threads for my sample test
Loop count in Loop controller is 10
Once I trigger the test, during the first second, all my 50 users have ramped up and triggered 50 requests and are now waiting for 10 second duration. Notice the number of samples, thread count and time
During the 7th iteration, 350 requests have been completed and they are about to reach 70th second
At the end of the test, I have 500 requests. Expectation from my test scenario is that post burst of 50 requests, wait for 10 seconds and continue this pattern for 10 iterations. Hence at the end of the test (~100 seconds later), I will have 500 samples completed.
Without Loop Controller
Follow similar test plan as defined with loop controller, only difference being, non-existence of the loop controller and loop count in Thread Group will be defined as 10
In either case, Flow Action Sampler has 10 seconds as Pause time
Hope this helps!
I have a JMeter Test Plan where I am using different Timers like Throughput Timer, Constant Timer & Synchronizing Timer.
Throughput timer is in root of test plan, Where as other timers are only applicable within scope of controllers.
TestPlan
- ThroughPut Timer
-- ThreadGroup
---- Controller-Login
---------- Constant Synchronizing Timer
---- Controller-Action1
---------- Constant Timer (for Think Time delay)
---- Controller-Action2
---------- Constant Timer (for Think Time delay)
Throughput Timer has Target throughput at 180 and it is applied to all active threads. Which means 3 reqs/sec.
Constant Timer is used to give delay between samplers and it has varying delays.
Now, when I run Test plan with only 'Throughput Timer' enabled, then it works fine. I get expected results (approximately 3 reqs/sec) for all requests ( except first one - reasons unknown!) check graph screenshot.
However, when I enable 'Constant Timers' as well, then JMeter fails to control the throughput. Almost all of requests cross 20 reqs/sec mark. check Transactions/sec graph screenshot.
Apparently, it seems that there is conflict when I use 2 or more than 2 type of timers in JMeter. Has any one a solution or workaround for this scenario as I want to implement think-time along with controlling through put.
I am trying to achieve goal of 3 TPS using all my threads. I used Constant Throughput Timer but somehow it doesn't provide constant TPS. It does go beyond 3 TPS like sometime 10TPS.
Test Scenario
Thread Group 1
This Thread group submit XML on server and check the status.
I put constant Timer under this Submit Quote action and set value as 3 per min.
After each Quote Submit i will perform some action.
Thread Group 2
This Thread group submit XML on Server and check the status as like first Thread group but the rest action are different than first.
I put constant Timer under this Submit Quote action and set value as 3 per min.
Thread Group 2
This Thread group submit XML on Server and check the status as like first & Second Thread group but the rest action are different than first & Second.
I put constant Timer under this Submit Quote action and set value as 3 per min.
I need 3 TPS from all these Thread Groups for Submit Quote step, i am able to achieve that somewhat but it's not constant.
Can some please help to manage TPS?
Below is the Graph you can see some high transactions:
CTT will give you "constant" throughput after some time, not in such reduced time as your test shows.
The peak you see come from variation of your server response time.
Maybe you can try this method:
Configure thread group :
Loop count = 1
Ramp up period = time of your test (3600 seconds for my example)
Delay Thread creation until needed = true
Scheduler duration = 3600 seconds
Scheduler startup delay = 0
if you run for 1 hour, to achieve 3 Trans per minute, set number of threads to 180.
I am able to manager this up to some extend by separating actions in to multiple threads. In my earlier example in Thread 1 i was performing some action which impacted CTT. To resolve issue, i am using Queue concept.
First separate your thread's, if any action in your takes time move them to separate thread. In below example actions QuoteStatus and further were part of my thread 1 and due to slow response from server it was not allowing me CTT.
If you look at above response time from Thread one its pretty constant, having multiple actions is one thread cause issues. If your goal is to put constant throughput, it would be good to keep one action each thread and then use Inter_Thread Communication to pass data in other threads.