During the performance test, we also need to simulate whether some abnormal data will appear when the network is abnormal. The most common one is the database writing operation. For example, when we place an order, if there is a network abnormality, will the data not match the situation?
For example, the number of successful requests sent by our JMeter does not match the order data stored in the final database table. This usually occurs when the network is abnormal, because many frameworks usually have retry functions, such as APP in Send a network request to the server. If the network is unstable during this request and no response is received, the APP will try again. However, in this case, we need to consider whether there will be repeated orders and two transactions will be generated. The status of the order.
Usually our server usually has a certain mechanism to handle this situation, but we need to test whether this mechanism on the server side is effective.
Introduction to tc tools
Usually we use the tc tool on the application server to simulate network packet loss . The tc tool works on the server side and is specifically designed to carry out some related strategies for network cards. For example, when our request is sent to the network card, in fact, the request has not yet entered the program at this time, then we can increase the delay time or lose packets when the network card comes out.
Simulating latency and packet loss in Linux
Before simulating packet loss, we now look at the network card of our machine. We can see that our network card is eth0.
Then I now ping our application server on this machine to confirm that the network is normal.
Set delay
1. At this time, we set the delay, where eth0 is the name of our network card. The following command adds a 30ms delay when sending packets to the eth0 port.
tc qdisc add dev eth0 root netem delay 30ms
After setting the delay, we can see that the time is already around 40ms.
2. Display delay settings
3. Modify the delay
tc qdisc change dev eth0 root netem delay 40ms
4. Delete delay configuration
tc qdisc del dev eth0 root netem delay 40ms
You can see that after deleting the delay, the time returns to around 10ms.
Simulate packet loss
1. Set packet loss
tc qdisc add dev eth0 root netem loss 10%
If you look again, you can see that packet loss has occurred.
If you log in to the device through SSH to configure packet loss, after configuring this command, you will feel that the machine access is a bit stuck. This shows that the device has started to lose packets, which can be checked by specifically capturing packets.
For other commands such as modification, viewing, and deletion, you can refer to the delay settings above.
Finally, I would like to thank everyone who reads my article carefully. Reciprocity is always necessary. Although it is not a very valuable thing, if you can use it, you can take it directly:
This information 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 also help you!