Is it possible with Jmeter for 300 000 virtual users(PSU) and how?.
I tried with 50 users, later for second time I was able to do only for 10 users.
Is it something with Non-GUI I should work?
First of all follow JMeter Performance and Tuning Tips guide.
Once you have proper JMeter configuration you can figure out what maximum amount of users JMeter instance can handle.
Once you know how many users can be simulated with a single JMeter instance you can consider Distributed Testing when one JMeter server orchestrates a number of JMeter slave machines and collects aggregate response.
By the way, you may not necessarily need to simulate as many as 300 000 virtual users as:
real users don't hammer application non-stop, they need to "think" some time between operations
time to load the page also needs to be considered
So given 300 000 users which wait for 15 seconds between requests and page load time is 5 seconds, it means that each user makes 3 requests per minute (60 / (15 think time + 5 seconds to load the page)).
Assuming above situation 300 000 users will produce 900 000 requests per minute which is 15 000 requests per second which is still high but looks more achievable.
So you can consider switching to so called "goal-oriented scenario" and focus on generating X requests per second load rather than simulating N users. You can precisely define requests per second rate using Constant Throughput Timer.
Related
I am working with 1 master, 50 slaves. Number of threads: 20
I have 1 thread and there are 3 samples in it. I'm starting the tests, but as a result of the test, I see that you are going 500-700 requests.
1000 requests from each should go. But it doesn't go.
You have 20*50=1000 threads in total.
You can reach 1000 requests per second only if response time is 1 second sharp.
If response time will be 0.5 seconds - you will get 2000 requests per second
If response time will be 2 seconds - you will get 500 requests per second.
If you need to simulate X requests per second you need to add more threads (or alternatively go for Concurrency Thread Group and Throughput Shaping Timer combination)
But remember that the application under test must be able to respond fast enough because if it doesn't - any JMeter tweaks won't make any difference.
By the way, 1000 requests can be simulated from a modern mid-range laptop without any issues (unless your requests are "very heavy"), just make sure to follow JMeter Best Practices
i've started distributed performance testing using jmeter. If i give scenario 1:
no.of threads: 10
ramp up period: 1
loop count: 300
Everything runs smooth, as scenario 1 translates to 3000 requests in 300 seconds. i.e. 10 requests per second.
If i give scenario 2:
no.of threads: 100
ramp up period: 10
loop count: 30
Afaik, scenario2 is also executing 3000 requests in 300 seconds, i.e. 10 requests per second.
But things started failing i.e. sever is facing heavy load and requests fail. In theory both scenario1 and scenario2 should be same, right? Am i missing something?
All of these are heavy calls, each one will take 1-2 seconds under normal load.
In ideal world for scenario 2 you would have 100 requests per second and the test would finish in 30 seconds.
The fact that in 2nd case you have the same execution time indicates that your application cannot process incoming requests faster than 10 per second.
Try increasing ramp-up time for 2nd scenario and look into the following charts:
Active Threads Over Time
Response Times Over Time
Transactions Per Second
Normally when you increase the load the number of "Transactions Per Second" should increase by the same factor and "Response Time" should remain the same. Once response time starts growing and number of transactions per second starts decreasing it means that you passed the saturation point and discovered the bottleneck. You should report the point of maximum performance and investigate the reasons of the first bottleneck
More information: What is the Relationship Between Users and Hits Per Second?
In scenario 2 after 10 seconds you have 100 concurrent users which execute requests in parallel, your server may not handle well or prevent such load
Concurrent user load testing sends simultaneous artificial traffic to a web application in order to stress the infrastructure and record system response times during periods of sustained heavy load.
In scenario 1 after 10 seconds you have 10 concurrent users looping through the flow, without causing a load on server
Notice your server may have restriction on number of users requesting only on specific request(s)
We shall be very clear about the Rampup time
Following is extract from the official documentation
Scenario 1 : no.of threads: 10
ramp up period: 1
loop count: 300
In the above scenario 10 threads(virtual users) are to be created in 1 seconds. Each user will loop 300 times. Hence there will be 3000 requests to the server. Throughput cannot be calculated in advance with above configuration. It fluctuates based on the server capability, network etc. You could control the throughput with some components and plugins.
Scenario 2 : no.of threads: 100
ramp up period: 10
loop count: 30
In scenario 2 100 threads (virtual users) are created in 10 seconds. 100 virtual users will send requests concurrently to the server. Each user will send 30 requests. In the second scenario you will have higher throughput (number of requests per seconds) as compared to the scenario 1. Looks like server cannot handle the 100 users sending requests concurrently.
Ramp up time is applicable for the first cycle of each thread. It will simulate delays between first request of each user in their first iteration.
Is that possible to execute 10000 concurrent user in jmeter?
If so how?
What should be the ram-up time for this scenario??
JMeter's limit of virtual users per Thread Group is very high, to be precise it's 2,147,483,647
The question is: do you have good enough hardware to simulate 10 000 users from a single machine. The process of checking it looks as follows:
Make sure to follow JMeter Best Practices
Set up monitoring of the CPU, RAM, Network, Swap, Disk usage on JMeter side, it can be done using JMeter PerfMon Plugin
Start with 1 virtual user and gradually increase the load at the same time looking into CPU, RAM, etc. usage. Here there could be 2 options:
you will be able to reach 10 000 users without issues, if this is the case you should be good to go
you will run out of resources earlier, in this case look into i.e. Active Threads Over Time listener to see how many users you were able to simulate from this machine and extrapolate the value to determine how many load generators you will need for 10 000 users using Distributed Testing approach
There is no golden rule for ramp-up time calculation, the good practice is to onboard the users gradually, this way you will be able to correlate increasing load with increasing response time, increasing number of errors, etc. Adding 3 users each second so in 1 hour you will have 10 000 seems a valid starting point to me.
Hellow
Which is the maximun number of virtual users that can be testet at a Jmeter distributed test? Is it possible to reach one million of virtual users?
Thak you.
It depends on may factors, technically the limit on JMeter end is very high (I think it should be 231 − 1 or 2 147 483 647 virtual users)
Nature of your application: use cases, is it more about consuming ore creating content, average request and response size, response time, etc.
Nature of your test: again, request and response size, need to use pre/post processors and assertions
Hardware specifications of your load generators
Number of load generators
So I would recommend the following approach:
Start with a single JMeter instance
Make sure you have optimal JMeter configuration and amended your test according to JMeter best practices
Make sure you have monitoring of baseline OS health metrics on that machine
Start with 1 virtual users and gradually increase the number of running users until you start running out of hardware resources (CPU or RAM or Network or Disk IO will be close to maximum)
Mind the number of active users at this stage (you can use i.e. Active Threads Over Time listener) - this is how many users you can simulate for particularly that test scenario. Note, the number might be different for other application or other test scenario.
Multiply the number you get by the number of the load generators you have - if there is > 1M - you are good to go.
If you won't be able to simulate that many users there is a workaround, but personally I don't really like it. The idea is that real users don't hammer application non-stop, they need some time to "think" between actions. Normally you should be simulating these "think times"using JMeter Timers. But if you lack load generators you can consider the following:
Given 1 virtual user needs 15 seconds to think between operations and response time of your application is 5 seconds, it means that each user will be able to execute only 3 requests per minute. So 1M of users will execute 3M requests per minute which gives us 50 000 requests per second which is also high, but more likely to be achievable.
I have started 300 requests per second by providing following values:
Number of Threads : 300
Tamp-up : 0
But I am getting following results:
summary + 55 in 21s
summary + 225 in 31.1s
summary = 280 in 31.1s
what different configurations would be needed to start all requests in one go?
IMHO, you have to take in account the time it takes to run the transaction itself.
I tend NOT to use synchronization, but to take measure on longer period of time, e.g. 15 minutes.
E.g., if your system is able to deliver one page in 2 seconds, you need to run AT LEAST 600 threads to deliver the throughput you want (probably more).
Also, remember that the time of a single page increase with the load, so a single measurement is not enough, AND take care of errors: you have to define an acceptable threshold for errors (e.g. 0.01%), and stop measurement when you go above that.
If you need to start all 300 requests at the same moment you need to use Synchronizing Timer
If you need provide constant load at 300 requests per second rate - you'll need Constant Throughput Timer
Two above would cover the majority of use cases, however if you want more control on your load pattern look into Throughput Shaping Timer (available through JMeter plugin)