jmeter运行报错“Non HTTP response message: The target server failed to respond”

     When running with jmeter, it reports "Non HTTP response message: The target server failed to respond" and "Non HTTP response code: java.net.SocketException", modify the property value in the jmeter.properties file httpclient.timeout= <time in ms > , generally modified to <time in ms> here is milliseconds, set 10-60 milliseconds according to the situation, can solve the problem of error reporting, but the corresponding time is 2-3 times of the normal test, the response time is longer, the problem is still not really solved .

     In the http request of jmeter, the tool will check Use KeepAlive by default. At runtime, the time ( httpclient.timeout ) setting in jmeter.properties is logged out by default, that is, the connection is idle and immediately disconnected, which may also be an error s reason.

    The jmeter official website reports socket errors and gives suggestions for modification. If you are interested, you can take a look. https://wiki.apache.org/jmeter/JMeterSocketClosed

---------------------------------------------------------------------------------

Transfer: http://liuzhigong.blog.163.com/blog/static/1782723752011412551547/Related knowledge:

      

HTTP Keep Alive

HTTP Keep-Alive is widely misunderstood. Let's introduce how it works under HTTP/1.0 and HTTP/1.1, and how it works in JAVA.

HTTP is a typical example of a request<->response pattern, that is, the client sends a request message to the server, and the server responds with this message. In older HTTP versions, each request would create a new client- >server connection, send the request on this connection, and then receive the request. A great advantage of such a pattern is that it is very simple, easy to understand and program; it also has a great disadvantage that it is inefficient, so Keep-Alive is proposed to solve the problem of inefficiency.

 

HTTP/1.0

In the HTTP/1.0 version, there is no official standard to specify how Keep-Alive works, so it is actually attached to the HTTP/1.0 protocol. If the client browser supports Keep-Alive, then in the HTTP request header Add a field Connection: Keep-Alive to the server. When the server receives a request with Connection: Keep-Alive attached, it also adds the same field to the response header to use Keep-Alive. In this way, the HTTP connection between the client and the server will be maintained and will not be disconnected (except for the time specified by Keep-Alive, unexpected power failure, etc.), when the client sends another request, use this established connection

 

HTTP/1.1

In the HTTP/1.1 version, the official Keep-Alive usage standard is somewhat different from that in the HTTP/1.0 version. By default, all connections in HTTP 1.1 are kept unless specified in the request header or response header to be closed. : Connection: Close , which is why the Connection: Keep-Alive field is meaningless. In addition, a new field Keep-Alive: is added, because this field does not describe in detail what it is used for, it can be ignored

Not reliable

HTTP is a stateless protocol, which means that each request is independent, Keep-Alive did not change this result. In addition, Keep-Alive does not guarantee that the connection between the client and the server must be active, which is also the case in HTTP 1.1. The only guarantee is that you will get a notification when the connection is closed, so you shouldn't make your program depend on Keep-Alive's keep-alive feature, otherwise there will be unintended consequences

 

Keep-Alive和POST

The HTTP 1.1 specification stipulates that there cannot be any characters after a POST message body, and also points out that a particular browser may not follow this standard (such as placing a CRLF character after the POST message body). As far as I know, most browsers will automatically send a CRLF character after the POST message body. How to solve this problem? The use of Keep-Alive in the POST request header is prohibited according to the instructions above, or the CRLF is automatically ignored by the server, which is automatically ignored by most servers, but it is impossible to know whether a server will do this without testing it. 

 

Java implementation -- client

On the client side, Java abstracts Keep-Alive and shares it with the programmer. The HttpURLConnection class automatically implements Keep-Alive. If the programmer does not intervene to operate Keep-Alive, Keep-Alive will pass through a HttpURLConnection class inside the client. instance object to automatically implement. That is to say, keep-alive in java is implemented by a Java class library, but not necessarily available in other class libraries.

 

Java implementation - server side
On the server side, Java still abstracts Keep-Alive, and the HttpServlet, HttpServletRequest, and HttpServletResponse classes automatically implement Keep-Alive. Some operations controlled by third parties are possible in this case, such as JavaWebServer mentioned in KeepAliveServlet, whether Keep-Alive is enabled or not is determined by two factors, content-length and output size, if content-length is part of the response (i.e. After the content length is output, there is still content to be output), then Keep-Alive is enabled (of course, if the client supports it); if the content length is not set, the servlet will try to calculate the response buffer length to determine the content Length, in the Javasoft implementation, uses a 4KB buffer (equivalent to the response mentioned above). That is to say, if the content length is not set and the returned data exceeds 4KB, it means that the content length is greater than the response length, not a part of the response length, and Keep-Alive will not be enabled.