I know that transaction controller is uage to logically group multiple samplers and it generate a sampler of itself. However I have a question on script performance optimization.
How advisable it is to use Transaction Controller if I have only Sampler in it? Does it impact the memory badly if I have 10s of those in the a thread group. Any link to best practice regarding the same will be appreciated.
Each element has its cost. Transaction Controller's cost is relatively low, it's just generating a virtual SampleResult plus adding metrics from each and every child to this virtual sampleresult plus sending the signal to the Listeners (if any)
There is no sense of having a Transaction Controller with only one child Sampler because it's response time, throughput, etc. will be absolutely the same as for its only child.
I wouldn't say that the number of Transaction Controllers in the Test Plan matter, it's more about the number of Samplers which are under the Transaction Controller (a little bit higher memory consumption, a little bit lower throughput), however if you properly configure JMeter you won't see any visible impact.
The only way to see the side-effect of having Transaction Controllers in the Test Plan is running your test with and without them under profiler tool telemetry
Related
I have read the user guide, here or on Blazemeter blogs regarding usage of flow action to implement dynamic pacing in Jmeter script with help of a JSR223 timer. I wanted to check if I can use JMX dummy sampler to implement the same JSR223 timer?
Does it really impact performance if using Dummy Sampler vs Flow Action in performance test scripts as both are samplers only. Please advise and any support link would be appreciated.
Impact performance of what?
"Pacing" is yet another approach to control the number of hits per second by slowing down the requests for whatever reason (not to overwhelm the application, send desired number of requests per second, etc.)
Any implementation of "pacing" is "killer" of the performance because it adds a pause between iterations instead of starting new iteration immediately so your question doesn't make a lot of sense. If you want to use the most resource efficient solution - you need to either share your implementation details for these 3 approaches or better measure it yourself using a profiler tool
If you're looking for a easier/better way of sending requests at constant rate instead of implementing the "pacing" I would rather recommend considering using of the following test elements:
Constant Throughput Timer
Precise Throughput Timer
Throughput Shaping Timer
While understanding concept of Concurrent thread and ultimate thread group, i am confused to understand result of summary/aggregate report while running concurrent thread or ultimate thread group .For example if i have 200 user and ramp up time 60 sec then i didn't see all sampler request as 200 sample after completing execution successfully but only few sampler request have 200 sample. when i use normal thread group then i always got thread count same for each sampler request after completing execution .
for realistic load testing with more user , could you please suggest me which thread group should prefer.
Could you please provide valuable guidance with some valuable link/book and also share me standard performance bench mark criteria or key parameter detail while doing load testing.(if any bench load parameter value does not meet standard then we can say that there is a performance issue)
Thanks for giving valuable time in advance.
Thanks
amit
This is due to the fact that:
Your application response time is too high
Your test duration is too low
For example I can see response times > 80 seconds:
it means that if a single virtual user has cumulative response time for 2 samplers > 160 seconds and the test duration is 120 seconds it will not be able to execute all the requests. Just increase your test duration to be i.e. 10 minutes and you should see more virtual users capable of executing all the Samplers you defined in the test plan.
Also given first user is capable of executing all the requests successfully and in time it looks like that your application gets overloaded hence cannot respond fast enough when the number of concurrent users reaches some "critical threshold", you can add listeners like Active Threads Over Time and Response Times vs Threads, this way you will be able to correlate increasing load with the increasing response time.
If also makes sense to collect:
Baseline health metrics of your application (CPU, RAM, Network, Disk usage, etc.), it can be done using JMeter PerfMon Plugin.
Lower level details like slowest methods, largest objects, heaviest database queries, etc. This form of information can be obtained using profiling tools specific to your application programming language(s).
I am trying to configure a test for signup-login with invalid credentials imitating bruttforce attack. However, I want to make requests as a single user.
So the scenario is the next:
Request to sign up with valid params;
Attempt to log in with invalid params in a loop.
I am adding throughput timer but then I need to set up a high number of threads to generate for example 1 request per second.
How can I set exactly one user and run only one request per second in a loop?
UPDATE - SOLUTION
Everything was rather simple but still strange for me.
Maybe someone will face the same problem.
To get a number of requests per one user throughput timer should be placed not inside the controller but inside the thread itself.
To achieve Target Request Per Second use Throughout Shaping Timer : How to use Throughput Shaping Timer
JMeter Plugin link : Download from here
Few Important Notes:
JMeter threads of Thread Groups in scope of the Element will be
stopped when RPS schedule finishes.
Provide enough working threads for your RPS, JMeter timers can only delay threads (and limit RPS). You may pair this plugin with Concurrency Thread Group using Schedule Feedback Function to dynamically maintain thread count required to achieve target RPS.
If you're using versions of JMeter lower than 3.3 and if you have RPS that lower at the end of test, make threads to lower also. Оtherwise you'll have a spike in last second.
Avoid using zero RPS value as start of test, this produce spike also
Avoid zero RPS during the test, this may lead to nasty effects
Now, practical example showing 1 RPS for 1 User:
You might want to reconsider the location of the timer, it obeys JMeter Scoping Rules so it gets applied to all Samplers which are in your Thread Group.
If you want to apply it to only one - make it a child of the relevant sampler.
Also be aware that Constant Throughput Timer is precise enough on minute level so you might want to switch to the Precise Throughput Timer
We are creating a new hosted server for one of our APIs on managed containers (Kubernetes) and we're trying to validate that it can handle at least the same amount of traffic load requests.
We've started with one of the APIs, where we would need to handle at least 140k requests per minute, all endpoints combined.
To verify this, I created a simple JMeter test as follows:
-Test Plan
---Thread Group Endpoint1
-----HTTP Request -> a GET request with query params for /path1
---Thread Group Endpoint2
-----HTTP Request -> a GET request with query params for /path2
For a local test, I used the following setup:
Thread Groups Endpoint1 and Endpoint2 are set to 200 threads (users), ramp-up period of 1s, loop count = forever and duration 60s.
Using a Summary Report listener when running the test gets me a total of ~9300 # Samples.
Using this approach, is it safe to just increase the number of threads (users) for the Thread Groups until I reach the desired 140k requests per minute?
Note: I only used JMeter a little before, so I'm aware that the entire approach may be wrong, therefore any suggestions and steering to the right path are more than welcomed.
Your approach is viable as long as it represents real-life application usage. If it has 2 endpoints with equally/evenly distributed load - your setup is just fine. If there are more endpoints and some of them are used more than the others - consider defining the workload correspondingly either using different Thread Groups or other distribution mechanism such as Throughput Controller
Increasing the number of threads is also fine, however consider increasing the load gradually, to wit increase ramp-up time so your test could have:
Arrivals phase
Time to hold the load
Ramp-down phase
This way you will be able to correlate various metrics like increasing response time, throughput, number of errors, etc. with the increasing load. Also you will be able to state what was the number of threads/requests per second when the system reached saturation point/breaking point and does it recover when the load gets back.
Also make sure you're following JMeter Best Practices as 2300/2500 requests per second is not something JMeter can support out of the box and you will need to do some tuning, at least increase JVM Heap size allocated to JMeter.
You may not be able to achieve the desired 140k requests per minute using a single Jmeter Machine, in that case you'll need Distributed Load Testing approach here.
refer: http://jmeter.apache.org/usermanual/jmeter_distributed_testing_step_by_step.html
Also keeping the ramp-up period of 1 second will lead to spike and unrealistic load in the system which will not give proper result unless you've pre-warmed your server, you should gradually increase the load as per real/estimated traffic pattern.
I'm trying to understand the basics of JMeter. I've got a "plus1" Java servlet that adds one to a request parameter and returns the result, so it's a fast test servlet just so I can understand load testing.
Here's my test plan:
Thread Group: 1 thread, ramp up 1 s, loop count 10000
HTTP Request to localhost
Graph Results
Summary Report
When I run this, the summary report shows a throughput number of 200/sec or so.
The key question, with no controllers in the test plan, is JMeter running the test plan (sending a single request) and waiting for the response before looping?
When I introduce a more computationally intensive page for the request, the throughput number goes down as I would expect.
In short, yes.
There is an argument for having a sampler that would make a request and not wait for the response but it's an edge case. In most cases you would want a testing tool to wait to see what happens and verify things. It's also more realistic, most users will wait for a response, in fact they generally have to, before making subsequent calls.
If you want to run a capacity test then the best approach, I think, is to spread the load over multiple threads and to actually throttle the throughput of each one - you can do this using a Constant Throughput Controller. Eg. You could have 500 threads each running at 60 requests per minute, this would give a total load of 500 reqs/sec. This way, your test load is predictable and stable - it won't be linked to the speed of response from the server. Note. with multiple threads you'll want a ramp up period and you might find you have to spread the test over multiple machines (known as 'distributed' testing if you're going to google it).