While sending a https request in Jmeter prior already i have set Content-Type as "application/json" and but output still displayed as Content-Type: text/html in response header
code
HTTP/1.1 504 Gateway Time-out
Server: nginx/1.18.0 (Ubuntu)
Date: Wed, 02 Mar 2022 05:45:33 GMT
Content-Type: text/html
Content-Length: 176
Connection: keep-alive
Don't confuse request headers and response headers, they don't have to be the same.
Response status 504 means Gateway Timeout
server error response code indicates that the server, while acting as a gateway or proxy, did not get a response in time from the upstream server that it needed in order to complete the request.
So most probably it indicates that your server is overloaded and cannot provide the response within the acceptable timeframe. You can already report it as the botteneck
If you want to investigate further you could:
Check your server logs
Check your server configuration it might not be suitable for high loads
Check your server resources availability in terms of CPU, RAM, Network, Disk, etc. It might be the case you have an APM solution in place, if not you can go for JMeter PerfMon Plugin
Re-run your test with profiler tool telemetry enabled, this way you will get more insights
Related
Thread Name:Thread Group 1-1
Sample Start:2022-04-26 14:22:39 IST
Load time:230
Connect Time:159
Latency:226
Size in bytes:11283
Sent bytes:498
Headers size in bytes:797
Body size in bytes:10486
Sample Count:1
Error Count:1
Data type ("text"|"bin"|""):text
Response code:503
Response message:Service Temporarily Unavailable
HTTPSampleResult fields:
ContentType: text/html; charset=UTF-8
DataEncoding: UTF-8
As per the error description:
503 Service Unavailable
The HyperText Transfer Protocol (HTTP) 503 Service Unavailable server error response code indicates that the server is not ready to handle the request.
Common causes are a server that is down for maintenance or that is overloaded. This response should be used for temporary conditions and the Retry-After HTTP header should, if possible, contain the estimated time for the recovery of the service.
so there is nothing you can "solve" here.
If the server is down for the maintenance - you just need to wait until it's back
If the server is overloaded - congratulations on finding the bottleneck, if you want to investigate further you might want to check:
your application and middleware configuration, you might need to tune it for the high loads
your application resources consumption (CPU, RAM, etc.) as if it lacks resources you might need to migrate to more powerful hardware, it can be done using JMeter PerfMon plugin
repeat your test with a profiler tool or an APM tool telemetry enabled, this way you will be able to tell for sure where the problem is
I have an angular web application that uses Spring boot with an embedded tomcat server in the backend. I want to keep established http connections alive longer to improve the response time of subsequent http requests. With http/1.1 a browser is told to keep the http connection alive by adding Connection: Keep-Alive and something like Keep-Alive: timeout=5, max=1000 to the response header. However connection-specific header fields such as Connection and Keep-Alive are prohibited in HTTP/2. Because of that Chrome and Firefox ignore them in HTTP/2 responses. With HTTP/2, connection-specific metadata should be conveyed by other means.
I can't find anywhere what those 'other means' should be though. Nor can i find anywhere how to configure an embedded Tomcat 9 server to add Keep-alive meta data to a HTTP/2 response. This is how tomcat is configured right now:
#Bean
public WebServerFactoryCustomizer<TomcatServletWebServerFactory> tomcatCustomizer() {
return (tomcat) -> tomcat.addConnectorCustomizers((connector) -> {
if (connector.getProtocolHandler() instanceof AbstractHttp11Protocol) {
AbstractHttp11Protocol<?> protocolHandler = (AbstractHttp11Protocol<?>) connector
.getProtocolHandler();
protocolHandler.setDisableUploadTimeout(false);
protocolHandler.setConnectionUploadTimeout(5000);
protocolHandler.setKeepAliveTimeout(4000);
protocolHandler.setMaxKeepAliveRequests(200);
protocolHandler.setUseKeepAliveResponseHeader(true);
}
});
}
But these settings aren't going to work if i want to use HTTP/2. Any ideas?
With http/1.1 a browser is told to keep the http connection alive by adding Connection: Keep-Alive and something like Keep-Alive: timeout=5, max=1000 to the response header.
That’s not actually true. Since HTTP/1.1 the Connection: Keep-Alive header is defaulted to be the case unless explicitly set to Close. The fact we even have the header is more a left over from HTTP/1.0 days and shouldn’t need to be set. The response has always been more informative of what the server will do rather than an instruction to the client (“hey, FYI I’m going to be using these settings”) but it was always kind of meaningless too since server (and client) could drop the connection if it wanted too. If a server is running out of TCP connections it shouldn’t really keep and old one that is not being used alive rather than accept a new one, in general.
However connection-specific header fields such as Connection and Keep-Alive are prohibited in HTTP/2. Because of that Chrome and Firefox ignore them in HTTP/2 responses. With HTTP/2, connection-specific metadata should be conveyed by other means.
I can't find anywhere what those 'other means' should be though. Nor can i find anywhere how to configure an embedded Tomcat 9 server to add Keep-alive meta data to a HTTP/2 response. This is how tomcat is configured right now:
In the same way as previous, HTTP/2 just got rid of the rather pointless header and assumed you want to keep it alive. It also made less sense in HTTP/2 as it’s used for multiple requests and responses whereas HTTP/1.1 is only used for one at a time and keep-alive is a connection-level setting. So if an HTTP/2 request could specific a keep-alive: close what would that mean for other requests on that connection that are already in-flight? And similarly setting it to keep-alive is implied by the very nature of HTTP/2’s multiplexing.
It’s up to the client and server to decide when best to drop the connection, based on its own logic and resource constraints, though the HTTP/2 spec does go on to say this later:
HTTP/2 connections are persistent. For best performance, it is expected that clients will not close connections until it is determined that no further communication with a server is necessary (for example, when a user navigates away from a particular web page) or until the server closes the connection.
I'm having trouble with a long running webservice timing out in an Oracle 10g environment.
The client calls the webservice and after approximately 10 minutes, it receives the following response:
HTTP/1.1 503 Service Unavailable Server:
OracleAS-Web-Cache-10g/10.1.2.3.0 Content-Type: text/html Connection:
Keep-Alive Keep-Alive: timeout=600, max=999 Content-Length: 402
No
Response from Application Web Server No Response from Application
Web Server There was no response from the application web
server for the page you requested. Please notify the site's
webmaster and try your request again later.
The webservice executes a procedure in the database which takes a long time to finish (more than 20 min, on average) and the client receives the above response after aproximately 10 minutes.
My guess is that the webserver thinks the webservice has crashed, so it terminates it and sends the above response to the client.
My question is: how do I deactivate the timeout setting? I need to let the webservice run for as long as it needs (or, at least, for severeal hours).
I don't have access to the webserver's configuration or administration console but I can ask the guys responsible for managing it to change any setting (this is a test environment).
Thanks in advance for any ideas.
I have a simple problem that I can't currently recreate and I need to solve next Monday.
In a development environment, we have a .NET4 service running on ASP.NET test server provided by VS2010 and a Java client running Axis2. We found that all requests fail. With Wireshark we found a 400 Bad request error on every request.
We found that each request from Java client required transfer-encoding: chunked. The rest seemed well formed. After the headers and a few bytes the server throws 400 error.
Questions are:
Does .NET test server support chunked transfers?
How can I tell Axis2 to use plain HTTP without even keep-alive just to be sure?
Answer 1
No, it doesn't. Disabling chunked encoding makes everything work!
Answer 2
http://wso2.org/library/209 provides information about how to disable chunked transfers (with an error in their code)
FooStub stub = new FooStub();
stub._getServiceClient().getOptions().setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.FALSE);
It seems even nginx only half supports HTTP 1.1 keep-alive requests:
It is an HTTP/1.0 proxy without the
ability for keep-alive requests yet.
(As a result, backend connections are
created and destroyed on every
request.) Nginx talks HTTP/1.1 to the
browser and HTTP/1.0 to the backend
server. As such it handles keep-alive
to the browser. (source)
Were it you,how would you implement this?
The hardest part I think is how to make the response the same order as requested in keep-alive mode.