Jmeter CLI stops tests after sometime. Any ideas? - performance

When I run Jmeter from Windows CLI, after some random time, the tests are being stopped or stuck. I can click on ctrl+C (one time) just to refresh the run but part of the request will be lost during the time it was stuck.

Take a look at jmeter.log file, normally it should be possible to figure out what's wrong by looking at messages there. If you don't see any suspicious entries there - you can increase JMeter's logging verbosity by changing values in logj2.xml file or via -L command-line parameters.
Take a thread dump and see what exactly threads are doing when they're "stuck"
If you're using HTTP Request samplers be aware that JMeter will wait for the result forever and if the application fails to respond at all - your test will never end so you need to set reasonable timeouts.
Make sure to follow JMeter Best Practices
Take a look at resources consumption like CPU, RAM, etc. - if your machine is overloaded and cannot conduct the required load you will need to switch to distributed testing

There are several approaches to debugging a JMeter test which can be combined as a general systematic approach that I capable of diagnosing most problems.
The first thing that I would suggest is running the test within the JMeter GUI to visualize the test execution. For this you may want to add a View Results Tree listener which will provide you with real time results from each request generated:
Another way you can monitor your test execution in real time within the JMeter GUI is with the Log Viewer. If any exceptions are encountered during your test execution you will see detailed output in this window. This can be found under the Options menu:
Beyond this, JMeter records output files which are often very useful in debugging you load tests. Both the .log file and the .jtl file will provide a time stamped history of every action your test performs. From there you can likely track down the offending request or error if your test unexpectedly hangs:
If you do decide to move your test into the cloud using a service that hosts your test, you may be able to ascertain more information through that platform. Here is a comprehensive example on how to debug JMeter load tests that covers the above approaches as well as more advanced concepts. Using a cloud load test provider can provide your test will additional network and machine resources beyond what your local machine can, if the problem is related to a performance bottleneck.

Related

Why it is recommended to run load test in non gui mode in jmeter

I'm monitoring the connect time and latency to connect from jmeter machine while running in GUI mode and that is in within acceptable limit.
Should we strictly follow non GUI mode even though I can able to perform load test with GUI mode?
I'm targeting 250 TPS and able to achieve that ..I have increased my memory and monitoring CPU and memory of load generator is below 60%.
Should I go for non GUI mode ?
The main limitation is that each event in the queue is being handled by a single event dispatch thread which will act as the bottleneck on your JMeter side.
My expectation is that your "250 TPS" look like:
while it should look like:
So check how does your load pattern look like using i.e. Transactions per Second listener (installable via JMeter Plugins Manager)
Also check how does your JVM look like especially when it comes to garbage collection, it can be done via i.e. JVisualVM, most probably you will see the same "chainsaw" pattern
You don't need to follow JMeter best practices, but
you may encounter issues to achieve specifc goals (as TPS)
your machine can't execute GUI or have low resources
you execute JMeter using a script or build tool as Jenkins
Also it's better to be familiar with JMeter CLI (non GUI) and its report capabilities
JMeter supports dashboard report generation to get graphs and statistics from a test plan.
Also it will be needed for using distributed testing
consider running multiple CLI JMeter instances on multiple machines using distributed mode (or not)
CLI also useful for Parameterising tests
The "loops" property can then be defined on the JMeter command-line:
jmeter … -Jloops=12

Whats the impact of response code 400,503 ? Can we ignore these codes if my primary focus is to measure loading time of web application?

