1. request request timeout setting
timeout The timeout time can be set manually. Create a new http request, find the "Timeout" setting in the "Advanced" settings, and set the connection and response time to 2000ms.
1. The requested connection timed out and the server could not be connected.
Phenomenon:
Jmeter's performance is as follows: the first few requests are successful, but some subsequent requests will report errors, and some requests are successful.
Error 1:
Response code: Non HTTP response code: java.net.SocketTimeoutException
Response message: Non HTTP response message: connect timed out
reason:
Generally, it is because there are too many threads, and the connection time out error server requests too many to handle.
The time to check the Load time is greater than the connect time out time set by the request, so this exception is thrown. It may be caused by the fact that there are many requests being processed by the server and the processing time is long, so that jmeter cannot connect to the server.
Solution: set jmeter http request timeout conn, restart server
Error 2:
Connection timed out: connect tool
java.net.ConnectException: Connection timed out: connect
at java.net.DualStackPlainSocketImpl.connect0(
reason:
This is mostly due to the exhaustion of port numbers. Usually the port number of a server is most likely 65535. It is recommended to use this command to check the port usage status of the stress test machine and the server respectively, netstat -nat|grep -i 8080|wc -l , if the number is around 6w, it may be that the port number is exhausted. At the same time, check the status of most ports, which should be in the time_wait state.
Solution: If the port number of the pressure testing machine is exhausted, add more pressure testing machines and use jmeter distributed pressure testing (jmeter turns on keep_alive by default)
If you count servers and the port numbers are exhausted, the most likely reason is that the server has opened a short connection. Just change the short connection configuration into a long connection.
If the server side is a short connection, every time jmeter initiates a request, it will create a TCP three-way handshake. After the data is transmitted, the link is actually not closed. The link status is time_wait. When the next request comes, a new port will be reopened and created. TCP three-way handshake, transmitting data....
In this way, as the number of requests increases, the ports will become less and less, so the ports will be exhausted quickly, and most ports are in the time_wait state. If the server also supports long connections, then the next request will come , transmission will continue on the last requested channel, and the port usage will be greatly reduced, effectively avoiding the problem of port exhaustion. For normal operation, each request can be given a timeout period to avoid http timeout errors.
2. The connection is successful, but the read times out.
If you cannot wait for the data returned by the server, it is usually because the amount of queries requested this time is large, such as checking the vertices of 5 degrees. (timeout is less than the maximum waiting time of the server) read time out error
jmeter disconnects the request before it can wait for the data returned by the server.
Response code: Non HTTP response code: java.net.SocketTimeoutException
Response message: Non HTTP response message: Read timed out
When this error occurs, jmeter is already connected to the server. Check that the load time does not exceed the set request timeout. The possible cause of the error is that the server has not processed the request of the thread, or the connection has been disconnected to ensure service capabilities.
In order to verify the guess, the concurrent number of requests is sent to the server for more than half an hour. After a period of time, the request receives a 503 response, confirming the guess.
3. The connection is successful, but the server times out when querying data.
This is because of the server timeout mechanism caused by the request in 2. If the query time exceeds 30s, an error will be automatically reported. (timeout is greater than the waiting time of the server). On the basis of 2, a large response time has been set, but it is still timeout. This should mean that the server has timed out before it can wait for the data returned by the database.
2. Problems existing in the press itself
1. In network programming, especially when there are too many new network connections in a short period of time, it often occurs
java.net.BindException: Address already in use: JVM_Bind exception
Java.NET.BindException: Address already in use: connect
reason:
There are too many new socket operations in a short period of time, and the socket.close() operation cannot release the bound port immediately. Instead, it sets the port to the time_wait state and releases it after a period of time (default 240s). You can see this with netstat -na , and finally the system resources are exhausted (on Windows, the pool of ephemeral ports is exhausted, this interval is between 1024-5000)
Solution:
On the machine running jmeter agent, add the registry entry
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
MaxUserPort 65334
TcpTimedWaitDelay 30
jmeter tool running settings:
1. In cmd, use the regedit command to open the registry
2. 在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
3. Right-click Parameters
4. Create a new DWORD value and set it (decimal) to 30 seconds. Name: TcpTimedWaitDelay, value: 30. Create a new DWORD value, (decimal) the maximum number of connections is 65534. Name: MaxUserPort, value: 65534
5. Select decimal as the base; to increase the number of allocable tcp connection ports and reduce the survival time of connections in the TIME_WAIT state
6. After modifying the configuration, remember to restart the machine for it to take effect.
jmeter returns java.net.SocketException: Connection reset after sending the request
This indicates that there is a problem with the test server. You can go to the page to verify it. It may be possible to configure client settings such as the tool run settings above.
java.net.SocketException: Socket closed
step1:
Find the advanced implementation in http request, select httpclient 4, and set connect to 15000-300000 milliseconds.
step2:
In the bin directory of the jmeter installation directory, find jmeter.properties and open it. Open the comment on line 425 and set the value to 1:
httpclient4.retrycount = 1
httpclient4.idletimeout=<time in 1000 ms>
java.lang.OutOfMemoryError: Java heap space
reason:
Observe the memory of the machine running jmeter. The memory usage is high and exceeds the memory limit set by jmeter.
solution:
Modify the jmeter configuration file and adjust the memory available range server
Modify the /bin/jmeter.bat file: find these 2 lines
set HEAP=-Xms256m -Xmx256m
set NEW=-XX:NewSize=128m -XX:MaxNewSize=128m
Change to:
set HEAP=-Xms1024m –Xmx2048m (the maximum value cannot exceed 1/2 of the system memory)
set NEW=-XX:NewSize=128m -XX:MaxNewSize=512m network
{ "_t" : "StringResultObject", "status" : 1030, "message" : "Server error", "data" : null, "isSuccess" : false }
If you encounter the response returned by the above request, you must first go to the server-side logs and use the logs to locate the problem.
Failed to initialise remote engine java.rmi.ConnectException: Connection refused to host:
reason:
During distributed testing, there is a problem with the link between the server and the agent. After troubleshooting a single machine, it was found that an agent machine had multiple network cards installed. When rmi was remote, it was looking for the network card of the virtual machine, causing the link to fail.
solution:
Disable unused virtual machine network cards and restore them after testing
java.lang.OutOfMemoryError: Java heap space
reason:
jmeter is a pure Java development tool. The memory is managed by the Java virtual machine JVM. When the memory is not recycled in time and the heap memory is insufficient, a memory overflow error will be reported.
Concept supplement:
Memory leak: The application does not release resources in time after using them, causing unnecessary resources to be held in the application memory.
Memory overflow: The application's memory can no longer meet normal usage, and the stack has reached the maximum value set by the system, leading to a crash.
It is usually due to memory leaks that cause the stack memory to continue to increase, resulting in memory overflow. The same is true for jmeter. During the jmeter test, if the memory overflows, the above prompt will generally appear: java.lang.OutOfMemoryError: Java heap space means heap memory overflow and not enough.
Solution:
Knowing that the reason for the error is due to insufficient heap memory size, it is natural to think of a solution to memory overflow: adjusting the heap memory size.
Steps (take Windows system as an example, Linux system is similar):
1. Open the jmeter.bat file, search by the keyword "HEAP", and change the original configuration to the following: Before modification:
if not defined HEAP (
rem See the unix startup file for the rationale of the following parameters,
rem including some tuning recommendations
set HEAP=-Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m
)
)
After modification:
if not defined HEAP (
rem See the unix startup file for the rationale of the following parameters,
rem including some tuning recommendations
set HEAP=-Xms512m -Xmx4000m
set NEW=-XX:NewSize=256m -XX:MaxNewSize=512m
)
set HEAP=-Xms512m -Xmx4000m: adjust the size of the heap memory
set NEW=-XX:NewSize=256m -XX:MaxNewSize=512m: Adjust the size of the new band in the heap memory
PS：
This value is not bigger, the better, it depends on the machine used for the stress test. Generally speaking, the maximum value of heap memory should not exceed half of the physical memory, otherwise it will easily cause jmeter to run slowly, freeze or even memory overflow (because of Java itself The garbage collection mechanism of the system is to dynamically allocate memory, which will take up a lot of memory when it is adjusted), and the memory allocated by NEW should not be too large.
1. After the modification is completed, save it and restart JMeter to take effect.
3. Summary
1. This method of modifying the heap size is only applicable to some situations and is not universal. When the number of threads to be simulated is large, distributed stress testing needs to be adopted according to the specific situation.
2. When running jmeter from the command line, be sure to disable listeners such as "View Result Tree" and "Aggregation Report" because it really consumes memory.
3. Disk monitoring tools include iostat & htop.
4. Network monitoring tools include iftop.
5. To check the network connection status, use netstat -n | find /I "established" /c.
Finally, I would like to thank everyone who has read my article carefully. Reciprocity is always necessary. Although it is not a very valuable thing, you can take it away if you need it:
These materials should be the most comprehensive and complete preparation warehouse for [software testing] friends. This warehouse has also accompanied tens of thousands of test engineers through the most difficult journey. I hope it can help you too!