I would like to push messages on to MQ with 800 TPS rate using JMS Publisher in JMETER. Please advice the right approach. I am trying to use constant throughput but I am unable to achieve it.
I am giving like 60*800=48000 within constant throughput timer. But not been able to achieve.
With how many threads (virtual users) defined in Thread Group? 1?
First of all try increasing the number of threads
Constant Throughput Timer can only pause the requests to limit JMeter samplers execution rate to desired value, it won't kick off any extra threads if the current throughput is lower than expected. You can consider switching to Concurrency Thread Group and Throughput Shaping Timer combination, they're capable of it.
JMeter itself needs to be able to send requests fast enough so make sure to follow JMeter Best Practices. If this is not sufficient you will have to go for the distributed testing
Related
I have used the normal thread group of 40 threads,180000 of throughput, and expected TPS is 3000.., But , Resulted only 2750 tps., How can I improve the TPS?
I have tried the concurrency thread group along with the shaping timer combination..
Can u pls guide me..,Thanks in Advance.
TPS or the throughput is controlled by sending the required number of requests to the target server in a unit time (seconds, minutes, hours, etc)
It is not easy or good practice to control the throughput by changing the number of threads. When the server gets slow the throughput gets low and vice-versa.
You need to introduce delays when the server responds faster and introduce more threads when the server responds slower. It is not easy to achieve the desired throughput by setting the thread count.
Please note that
throughput will be lower if the server is not capable of handling it, or if other timers or time-consuming test elements prevent it.
JMeter has a number of ways to achieve the desired throughput by introducing delays to the requests.
Using Timers
Constant Throughput Timer
Precise Throughput Timer
Througput Shaping Timer
In the above cases, you need to ensure a sufficient number of threads are available to generate the required throughputs. This solution is not efficient if a large number of threads are created than the required number of threads.
The best approach would be the test should create additional threads on-demand and introduce delays between requests as required.
In JMeter, you can achieve this with Concurrency Thread Group along with the Throughput Shaping Timer.
This video demonstrate the use of the controllers.
First of all your application must be able to handle such a load. I don't know what your 180000 of throughput, stanza means,if you put it to the Constant Throughput Timer be aware that:
it is precise enough on "minute" level
it can only "pause" JMeter to "limit" its throughput to the given value
In general you can reach out 3000 TPS with 40 users only if 1 user will make 75 requests per second which means that your application response time should be below 75 milliseconds.
If response time will be higher - you won't be able to reach 3000 requests per second with 40 users.
Also JMeter should be able to send requests fast enough, so make sure to follow JMeter Best Practices and if this is not sufficient consider using Distributed Testing
More information: What is the Relationship Between Users and Hits Per Second?
i want to use the Throughput shaping timer for my project in Jmeter to set the "requests per seconds" to any level that i want. i read the article below.
(RPS : requests per second)
https://www.blazemeter.com/blog/using-jmeters-throughput-shaping-timer-plugin
it is useful but not sufficient the uses in real life. anyone doesnt send only one sampler. in my project i send a lot of samplers (http requests) and i want to set the RPS for all samplers in total.
for example if there are 20 samplers and i want set the RPS to 100. what jmeter does now?
should i bring the all samplers under the Throughput shaping timer or what?
i tried this method but i coudnt achieve the numbers even if i increase the number of threads (this was be performed in the article).
JMeter Timers obey JMeter Scoping Rules so it's sufficient to add a single Timer and it will apply the desired throughput to all Samplers it its scope. A good position would be a direct child of the Thread Group
Throughput Shaping Timer per se can only pause JMeter threads to limit execution rate to the given number of requests per second. If you don't have enough threads in order to conduct the required load - it won't be able to do anything about it so either go for Concurrency Thread Group and connect it to the Throughput Shaping Timer via Feedback Function or increase the number of threads so it would be enough in order to deliver the load.
Also remember 2 constraints:
JMeter itself should be able to send requests fast enough so make sure that you're following JMeter Best Practices and JMeter has enough headroom to operate in terms or CPU, RAM, etc.
System under test should be able to respond fast enough as JMeter will wait for the previous response before sending the next request and in case of increased response times the throughput will go down
I have a JMeter test plan with a concurrency thread group and a throughput shaping timer.
below is a screenshot of the test plan.
The post requests are two requests which are sent one after another for a device. there should be 200 transactions/requests needs to sent per sec which I am controlling by target concurrency in concurrency thread group, start RPS and end RPS in the throughput shaping timer.
the total TPS should be 200 ( sum of the first and second requests in the test plan) and the device would be different in each thread. can this be achieved with the above test plan. I see that post-event 2( second post-event in the test plan) are not sent for some of the devices towards the end of the test.
You should be able to achieve the target throughput (RPS) with the Throughput Shaping Timer with the feedback function in the Concurrency Thread Group.
RPS can be set on the Throughput Shaping Timer
This short video demonstrates the use of various options available in JMeter for Throughput Controlling.
Yes, it's possible, but be aware that "Concurrency" in the Concurrency Thread Group is the number of threads (virtual users) and the number of requests per second will be equal to the number of threads only if your application response time is 1 second.
If it's higher - you will need to proportionally increase the "Concurrency" in the Concurrency Thread Group.
More information: What is the Relationship Between Users and Hits Per Second?
You can connect Concurrency Thread Group with the Throughput Shaping Timer via Feedback Function, this way JMeter will be able to kick off extra threads if the current amount is not sufficient in order to reach/maintain the desired amount of requests per second.
Also re-consider using listeners in your test plan, they don't add any value but just consume valuable resources, you should be running JMeter tests in non-GUI mode with all listeners enabled/deleted and once test finishes open the .jtl results file with the listener of your choice or generate HTML Reporting Dashboard
Our requirement is to execute
1 user/thread, 10 requests/sec, Total requests = 10,000
With current Thread Properties not able to achieve.
Only one user/thread send 10 request/sec and total should be 10000 requests. Any other way to achieve this in Jmeter ?
Is following approach is correct ? We used Loop controller. So each request will repeat 10 times
You will be able to achieve 10 requests/second with 1 virtual user only if your response time will be 100 milliseconds. If response time will be more than 100 milliseconds - you will not be able to reach the desired load.
If your application fails to respond in 100 milliseconds time frame - most probably you've found a performance bottleneck and you can report this to your application developers.
If you have some time to investigate the issue you can try to provide more information, i.e. what is the average response time, what are minimum, maximum, quantiles, the actual number of requests per second, etc, all this information can be retrieved using Aggregate Report listener.
Normally when people are looking for the answer if the application under test can support X requests per second they use > 1 virtual user as load test should represent real life usage of the system under test and 1 thread (virtual user) isn't normally associated with performance testing and derivatives.
So probably you should reconsider your approach to testing and try increasing the number of threads (virtual users). The throughput can be controlled using Precise Throughput Timer or Constant Throughput Timer. However be aware that the above timers can only pause JMeter to slow it down to the desired throughput. Another approach is using Concurrency Thread Group and Throughput Shaping Timer combination, they can be connected using Feedback Function so JMeter will kick off extra threads in order to reach/maintain the desired number of requests per second.
You can install Concurrency Thread Group and Throughput Shaping Timer using JMeter Plugins Manager
When I'm doing Jmeter benchmark, the throughput and transfer bytes/sec keep decreasing as time goes by? Who can tell me why?
When the test begins, it has a high throughput , but it decreases all time, and the stable status can't be accessed.
JMeter kicks off threads representing virtual users according to your ramp-up. Each thread starts executing samplers upside down (or according to parent Logic Controllers). When thread doesn't have more samplers to execute and no more loops to iterate it's being shut down.
You can consider the following approaches to implement desired load scenario:
Provide enough iterations via Thread Group or Loop Contoller
Use Ultimate Thread Group which provides easy way of defining a load scenario so you will be able to set initial users number, ramp up duration and users arrival rate, time to hold the load, and define ramp-down.
JMeter provides Constant Throughput Timer which can be used to set precise load in "requests per minute" so you'll be able to control target throughput. You can also use it in conjunction with Beanshell Server - this way you can dynamically change throughput on-the-fly.