Jmeter: Getting 502 bad gateway error for some of the requests in suite - jmeter

I have created a performance test suite in Jmeter. The suite contains one thread group:
Thread properties:
Number of threads: 100
Ramp-up period: 5
Loop count: 1
Clearing cache and cookies on each iteration.
Thread group has 30 samplers (HTTP Requests for 30 pages), each samplers has "View Results Tree" and "View Results in table" listeners.
With this I am running the test suite.
Problem: I am getting "502 Response" for some requests on some threads.
I am new to performance testing and Jmeter. Please let me know what is the reason for getting 502 in this case and how can I solve this.

All HTTP status codes 5xx are server errors which means that you cannot "solve" them from JMeter perspective.
Particular HTTP status code 502 means "Bad gateway", as per description:
The HyperText Transfer Protocol (HTTP) 502 Bad Gateway server error response code indicates that the server, while acting as a gateway or proxy, received an invalid response from the upstream server.
Note: A Gateway might refer to different things in networking and a 502 error is usually not something you can fix, but requires a fix by the web server or the proxies you are trying to get access through.
So in order to "solve" it you need to inspect your application and middleware logs and see what is the root cause of the problem.
If it happens only under the load of 100 users and not reproducible with less amount of threads it indicates that your application is overloaded hence cannot properly respond to certain requests. So you can just report it as a performance bottleneck.
A good idea would be implementing monitoring of the system under test to measure CPU, RAM, Network, Disk usage, etc. as the reason could be as simple as the lack of resources, it can be done using JMeter PerfMon Plugin
If the machine is not overloaded but you're getting this error it means that either system under test is not properly configured for high loads or uses inefficient algorithms somewhere, you can discover what's going on under the hood by looking at profiler tool or APM tool output

Related

The jmeter concurrency test found 429/Too Many Requests errors

I set up a web project with springboot and modified the Tomcat configuration:
tomcat:
max-threads: 800
accept-count: 1000
max-connections: 10000
min-spare-threads: 100
I deployed the project to a Linux server. The concurrency performance was tested with jmeter both locally and on the server. jmeter sets the following parameters:Number of Threads is 200, Ramp-up period is 0, and Loop Count is 1.
The local result is normal, and all requests are all accepted. However, 429 errors occurred in 43.5% of requests from the server test result.
How to solve this problem?
It might be the case you have a rate-limiter implemented somewhere so depending on the configuration applied you can:
Just turn it off via Spring Boot configuration
Or check your app performance within the configured maximum requests rate
Or try to impersonate different users coming from different IP addresses by setting up IP Spoofing in your JMeter test so your server would "think" that users are coming from the different locations and apply rate limiting for each user and not globally.

Requests are getting failed with error code 499

Requests are getting failed with error code "499" when application is loaded with 1000 users with ramp-up time as 150 seconds using jmeter.
could not find any error in jmeter.log in bin folder.
it would be great help if some pointers for this failures?
Thanks in advance.
Status code 499 isn't listed in the standard so you need to see your application logs to know what it means and what could be possible cause.
If you're using nginx as the backend status code 499 means that the client (in your case JMeter) has closed the connection in the middle of communication, most probably due to timeout so if response times are higher than your configured or default timeout - it may be the cause of the issue, consider increasing connect/response timeouts, the setting lives at "Advanced" tab of the HTTP Request sampler or HTTP Request Defaults configuration element

Jmeter | API 500 internal server error | Back End Server : Azure Appservice

