I used Jmeter2.13 to test an http request of the website. The server is tomcat7. The number of 500 threads tested is normal. When the number is increased to 750, a connection refused error will occur. In general, an error occurs in Last request. The front is still correct. Try some online methods to increase the maximum number of threads of tomcat7 server.xml, and modify system parameters, etc. At this time, Central Processor and memory bandwidth are not full of IO, so I do not know where the bottleneck is? ? I hope anyone who has encountered similar situations or knows it can answer, thank you!
The error code in the result tree is as follows:
org.apache.http.conn.HttpHostConnectException: Connection tohttp://10.0.0.160:8080 refused
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:190) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294) at org.apache.jmeter.protocol.http.sampler.MeasuringConnectionManager$MeasuredConnection.open(MeasuringConnectionManager.java:107) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:643) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:479) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805) at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.executeRequest(HTTPHC4Impl.java:517) at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:331) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1146) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1135) at org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:434) at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:261) at java.lang.Thread.run(Unknown Source)
Caused by: java.net.ConnectException: Connection timed out: connect
at java.net.DualStackPlainSocketImpl.connect0(Native Method) at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source) at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source) at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source) at java.net.AbstractPlainSocketImpl.connect(Unknown Source) at java.net.PlainSocketImpl.connect(Unknown Source) at java.net.SocksSocketImpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:127) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180) ... 14 more
I have encountered a situation before, probably because the port number is exhausted. Generally, the port number of a server is 65535 at most. It is recommended to use this command to check the port usage of the down-pressure tester and the server respectively. Netstat-NAT | GREP-i8080 | WC-L. If this number is about 6w, it may be that the port number is exhausted. At the same time, to check the status of most ports, it should be time_wait status.
If it is a pressure measuring machine and the port number is exhausted, increase the pressure measuring machine and use jmeter distributed pressure measurement (jmeter opens keep_alive by default)
If the server is counted and the port number is exhausted, the most likely is that the server has opened the Short link and the Short link configuration can be changed into a long connection.
Because if the server is Short link, every time jmeter initiates a request, it will establish a tcp three-way handshake. After the data is transmitted, the connection is actually irrelevant. The connection status is time_wait. When the next request comes, a new port will be reopened, tcp three-way handshake will be established, and the data will be transmitted …. As more and more requests are made, the ports will become fewer and fewer, so the ports will run out quickly. Moreover, most ports are in the state of time_wait. if the server side also supports long connections, the next request will continue to transmit on the channel requested last time, thus greatly reducing the utilization rate of ports and effectively avoiding the problem of port exhaustion.