I have a jmeter script where in I initiate the test with concurrent 300 users(threads), then with every 10sec, 100 more threads are added. My script was running absolutely fine. But suddenly I am noticing that inspite of adding 100 threads, its adding 3 or 4 threads.
I have increased swap memory, still no go.
I am using 4GB machine, in which i have made "Xms=1g Xms=3GB"
And this is how slowly threads are getting added:
Here is how "absolutely fine" execution of your scenario should look like:
Given you have that many threads in the Finished state there is something preventing them from doing their normal job so instead of finishing execution of all Samplers of the current iteration and starting the new one the threads are being terminated somewhere in between and JMeter restarts them.
Your question doesn't contain sufficient information in order to guess the reason, inspect your test plan and make sure you have enough test data, in case of CSV Data Set Config ensure that Stop Thread on EOF is set to False, etc.
If your test plan looks okayish check jmeter.log file for any suspicious entries
Related
I need to run a load test of 25 threads, what will be the most efficient configuration to use? (ramp-up period....). I ran the load test with the below configuration and some of the threads failed but pass if I just ran the script individually.
Your configuration will mean that:
JMeter start with 1 thread and add another thread each 4 seconds
Once started each thread will begin to execute Samplers upside down (or according to the logic controllers)
When the thread executes the last sampler it will be shut down
When the last thread executes the last sampler the test ends
Depending on the number of samplers and application response time you may or may not achieve 25 users concurrency, you might want to check the actual number of concurrent users using Active Threads Over Time listener
If you want to make sure to have 25 online users set "Loop Count" to Infinite and "Specify Thread Lifetime" duration to be more than your ramp-up period. See JMeter Test Results: Why the Actual Users Number is Lower than Expected article for more details.
With regards to the failures - we cannot state anything meaningful without seeing request and response details, make sure to save them using i.e. View Results Tree listener and inspect response body for the failed requests
I have a test plan where I have to pick 100 users from a CSV file. If I give threads count as 500 and loop count as 1, then I can see 490 are failed and only 10 are passed. But at the same time, if I give threads as 5 and loop count as 100, all the tests are passed. Aren't these same where the total number of requests are 500?
Is this because 500 threads and 5 threads?
If you start 500 threads, By default, the file is only opened once, and each thread will use a different line from the file. However the order in which lines are passed to threads depends on the order in which you execute, which may vary between iterations.
Change Your Jmeter CSV-DataSet-Config property "Recycle on EOF - True"
; Your Issue will solve
Hope This Helps!
You get different results because you apply different load pattern. JMeter acts as follows:
Each Thread Group kicks off threads (virtual users) within the ramp-up period
Each Thread starts executing Samplers upside down (or according to the Logic Controllers)
When the thread doesn't have any more samplers to execute or loops to interate it is being shut down
So reasons could be in:
Your application isn't capable of handling 500 users. Checks its logs for error details. If there are no specific errors it might be lack of hardware resources, re-run your test with JMeter PerfMon Plugin Telemetry to check the impact of the increasing load onto hardware resources consumption
Your application underlying components is not suitable for high loads. Some application and database servers come with connection limitations, low memory allocation, etc. in other words configuration suitable for development and debugging. Production deployment assumes totally different configuration therefore it needs to be inspected and amended
Your JMeter instance cannot create the required load. Like in point 2 JMeter default configuration is good for tests development, however when it comes to running load tests you need to mind some important points:
Increase JVM Heap size for JMeter
Run your test in non-GUI mode
Disable all the listeners during test run
See Reducing resource requirements chapter of JMeter's User Manual for more information
How to run a thread group for a given number of times, eg. 10,000 times.
You can use Loop Controller where number of iterations are in your control (you can define) instead of scheduled time (there is no control over no. of iterations, once time is completed, JMeter stops the test). So, I suggest using Loop Controller.
When you ran the test for 5 mins, it might be the reason that scheduled time got completed so stopped the test, hence next 2 requests are not sent.
Add View Results Tree listener and observe the behaviour. Once debugging is done, remove the listener as it consumes a lot of resources.
I've got a pretty basic test plan in JMeter consisting of a Thread Group and a bunch of HTTP Requests separated by Timers and a Summary Report. I notice when I watch the report that all 10 of my threads make the first request, then pause for some time, then all make the second request.
Is it possible to have each thread execute the full script independently of the others so that (given a Ramp-up delay) you have overlapping workload, i.e. some threads executing the first step while others are on the 3rd or 4th etc?
Threads DO execute independently in JMeter.
Make sure you are you using any Ramp-up period in the thread group definition.
Another reason for what you're seeing is probably due to using a constant timer which ends up in requests looking they they are synchronized. If you simply change it to one of the Random timers you'll get more randomness in the delay between requests.
Here are two good sources about timers:
http://performancetestersdiary.wordpress.com/2013/03/06/jmeter-timers-in-pictures/
http://www.softwaretestingclass.com/timers-in-jmeter-tutorial-series-6/
Yes, Threads DO execute independently in JMeter, but,if you start at the same time and do the same things, all the requests will be issued at the same time (specially if you are using a constant throughput timer).
I use two way of approaching this problem:
use a uniform random timer under a "once Only controller", at the beginning of the thread.
The value of the timer should be close equal or close to the time it takes to execute the service.
use rampup time (same value as above). It is deterministic and simpler to use (which can be bad or good, according to your needs.
Click on your "Test Plan"
Check/Select the Property: Run Threads consecutively (i.e. Run Groups one at a time)
Hope this will help.
We have about 10 different Python scripts that download data from the web, read data from a database and write data back to that database. They do so repeatedly every 10 seconds (or 10 seconds after the last task has completed).
The question is, what is the best approach at running these tasks? I can think of a few ways:
a while True that runs the task then sleeps for the interval. It could be guarded by a watchdog like supervisord, making sure it is always up.
having the script execute the task just once, and invoking the script externally once every 10 seconds by another process.
having the script execute the task lets say for 1 hour (every 10 seconds for an hour), and having a watchdog make sure that task runs again once the hour is over.
I would like to avoid long running processes that actually do something because I don't want to deal with memory problems etc over long periods of time.
Additional Information
The scripts are different because they each retrieve data from a different source, and query, calculate and insert different data into the database.
The tasks are performed every 10 seconds since the data being retrieve is in real-time, and we need to not only keep updating it very frequently, but also keep all the historical data in the database.
There are a lot of resources being used by the scripts - MySQL connections, HTTP connections, Redis connections, etc. We have encountered issues with using the long-running approach before, specifically with MySQL connections (things like MySQL server has gone away, even though all connections had been closed). Hence the inclination toward having the scripts run in shorter periods of time.
What are some common approaches at this?
Unless your scripts somehow leak memory (quite unlikely), they should all be the same. So, for sheer simplicity (your time programming/debugging is much more expensive than a few miliseconds of the machine's time, even each 10 seconds!) I'd go for the single script that checks each 10 seconds.
OTOH, checking each 10 seconds sounds like busywork. Can't you set up so that whatever you are monitoring tells you when there are changes? Or batch the records up so you can retrieve, say, a day's worth at at time?
If you are running on linux, cron has granularity of a minute. We have processes we run constantly. Rather than watch them, the script will open a semaphore that gets released when the program finishes normally or not. This way if it runs long and it gets called again by cron, the copy will exit when it can't get the lock. This way you can call it a often as you need to without it stepping on a possibly still running copy.