I am using JMeter 2.11 for simulate 10000 thread users. I use CSV data set config to simulate 10000 user load and take 2-3 HTTP request in my test plan. All 10000 user load applied successfully by Jmeter but main problem is when my last request goes idle (as I put my Jmeter http request on home page of my website) all sessions goes timed out after some time.
I also configure "app pool's Idle time out=0" and my application's web config's "session state timeout is 20" (I also increase this time from 20 min but no way). Also Keep Alive is checked on all http request.
Please suggest me what to do for keep my last request's session alive.
JMeter threads are never idle, if thread doesn't have any more samplers to execute or no more loops to iterate it's being shut down. 10 000 users is quite a high load, it might be a problem with your JMeter configuration, i.e. it is not capable of generating and sustaining 10 000 threads. In 99% of cases jmeter.log file has enough troubleshooting information.
In the meantime few recommendations:
Upgrade to the latest version of JMeter (for the moment it's Apache JMeter 2.13)
Make sure you use 64-bit server JRE or JDK
Provide JMeter enough Java Heap space, by default it comes with 512Mb only which is not enough to simulate 10k users
Run JMeter test in non-GUI mode
Disable all Listeners during test run
See 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure for above points explained and few more tips and tricks.
Related
I run a performance test with load 25 users with jmeter integrated with jenkins.Once the build is triggered all my thread groups are completed but the console process is running for close to 2 hours.
image here
In your image I see 500 users, not 25.
Also I see that 498 users have finished and 2 are still running.
I cannot state for sure why they are running, it's more a question to you. I can think of the following reasons:
You're not following JMeter Best Practices
JMeter lacks resources and got stuck i.e. in endless garbage collection (which is a subset of point 1)
JMeter waits for response from the server and the server fails to respond. By default JMeter's HTTP Request samplers don't have any timeout defined and it means that JMeter will wait forever, so make sure to set reasonable connect/response timeouts, the setting lives under "Advanced" tab of the HTTP Request sampler (or better use HTTP Request Defaults so you could set the timeout for all the HTTP Request samplers in one shot)
If nothing helps you can check what exactly threads are doing and where they're stuck by taking a thread dump
I am running a load test using JMeter with 200 users for approx 1hr. So, the observation is that a few threads are stuck even after the duration completes. Like 60 out of 200 get stuck. When I take the thread dump and observe that these threads are in a Runnable state. Any suggestions for resolving this issue? And I do not see anything meaningful from the JMeter log file.
You will find an unexpected increase in response time at the end of that time.
This is because of the thread's insufficient ramp-down time. Some of your threads were active and made requests to the server and didn't receive the response but threads were closed forcefully. If your JMeter test is stopped forcefully, all the active threads will be closed immediately. So the requests generated by those threads will get higher response time.
You can use Ultimate Thread Group for graceful shutdown time(ramp-down time) of threads just like the ramp-up time.
Here is an example setting:
This is not a normal behaviour for a JMeter test, most probably it indicates that either JMeter engine is overloaded (not properly configured for high loads) or the machine where JMeter is running is overloaded (i.e. lacks RAM and starts intensive swapping)
Make sure to follow JMeter Best Practices (run your test in non-GUI mode, remove all Listeners and test elements you don't need, increase JMeter heap size, etc.)
Make sure to monitor the essential health metrics of the machine where JMeter is running (CPU, RAM, Network and Disk IO, Swap file usage). You can use JMeter PerfMon Plugin for this if you don't have any better software
It might be the case you'll have to switch to Distributed Testing, 200 virtual users doesn't seem to be a "high" load to me, but it depends on what exactly these users are doing, if they're uploading/downloading large files it may be sufficient to cause the problems
Going forward consider adding the thread dump and jmeter log file contents to your question as it doesn't contain any clues so we can only come up with "blind shot" answers
You may want to check your HTTP timeouts.
I usually set Connect Timeout to 5000 milliseconds, and Response Time out to 30000.
Your values may vary for your specific environment/ application.
In this way, if things go bad on the server under test, all requests terminate within the timeout (with errors).
You have also to consider that, if you are retrieving an HTML page with all its embedded objects, and the web server is stuck, you need to wait for multiple timeouts to expire before the operation terminate.
I am doing a load test of 300 Virtual users on an application. Previously my users were ramping down and test seems to be finished with in time But now as I jump to 500 user test my users are not ramping down and test keep running for like infinite amount of time. Again I run the test with 300 users, 37 users are still in the system and are not ramping down. Hence my test did not finish.
These are the things that I tried to fix,
Increase the HEAP size in jmeter.properties file.
Cleared the cache and rebooted the services (i.e. SQLSERVER and
collab services)
Can anybody suggest that where Iam doing wrong?
It might be the case your server fails to provide response, by default JMeter will wait for the response forever, it might explain the situation you're running into.
There is "Timeouts" section on the "Advanced" tab of the HTTP Request sampler (or even better HTTP Request Defaults configuration element) where you can set maximum values for Connect / Response, in case if they are exceeded JMeter will automatically mark the sampler as failed and proceed.
Alternative options:
You can set maximum test duration using "Scheduler" section of the Thread Group
There is Runtime Controller where you can define for how long its children are allowed to be run.
I want to test 400 Concurrency Users Which allow us to pass our load testing scenario as I am using below configuration setting in Apache JMeter which will through us lots of errors.
Number of Thread (Users): 400
Ramp-Up Time: 1
Loop Count: Forever Until ( Period of 1 minutes )
We are not telepathic enough to tell what's wrong with your setup without seeing the configuration and the nature of errors.
Several generic hints:
Run your test with 1-2 users/iterations to ensure it works fine and does what it is supposed to be doing. Check requests and responses details using View Results Tree listener
Make sure to run your test in command-line non-GUI mode and disable all the Listeners while your test is running.
It is better to increase and decrease the load gradually so consider using longer ramp-up time and increase test duration accordingly. I.e.
During the first minute virtual users arrive
They then hold the load for another minute
During the last minute virtual users leave
This way you will be able to tell what was the load when the errors started occurring, what is the maximum number of users your application can support, where is the saturation point, does it recover when the load gets back to normal, etc. See JMeter Ramp-Up - The Ultimate Guide article for more details.
It might be the case you found the bottleneck, i.e. your application fails to support 400 concurrent users, now you need to find the reason which may be in:
incorrect middleware configuration (wrong web server, database, load balancer settings)
your application simply lacks resources (CPU, RAM, Network, Swap, etc.). You can check this using JMeter PerfMon Plugin
if infrastructure configuration is OK and there is enough headroom for the application to operate most probably the reason is in the application code, you need to inspect what it is doing using APM or Profiler tools and report the issue.
Using jmeter, I have 10000 users need to hit the server and to respond back with in 40 sec.
During execution (in distributed mode) only 600 users really hitting (Checked in db) in server.
But in AGGREGATE REPORT it shows all requests hits the server.
What is the issue behind this? why the number of requests hits the server isn't consistent between db and jmeter listener?
Probably your test configuration is a little bit wrong.
JMeter acts as follows:
JMeter starts all the threads (virtual users) within the bounds of ramp-up period specified in the Thread Group configuration
Each thread (virtual user) starts executing samplers upside down
When there are no more samplers to execute and no more loops to iterate the thread is being shut down.
You can check how many threads were actually active using Active Threads Over Time Listener or the same chart of the HTML Reporting Dashboard
So you may run into a situation when some samplers have already done their work and some haven't been yet started. Basically you need to provide enough loops to make sure all 10k threads will be up and running for the required test duration.
See JMeter Test Results: Why the Actual Users Number is Lower than Expected guide for more information.