I am testing a web application login page loading time with 300 thread users and ramp up period of 300 secs.Most of my samples return response code 200.But few of them return response code 400,503.
My goal is to just check the performance of the web application if 300 users start using it.
I am new to Jmeter and have basic knowledge of programming.
My Question :-
1.Can i ignore these errors and focus just on timings from the summary report ?
2.If i really need to fix these errors, how to fix it ?
There are 2 different problems indicated by these errors:
HTTP Status 400 stands for Bad Request - it means that you're sending malformed requests which cannot be understood by the server. You should inspect request details and amend JMeter configuration as it is the problem in your script.
HTTP Status 503 stands for Service Unavailable - it indicates the problem on server side, i.e. server is not capable of handling the load you're generating. This is something you can already report as the application issue. You can try to identify the underlying cause by:
looking into your application log files
checking whether your application has enough headroom to operate in terms of CPU, RAM, Network, Disk, etc. It can be done using APM tool or JMeter PerfMon Plugin
re-running your test with profiler tool telemetry to deep dive into what's under the hood of the longest response times
So first of all you should ensure that your test is doing what it is supposed to be doing by running it with 1-2 users/loops and inspecting requests/response details. At this stage you should not be having any errors.
Going forward you should increase the load gradually and correlate the increasing number of virtual users with the increasing response time/number of errors
`
Performance testing is different from load testing. What you are doing is load testing.
Performance testing is more about how quickly an action takes. I typically capture performance on a system not under load for a given action.
This gives a baseline that I can then refer to during load tests.
Hopefully, you’ve been given some performance figures to test. E.g. must be able to handle 300 requests in two minutes.
When moving onto load, I run a series of load tests with increasing number of users/threads and capture the results from each test.
Armed with this, I can see how load degrades performance to the point where errors start to show up. This gives you an idea of how much typical load the system can handle.
I’d also look to run soak tests too. This where I’d run JMeter for a long period with typical (not peak) load to make sure the system can handle sustained load.
In terms of the errors you’re seeing, no I would not ignore them. Assuming your test is calling the same endpoint, it seems safe to say the code is fine, its the infrastructure struggling with the load you’re throwing at it.

Jmeter Execution Report Analysis

I execute jmeter script via Blazemeter and I got 2% error. Is it a acceptable rate?
In detail report I observed 1353 request are failed. I just run the script for one user. In that case non of the request doesn't fail. So is that failures are due to performance issue?
Following is summary of the report. Kindly help me to anlyse this.
Most probably your application simply cannot handle the load of 50 concurrent users. With regards to "acceptable" - we don't know. If you're load testing a fan page of your local hip hop star - even 90% error rate will be acceptable. If you're testing an algorithm which will be deployed on a Mars rover and will have to work without errors and modifications for 20 years - it is not.
Normally maximum response time, minimum throughput, acceptable number of errors, etc. are defined in SLA or NFR. If you don't have those and performing some form of stress testing of your application and want to figure out the root cause of the performance bottleneck - take the next steps:
Check your application log file(s), they should have some information regarding the failure
Check status message and code in .jtl results file. Sometimes it also makes sense to "tell" JMeter to save response data for failed samplers by adding the next lines to user.properties file:
jmeter.save.saveservice.output_format=xml
jmeter.save.saveservice.response_data.on_error=true
Make sure you add the load gradually, this way you will be able to correlate increasing error rate with increasing number of users and will be able to determine exact point of time when first error occurred
Get used to monitoring whether your application under test has enough headroom to operate in terms of CPU, RAM, Network, Disk, etc. It can be done using JMeter PerfMon Plugin
If you have ability to read and understand the code in the language your application is written in - it would be beneficial if you could run your test with profiler tool telemetry enabled, this is probably the most efficient way to identify the performance problem in your application.

Jmeter log replay taking more time

Jmeter log replay taking more time .. can we able to use access log sampler in multiple thread? if so how to share the log files to all the threads?
Please help.
You can convert your access log into a CSV file with a script and use CSV Data Set Config in conjunction with the HTTP Request samplers - this way you will get it replayed with the multiple threads. See Stop Making Assumptions! Learn How to Replay Your Production Traffic With JMeter article to get the idea in more details and see the example implementation.
However be aware that this way most likely you won't be able to replay complex end-to-end scenarios, only simple HTTP GET requests which are not authenticated can be replayed this way. For quick-and-dirty test plan it might be enough, however it is much better to come up with modular test plan, reusable components, full control of workload, etc. so I would rather recommend building a web test plan from scratch.

Jmeter-Saturation point

How can i know the critical point where the systems breaks.
To analyze the result is the toughest part in Jmeter.I failed to judge it because everytime the result or listeners show different result
Can anyone suggest me what efforts should i put so that i can easily say "that this website is crashing with 500 users or giving no response after certain point."
I also have a problem in configuring the threads that what combination should i entered in thread group.
Because i have to report it further or needs to explain.
Reporting is JMeter's Achilles' heel. You can use JMeter Plugins project which provides
Ultimate Thread Group - which simplifies load scenario definition
Active Threads Over Time - which displays amount of active threads as your test goes
Server Hits Per Second - which provides information how many requests per second your threads provided
You can also consider using Taurus tool which simplifies the process of configuring and executing of JMeter tests and has rich reporting capabilities.

Resources