Nick Danielsson wrote:
Hello!
As the subject suggest I'm having trouble getting the expected
throughput when I pass 6000 samples/min to the Constant Throughput
Timer, it seems between 6250-10500 samples/min the throughput is
usually lower then expected but when it is at 11000 samples/min or
above the throughput is always higher then expected.
I have a testplan with 3 scenarios, the setup is the same for all 3
and they read from the same testdatasource (csv-file) via CSV Data Set
Config.
We have a setUp Thread Group where we set some propertys, throughput,
thread count, test scenario, etc, with some JSR223 PreProcessors and
JSR223 samplers, then the "main" Thread Group begins. It contains the
following in order:
/Constant Throughput Timer/ - with target throughput =
${__property(Tpm)} (set as a property in the setUp depending on
scenario), and Calculate Throughput based on = all active threads (shared)
X3 /If Controllers/ - One for each scenario. Each If Controller have X
amount of /Throughput Controllers/, one for every HTTP Request to make
sure the distribution of requests reflects production. In the
Throughput Controller we have a /Module Controller/ pointing to a
/Test Fragment/ containing that specific HTTP Request. All of these
Test Fragments are located in the Test Plan root outside of the main
Thread Group and almost everyone of the Test Fragments are made up of
a single HTTP Request.
That's basically it, every scenario is built the exact same way. Now
to the problem.
The first scenario has a throughput of 2400 samples/min (40
samples/sec), 20 threads and works great, perfect distribution of both
HTTP requests and throughput, no problems here.
The second scenario has a throughput of 14000 samples/min (233,3
samples/sec) 50 threads, the distribution of requests are perfect but
the throughput is always off by about 1000 samples/min (16,6
samples/sec) *higher* than what is set in the constant throughput timer.
The third scenario has a throughput of 10200 samples/min (170
samples/sec) 50 threads, the distribution of requests are perfect but
the throughput is off here as well, not by as much but till by about
500 samples/min *lower* than what is set in the constant throughput timer.
I have tried with increased amount of threads and lower amount of
threads, but this doesn't affect the outcome.
I've tried changing the throughput and I get some strange results from
it, when the throughput is at or above 11000 it seem to always result
in about 1000 samples/min *higher* then what was set. When the
throughput is at between 6250 - 10500 it usually results in an output
that is around 200 - 500 samples/min *lower* then what was set.
There seem to be some cut off happening around 6000 samples/min
because when I run tests with that throughput or lower they're close
to perfect.
I've been monitoring the server generating the load and the test
target servers and they all show no sign of overworking.
We use 1 server to generate the load and it runs Jmeter 5.6.2
Kind regards, Nick
PÖverväg miljöpåverkan innan du skriver ut detta e-brev.
Vill du veta hur Pensionsmyndigheten hanterar dina personuppgifter? Se
myndighetens webbplats
<https://www.pensionsmyndigheten.se/om-pensionsmyndigheten/allmanna-handlingar/om-personuppgifter>.
1. In order to be able to run Samplers using different "throughputs"
you need to put them under different Thread Groups
<https://jmeter.apache.org/usermanual/component_reference.html#Thread_Group>,
JMeter waits for the previous response before sending the next
request therefore the sequence of the requests will be run at the
speed of the slowest request
2. Constant Throughput Timer is only capable of *pausing* the threads
in order to *limit* Samplers execution speed to the desired value,
it will not kick off extra threads if the current amount is not
sufficient for conducting the required load. If this is your case
either increase the number of threads or consider switching to
Concurrency Thread Group
<https://jmeter-plugins.org/wiki/ConcurrencyThreadGroup/> and
Throughput Shaping Timer
<https://www.blazemeter.com/blog/jmeters-shaping-timer-plugin>
combination.
3. There is Precise Throughput Timer
<https://jmeter.apache.org/usermanual/component_reference.html#Precise_Throughput_Timer>
which is more "precise" especially when your test lasts less than 1
minute or you change the throughput property frequently.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
For additional commands, e-mail: user-h...@jmeter.apache.org
