jmeter stress test (stepping on the pit) error: Address already in use

Recently, I was writing a search interface service. After writing the interface, I carried out a stress test, but the following error will be reported when the long-term thread is high for testing:

java.net.BindException: Address already in use: 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.socket.PlainConnectionSocketFactory.connectSocket(PlainConnectionSocketFactory.java:75)
        at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
        at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl$JMeterDefaultHttpClientConnectionOperator.connect(HTTPHC4Impl.java:331)
        at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:373)
        at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:394)
        at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:237)
        at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
        at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
        at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
        at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
        at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.executeRequest(HTTPHC4Impl.java:832)
        at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:570)
        at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:67)
        at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1231)
        at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1220)
        at org.apache.jmeter.threads.JMeterThread.doSampling(JMeterThread.java:622)
        at org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:546)
        at org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:486)
        at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:253)
        at java.lang.Thread.run(Unknown Source)

Troubleshooting:

First check the server log and find that there is no error. Then check the nginx data and find that the number of requests is inconsistent with the number of requests sent by the test, and the server receives less, so it is thought of missing requests. Later, after searching for information, I found out that it was a problem with the windows machine. The reason: the ports provided by windows for TCP/IP connections are 1024-5000, and it takes four minutes to recycle them, which causes us to run a large number of requests in a short period of time. It is full, resulting in the above error.

Solution (operate on the server where jmeter is located):

1. Enter the regedit command in cmd to open the registry;
2. Right-click Parameters in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters;
3. Add a new DWORD named MaxUserPort;
4. Then double-click MaxUserPort, and enter the value data as 65534, choose decimal as the base;
5. After completing the above operations, be sure to restart the machine, and the problem is solved.
The test results after the solution will no longer report an error: 1a249e0ec0f2c1e80f307a48b7297b60.pngSupplement: I can perform a normal test after modifying the above problem, but after two days after increasing the number of threads, the same problem occurs again, and the following configuration will test normally. After the above three steps, add TcpTimedWaitDelay, the value is 30-300, choose decimal. Still need to restart the computer.

d778c2bc1ae88003636fcc8d85d8ed83.jpeg

Guess you like

Origin blog.csdn.net/dot_life/article/details/129312190