I have a HTTP Request in my Thread Grpup that takes around 20 to 30 seconds to complete with a single user, so when I added 50 users I get a 500/Internal Server Error or 503/Server has been shutdown sometimes.
I want to add a Constant Timer with 40 seconds (in miliseconds) under the HTTP Request so maybe the application will have some time to process it. I am going to the rigth way?
If I add the Constant Timer will it be calculate as well in the Summary Report?
I need that the Jmeter give the time to the API (My aplication) complete the process (need at least 30 seconds) and it may be or not affetct my Summary Report
PreProcessors, Post-Processors and Timers are not counted in the Elapsed time. so response time will not be impacted.
However Throughout (the number of requests for the test duration) will be lower.
See JMeter Glossary for more information on the above metrics.
With regards to "right way" - real users don't "hammer" application non-stop, they need some time to "think" between operations so if you're simulating a real user you should have non-zero think time, however 40 seconds it kind of too much for me. Take a look at How to make JMeter behave more like a real browser article for more tips on properly configuring your JMeter test.
Related
Ok so I am experiencing an issue where I am supposed to ramp up 10 vusers in 1 minute till it reaches 200 Vusers and hold the load for 60 minutes. However, as it calls 200, it is calling all of them concurrently which is affecting the performance of my test. Right now, I want to call the 200 vusers which each users being called with an interval timing in between instead of one shot concurrent call.
The real users don't hammer the system under test non-stop, they need some time to "think" between operations.
Well-behaved JMeter test must mimic real user using a real browser with 100% accuracy including cookies, headers, cache, etc.
This "think time" is also uber-important, real users need to read the content of the page before navigating to the next one. If they're supposed to type/write/upload something - they will need even more time.
So in order to accurately simulate this "think time" you need to add a suitable Timer(s) and configure them properly in order to introduce reasonable delays between requests.
I want to run basic load testing scenario on a mendix application.
The initial requirement is at least 10 users should be able to perform some activities like login , file upload concurrently.
I have used the webdriver sampler in Jmeter with selenium and written the JS script for the actions.
The issue is it launches 10 browser on the same machine.
Please suggest the proper way to handle this. Currently it seems that the errors which I am getting are because of I am running the test on my laptop instead of distributed setup.
Also the total script takes 60 seconds to finish for single user. What should be the ramp up time?
If not Jmeter, please suggest any other suitable tool for this scenario.
As per The WebDriver Sampler: Your Top 10 Questions Answered article
Q. How do I Allocate the WebDriver Sampler?
A. First of all, don’t use the WebDriver Sampler to create the load! You’ll need around 1 CPU core per virtual user to keep the JMeter resource consumption within an acceptable range. The WebDriver Sampler should be used in addition to HTTP Request Samplers. Here’s an example of how it should be used:
1,000 of users are simulated by HTTP Request Samplers
1 user is the WebDriver Sampler
You should use the WebDriver Sampler to evaluate a real-life user experience. It’s most commonly used to measure the load times of pages when the system is experiencing high loads. The HTTP Request doesn’t really “render” the page and it can’t execute JavaScript. That’s why the WebDriver Sampler is so valuable - JMeter isn’t a browser and it overcomes limitations posed by this fact.
So first of all I would recommend re-considering your approach and migrating to HTTP Request samplers, you might be able to execute 10 browsers but if you will need to scale your test to 100 or 1000 users you will definitely won't be able to use this "real browser" approach while HTTP Request samplers act on HTTP protocol level, given you properly configure JMeter it will be no difference for the application under test whether the requests are originating from JMeter or from the real browser and the resources footprint will be much less.
With regards to the ramp-up time: the overall idea is to increase the load gradually so you could correlate the changing number of virtual users with changing metrics like response time, throughput, etc. According to JMeter Documentation:
The ramp-up period tells JMeter how long to take to "ramp-up" to the full number of threads chosen. If 10 threads are used, and the ramp-up period is 100 seconds, then JMeter will take 100 seconds to get all 10 threads up and running. Each thread will start 10 (100/10) seconds after the previous thread was begun. If there are 30 threads and a ramp-up period of 120 seconds, then each successive thread will be delayed by 4 seconds.
Ramp-up needs to be long enough to avoid too large a work-load at the start of a test, and short enough that the last threads start running before the first ones finish (unless one wants that to happen).
Start with Ramp-up = number of threads and adjust up or down as needed.
Need help on JMeter response result from the image
My scenario: Am calculating Min/Max/Average response time on Api creating a user account.
1.Login to site
2.Using API request creating a user account - (creating 100 users account using API)
3.Logout.
Observation :
Total elapsed time is 32 mins (which is there in the image).
Response time for 100 users is 90852.
I need to understand how the response time units are measured here.
does 90852 milliseconds mean approximately 90secs.
So is it like a single user account is created in 90 secs by the API?.
So, please tell me how response time is working here when it compared with total response time?
Thanks :)
The average creation of a user took your API 908 ms (the entry with 100 samples ending with /api/users).
Since the line (where the name of the transaction is not in the screenshot) has the sample count 1 and the response time resembles 100*908ms I would guess that you have a Transaction Controller that holds the Loop Controller.
The same hierarchy that you use to organize your test plan also applies to transaction controllers and samplers. So if you group several samplers - and/or transaction controllers - under a parent transaction controller, that parent transaction controller will have the combined response time of all its children.
Response time for 100 users is 90852. - No, only for 1 user. Looking at your image it appears that only 1 sample was collected during 32 mins. So this response time is for that 1 sample not for all 100 users. JMeter only shows you completed responses. Assuming you have a thread group of 100 users, the rest didn't complete / were waiting for the api to respond.
Does 90852 milliseconds mean approximately 90secs. - yes. In your api you seem to be using once only controller for login and authenticate and everything else seems to be running sequentially. So if you are load testing have a slow api response then you won't be able to measure other throughput for the rest of the apis correctly as the slowest api will hold up the thread for a long time.
Hope this helps.
It is hard to provide comprehensive analysis without seeing your Test Plan.
When it comes to your questions:
Total elapsed time is 32 mins (which is there in the image).
this looks a little bit high for me, given you create 100 user accounts and average response time is 908 milliseconds I would expect that your test will finish in 90.8 seconds which is 1.5 minutes.
does 90852 milliseconds mean approximately 90secs.
it rather looks like a sum of all 100 response times most probably you got it from the Transaction Controller
Average Response time is basically arithmetic mean, to wit sum of all response times divided by their count.
First of all you need to understand why does you test take that long.
You seem to be creating 100 user accounts using 1 thread (virtual user) in loop, you might want to consider doing it with multiple threads instead
You should be using JMeter GUI only for tests development and/or debugging, when it comes to test execution you should be running your JMeter tests in command-line non-GUI mode like:
jmeter -n -t test.jmx -l result.jtl
I'm load testing a system with 500 virtual users. I've kept the "Ramp-Up period (in seconds)" option to zero. So, what I understand, JMeter will hit the system with 500 virtual users all at the same time. Please correct me if I'm wrong here.
Now, the summary report shows the average response time for the first page is ~100 seconds!. Which is more than a minute and a half of wait time. But while the JMeter is running, I manually went to the same page/url using a browser and didn't have to wait for that long. It was not even close, the page response was almost immediate for me.
My question is: is there any known issue for the average response time of the first page? Is it JMeter which is taking long to trigger that many users?
Thanks in advance.
--Ishtiaque
There is no issue in Jmeter related to first page response time.
Summary Report shows all response time details in Milliseconds, the value "100" seconds have you converted milliseconds to seconds?
Also in order to make sure that 500 users hit concurrently, use Synchronizing Timer.
Hope this will help.
While the response times will be accurate, you need to consider the affect of starting so many threads at once on both your server and your client.
500 threads to start at once is not insignificant n the client. If your server has the connections, it will start 500 threads as well.
Ramping over a period of time is more realistic loadwise, but still not really indicative of server capability until the threads have all started and settled in.
Databases can also require a settling in period which can affect response times.
Alternative to ramping is introducing a random wait at the start of each thread before firing the first sample. You can then choose not to ramp over time, but still expect resources on the client to suddenly come under load and change the settings if you hit limits. This will make the entire run much more realistic of typical behaviour. However, you need to determine if your use cases are typical.
Although the heap size is increased, i notice there is still longer time as compared to actual response time. Later i realised it was the probe effect (the extra time a tool generates due to test execution)
I have a jmeter test with about 50 users. the beginning of the test performs a login and some set up stuff. I don't want this all to happen at the same time as there would be way too much contention for a part of the test I am not interested in. So I have a ramp up period of 10 seconds. There is then one specific HTTP request where I want the 50 users sending over 1 second interval i.e. a HTTP request every 20 ms. This is to ensure the 50 users are excuting this part concurrently. Ideally, something like a thread.join() after the login / ramp up would help out here, followed by another guassian timer.
Is there something similar to thread.join() in jmeter?
To mimic thread.join you can use a Synchronising Timer, this will block n threads until they reach a point and then execute them all at the same time.
If you want this request load of 1 every 20ms to continue (rather than a single burst) then you can use a Constant Throughput Controller to define the actual rate of requests you want JMeter to run. You can configure each thread to run at a rate of 60 requests per minute and this will give you one hit every 20ms (based on 50 threads with response times always less than 1 second). You can also tell JMeter to just make sure your load is 1/20ms no matter how many threads you use and it will dynamically adjust. This option is perhaps more useful in the context of load testing.
Note. When using a CTT controller, you would probably want to put the login request either in a Once Only COntroller or in a setup thread group.