I am getting API 500 internal server error while trying to requests a high number of the load. Some of the threads are only getting 500 internal server error, other threads are working fine.
Is there any way why the API is throwing 500 internal server error.
Could you please tell me Is that server-side issue or Jmeter-side issue.
I am just confused whether it is a jmeter issue?
Your question contains the answer already:
500 internal server error
If you look at HTTP Status Code 500 description:
The HyperText Transfer Protocol (HTTP) 500 Internal Server Error server error response code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.
This error response is a generic "catch-all" response. Usually, this indicates the server cannot find a better 5xx error code to response. Sometimes, server administrators log error responses like the 500 status code with more details about the request to prevent the error from happening again in the future
So I would say that it's a server-side issue, if you want to get to the bottom of it:
Check health metrics of your website
Increase ramp-up period in order to identify how many users can be normally served and what is the "critical" amount when the errors start occurring, you can correlate the following charts:
Active Threads Over Time - to visualise users arrival
Response Codes Per Second - to see the HTTP Status codes over time
Response Times Over Time can also be useful to see whether response time increases as the load increases, this way you will be able to find the saturation point

Internal Server Error(500) while running load test in JMETER

I am unable to get response from server so how will correlate dynamic values too
As per HTTP Status Code 500 description:
The HyperText Transfer Protocol (HTTP) 500 Internal Server Error server error response code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.
This error response is a generic "catch-all" response. Usually, this indicates the server cannot find a better 5xx error code to response. Sometimes, server administrators log error responses like the 500 status code with more details about the request to prevent the error from happening again in the future.
If your test works fine with 1-2 users and you're seeing this HTTP 500 error only when your application is under the load, most probably your application gets overloaded hence fails to provide valid response.
You can already report it as the bug, or if you want you can investigate it a little bit further, to wit:
Use Active Threads Over Time and Response Codes per Second to see when these errors start occurring (i.e. application works fine till 200 concurrent users and after 201 it starts throwing HTTP 500 errors)
Inspect your application logs
Make sure that the application has enough headroom to operate in terms of CPU, RAM, Network, Disk, etc, you can use JMeter PerfMon Plugin for this
Inspect your application middleware configuration and logs (load balancer, application server, database, etc.)
Consider collecting APM and/or profiler tools output during the load test execution, this way you will be able to precisely identify the root cause of the problem

What raises HTTP 503 and how to change timeout?

I have inherited an application (internal to my company) that uses javascript running in Internet Explorer which makes Ajax calls to a Struts-based application running in WebLogic Server v10.
Certain server-side operations in the system are taking longer than 3 minutes. Users consistently noticed that the Ajax call returns 503 error at the 3 minute mark. My users can wait longer than 3 minutes, but 503 errors interrupt their work.
This application needs to be performance tuned, but we badly need a temporary workaround to extend how much time can occur before a 503 error is returned.
The current theory is that the 503 error is being raised by the IE XMLHttpRequest object. A team of supposed WebLogic experts poured over our code and WebLogic logs, and declared that there's no timeout occurring on the server side. But I have my doubts.
My question is, which piece of software is responsible for raising 503 error: the browser, the Ajax javascript, or the server? And can this timeout period be changed?
A 503 error is kind of a catch-all for a lot of different types of errors, usually on the server side. In your case it could be that the server is just rejecting the connection after a certain timeout, and responding back with a 503 to indicate that the server is overloaded or cannot process your request.
A lot of times with web services, a 503 will be returned when the server code throws an exception or error. If the server code doesn't properly handle the error, it will bubble up to the server, which will just respond back with a generic 503.
http://www.checkupdown.com/status/E503.html
Error code 5xx (alternate definition)
RFC 2616
503 is a server error. XMLHttpRequest will happily wait longer than 3 minutes. The first thing you should do is satisfy yourself of that by visiting the problem URL in telnet or netcat or similar and seeing the 503 with javascript out of the picture.
Then you can proceed to find the timeout on the server side.
Your web server has a request reply timeout which is being tripped by long-running service requests. It could be the WebLogic server or a proxy. It is certainly not the client.
Have you considered submitting an asynchronous HTTP request that will be responded to immediately, and then polling another location for the eventual results? Three minutes is about 170 seconds too long.
503 is most likely due to a timeout on the server. If you can tune your Apache server, read about the Timeout attribute that you can set in httpd.conf.
Look in the httpd/logs/error_log to see if timeouts are occurring.
Refer also to this answer: Mod cluster proxy timeout in apache error logs .

Resources