I have a REST service 'A' that relies on an external service 'B' to perform a task.
If 'B' is not available at the time 'A' needs it to fulfill a request, what status should I return?
Is a 503 appropriate in this case? In a way we could say that service 'A' is not available since it can't perform all the work, however in reality only the dependent service is not available.
From the API consumer perspective, it won't mater whether your server or the upstream server that you are proxying is unavailable. You could return either 500 or 503:
6.6.1. 500 Internal Server Error
The 500 (Internal Server Error) status code indicates that the server
encountered an unexpected condition that prevented it from fulfilling
the request.
6.6.4. 503 Service Unavailable
The 503 (Service Unavailable) status code indicates that the server
is currently unable to handle the request due to a temporary overload
or scheduled maintenance, which will likely be alleviated after some
delay. The server MAY send a Retry-After header field
to suggest an appropriate amount of time for the
client to wait before retrying the request. [...]
If the operation is read-only, for example, you may want to return some cached/default data to avoid the error.
Related
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
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
I am requesting for an endpoint which actually creates a task so when I am trying to execute my jmeter script with 500 threads then I am facing some issue. For first 200 threads I am getting 200 response and after that I am getting 400 Bad Request error with the same end point.
Please help me out in this.
Thanks.
Could you check the status of your web server?
There are possibility that web server's connection pool is full.
As per HTTP Status Code 400 documentation
The HyperText Transfer Protocol (HTTP) 400 Bad Request response status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).
So I would recommend:
Double checking your request details (url, parameters, etc.) using i.e. View Results Tree listener
Check jmeter.log file for any suspicious entries
Review your test configuration, for instance if you use CSV Data Set Config which is set not to recycle at the end of file you will be sending <EOF> instead of real values which will not be accepted by the server
Make sure to follow JMeter Best Practices as it might be the case JMeter cannot conduct more than 200 virtual users load due to lack of resources
I have a page on my web site that reports on the health of the site and sets an HTTP 200 status code is everything is okay. This page is used by an external monitoring program to check that the site is up.
When this page is hit, I make a very lightweight DB proc call to see if the DB is up and okay. If this fails, I want to return a meaningful HTTP error code to the monitor to let it know that all is not well.
From what I can work out there's no HTTP status that says "a third party component that I rely on is down" so what what would you return in this case?
503 Service Unavailable...?
That's exactly what a 503 is.
503 means that the server was relying on connecting some other service, which did not respond in time.
Server Error 5xx
Checked up on Wikipedia and the listing there seems to imply that a 504 would be the one I'm thinking of. Quite possibly the link over is outdated.
So:
504 Gateway Timeout
The server was acting as a gateway or
proxy and did not receive a timely
request from the downstream server.
I would suspect that a 500 or 503 would be appropriate. 503 is generally used for overloaded or maintenance conditions, but I don't think it would be unreasonable to use it for your situation.
Leave 500 and 503 for situation when you couldn't determine status of service, like syntax error or DB error about credentials, etc. Or maybe for situation when DB is ok but the app is overloaded.
If the page is for monitoring purposes only, I would not use http codes to indicate status of another service. Better return 200 or even 207 and some XML/json with details. If all is good, then 204 may be ok.
It sounds like you should base your monitoring on more than just the status return. You're trying to pass more sophisticated information than the HTTP status codes were designed to communicate.
Or, just pick a code, even make one up, and set up your monitoring to treat it as "db down".
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 .