In continuation to working on this issue - JMeter test not stopping after duration ends in distribution mode
Using JMeter version - 5.4
I got a thread dump and figured out few threads are getting stuck on HTTP Requests.
The resolution figured out is to set timeouts for the HTTP Requests as mentioned here - Configuring response timeout in Apache JMeter
But I'm not the author of the test plan. Hence, the only way I could use is to set JMeter properties.
I've set the following in jmeter.properties (values are for local testing):
httpclient.timeout=100
hc.parameters.file=hc.parameters
os_sampler.poll_for_timeout=100
and in hc.parameters
http.socket.timeout$Integer=100
But unfortunately none of these are working.
The only timeouts working are the ones when I set them in Advanced Tab of HTTP Sampler of the test plan.
Do we have any platform recommendation to control this behavior (like some other setting or property etc.)? Or am I missing anything in the above mentioned properties?
Also, I do sometimes get this exception in response, but I highly doubt if this is related?
Non HTTP response code: java.net.BindException
Non HTTP response message: Address already in use: connect
Your steps are correct so it looks like a bug in JMeter, presumably a side-effect of this commit so you have 2 options:
Downgrade to JMeter 5.0 where this functionality is still working
Raise an issue in JMeter Bugzilla but you will need to wait until someone fixes it and then either for a nightly build or a new release containing this fix
Fix it yourself and contribute the fix to the upstream
Related
I am using jmeter to perform load testing on my dev cluster. I have used HTTP Authorization Manager and have passed baseurl, username, password etc. Now my thread group have:
Number of threads:100 ,
Ramp-up period: 1 and Loop Count:1
Now for the first 50-60 calls the authorization works as expected but later it starts failing by giving error as 403. can anyone please tell me how to fix this?
I am using jmeter 5.4.1
Is there any response data? Perhaps you are getting rate limited. I also noticed you are reading in variables from a CSV. Are you sure the data in each row is correct? If you are providing auth credentials through the CSV, an incorrect row could lead to a 403.
As a side note, JMeter 5.4.1 has a log4j vulnerability, you might want to upgrade it to the latest version.
If the problem occurs under the load I can think of 2 possible reasons:
Your application gets overloaded and cannot properly handle the requests. Check your application logs and resources usage (CPU, RAM, etc.)
JMeter gets overloaded and not being able to properly send the requests. You're violating several JMeter Best Practices in particular:
you're running JMeter in GUI mode, GUI is only for tests development and debugging, when it comes to execution you should be using command-line non-GUI mode
you're using Listeners, especially View Results Tree, they don't add any value and just consuming resources
you're not using the latest version of JMeter, current stable release is 5.4.3
Today i got issue Non Http Response code when run script on Jmeter. My script run over some steps (Login - view) but got this issue and have log that issue at NoHttpResponseException.
I'm using Jmeter version 3.3. And I think that maybe this issue from server side, not by my script.
Does anyone fix this issue before? Please support me to resolve it.
This status code is being returned when an Exception occurs during HTTP Request sampler execution. There are hundreds or thousands of possible exceptions and even more potential causes for them.
If it occurs only under the load - most probably it's a server side error and you need to check the application under test logs and monitoring software results to identify the cause
It might be something described in the Connection Reset since JMeter 2.10 ?
It might be the case your JMeter script is badly designed/implemented and you're sending garbage instead of proper HTTP request
So try to collect as much information as you can:
Application under test and JMeter logs (it includes any middleware such as reverse proxies, load balancers, databases, etc.)
Application under test and JMeter machines health metrics (CPU, RAM, Network, Disk, Swap)
Network layer information, i.e. HTTP Request and response details.
Also be aware that according to JMeter Best Practices you should always be using the latest version of JMeter so consider upgrading to JMeter 5.0 (or whatever is the current latest JMeter version available at Downloads page) as soon as it will be possible.
Am testing with an realtime application upto 40 users everything going fine after 40 users if i increased users to 45 or 50 and so on getting java.net.socketexception:connection reset errors could you please suggest a solution for this?
Most probably it indicates an issue with your application, check if there are any suspicious entries which can shed light on the root cause in your application logs. It might also be a configuration issue of any middleware (load balancers, routers, switches, proxies, etc.)
If you absolutely sure that your application behaves as expected you can tune JMeter to do retries on connection resets (however this will make your test not realistic from browser perspective), in order to do this:
In user.properties file add the next lines:
httpclient4.retrycount=1
hc.parameters.file=hc.parameters
In hc.parameters add the next line:
http.connection.stalecheck$Boolean=true
Restart JMeter to pick up the changes.
References:
Connection Reset since JMeter 2.10 ?
Configuring JMeter
JMeter Properties Reference
Apache JMeter Properties Customization Guide
Getting high Error% in jmeter after run, how to know this error is due to out of memory or used machine doesn't have capability or the http request has an issue. In my case getting Error% in jmeter summary report is 97.50% (for login api) and when loaded this result in 'View results tree' can see 500 internal server errors or the failed requests. Please suggest what measures can be taken to analyse these errors.
As per the RFC 2616
10.5 Server Error 5xx
Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. User agents SHOULD display any included entity to the user. These response codes are applicable to any request method.
10.5.1 500 Internal Server Error
The server encountered an unexpected condition which prevented it from fulfilling the request.
So the possible reasons are in:
You are sending incorrect requests which cannot be processed on your server side. Check server logs for details, most probably you will be able to figure out something from them. If you don't have access to logs you can at least configure JMeter to save response data for failed requests, add the following lines to user.properties file to trigger this on:
jmeter.save.saveservice.output_format=xml
jmeter.save.saveservice.response_data.on_error=true
Check out Configuring JMeter chapter for more information.
It may be your application components configuration which is not suitable for high loads, i.e. your application server or database can be configured to accept not more than X connections and your load test is exceeding this value. The solution is again to check application, web server and database logs and make required configuration changes
It may be due to simple lack of resources, i.e. CPU or RAM on server side so you can monitor them using u.e. JMeter PerfMon Plugin. See How to Monitor Your Server Health & Performance During a JMeter Load Test for more details.
When I have given 500 concurrent users load via jmeter my server throwing error message but the same time I have called same request via browser showing proper response. How it is possible? Is there any settings in jmeter for avoiding same.
It is hard to say what can go wrong without seeing your JMeter configuration, full server response, JMeter and application under test logs and network dump for browser and JMeter.
The whole idea of performance testing is mimicking real user as close as possible, so you need at least
Add HTTP Request Defaults and set JMeter to:
Download embedded resources
Use concurrent pool of 2-5 threads
Add HTTP Cookie Manager
Add HTTP Cache Manager
Add HTTP Header Manager
Correlate any dynamic parameters
Simulate any specific application behaviour (i.e. AJAX calls)
etc.
In addition to above recommendations: ideally given "good" JMeter you shouldn't see any "response messages", you should see a number of errors in final report so double check you:
Run JMeter in non-GUI mode
Storing only those metrics which are absolutely required
Follow other recommendations from 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure
beside, what Dmitri described above, I would also check the actual throughput the server returns in either cases.
Throughput depends a lot on the timers you configured in Jmeter to simulate think time.
Jmeter has no rendering and no javascript engine, so each thread is much much faster than a real browser.