Netperf and network performance measurement

This article first introduces some basic concepts and methods of network performance measurement, and then discusses how to test network performance in different situations based on the use of the netperf tool.

Tang kai (tangk73@hotmail.com ),

July 01, 2004

• Content

When building or managing a network system, we are more concerned about the availability of the network, that is, whether the network is connected. However, we often do not consider the overall performance of the network, or even considering the performance issues, we find that there is no proper way to test the network performance.

When a network application is developed, we will find that in actual network environments, the use of network applications is not very effective, and the problem may occur in program development, it may also be caused by bottlenecks in the actual network environment. In the face of such problems, programmers are generally unable to do anything, because they do not master some network performance measurement tools.

In this article, we will first introduce some basic concepts and methods of network performance measurement, and then discuss how to test network performance in different situations based on the use of the netperf tool.

Network Performance Test overview five network performance measurement indicators

The following are the five indicators used to measure network performance:

• Availability)
• Response time)
• Network utilization)
• Network throughput)
• Network bandwidth capacity)

1. Availability

The first step to test network performance is to determine whether the network works normally. The simplest method is to use the ping command. Send the icmp echo request to the remote machine and wait for the icmp echo reply to be received to determine whether the remote machine is connected and whether the network works properly.

The Ping Command has rich Command Options. For example,-c can specify the number of echo requests sent, and-s can specify the size of the ping packet sent each time.

A network device generally has multiple buffer pools. Different buffer pools use different buffer sizes to process different groups (packet ). For example, a vswitch usually has three types of Packet buffering: one for small groups, the other for medium-size groups, and the other for large groups. To test such a network device, the test tool must be able to send packets of different sizes. The Ping Command-s can be used in this scenario.

2. Response Time

The time it takes to Ping the echo request/reply round-trip command is the response time. There are many factors that affect the response time, such as network segment load, network host load, broadcast storm, and abnormal network devices.

When the network works normally, record the normal response time. When users complain about slow network response time, they can compare the current response time with the normal response time. If the difference between the two is large, it indicates that the network device is faulty.

3. Network Utilization

Network Utilization refers to the proportion of the time used by the network to the total time (that is, the time used + the idle time. For example, although Ethernet is shared, only one packet can be transmitted at the same time. Therefore, at any time, Ethernet, 100% utilization, or 0% utilization.

It is relatively easy to calculate the network utilization of a network segment, but it is complicated to determine the utilization of a network. Therefore, network testing tools generally use network throughput and network bandwidth capacity to determine the performance between two nodes in the network.

4. network throughput

Network throughput refers to the remaining bandwidth that is provided to the network application between two nodes in the network at a certain time point.

Network throughput can help groups find bottlenecks in network paths. For example, even if both the client and server are connected to their respective 100 M Ethernet, if the two 100 M Ethernet are connected by 10 M Ethernet, 10 M Ethernet is the network bottleneck.

The network throughput is very dependent on the current network load. Therefore, in order to get the correct network throughput, it is best to perform tests at different times of the day, or on different days of the week, only in this way can we get a comprehensive understanding of network throughput.

Some network applications can run normally during the development test, but cannot work normally in the actual network environment (because there is not enough network throughput ). This is because the test is only in an idle network environment, without considering the existence of other network traffic in the actual network environment. Therefore, it is of practical significance to define the network throughput as the remaining bandwidth.

5. network bandwidth capacity

Different from network throughput, network bandwidth refers to the maximum available bandwidth between two nodes in the network. This is determined by the capabilities of devices that make up the network.

There are two difficulties in testing the network bandwidth capacity: How to know the maximum available bandwidth of the network when other network traffic exists in the network; during the test, it does not affect the existing network traffic. Network testing tools generally use packet pairs and packet trains to overcome such difficulties.

How to collect network performance data

After determining the network performance test indicators, you need to use the network test tool to collect the corresponding performance data. There are three ways to obtain data from the network:

1. Get it directly from the network device through the snmp protocol, such as the net-snmp tool.

2. Listen for network performance data. A typical tool is tcpdump.

3. Generate Test Data by yourself, such as the netperf tool used in this article.

Back to Top

Netperf

Netperf is a network performance measurement tool, mainly for TCP or UDP-based transmission. According to different applications, Netperf can perform network performance tests in different modes, that is, bulk data transmission mode and request/response mode. The Netperf test results reflect how fast a system can send data to another system, and the other system can receive data at multiple blocks.

The Netperf tool works in client/server mode. The server is netserver, which is used to listen for connections from the client, and the client is netperf, which is used to initiate network tests to the server. First, establish a control connection between the client and the server to pass the test configuration information and test results. After the control connection is established and the test configuration information is passed, A test connection is established between the client and the server to pass back and forth a special traffic mode to test the network performance.

TCP network performance

Because the TCP protocol can provide end-to-end reliable transmission, it is used by a large number of network applications. However, the establishment of reliability is costly. Measures to ensure the reliability of the TCP protocol, such as establishing and maintaining connections and controlling the orderly transmission of data consume a certain amount of network bandwidth.

Netperf can simulate three different TCP traffic modes:

1) A single TCP connection transmits a large amount of data in bulk

2) A single TCP connection, client request/server Response transaction (transaction) Method

3) multiple TCP connections, one transaction method for a request/response in each connection

UDP network performance

UDP does not have the burden of establishing connections, but UDP cannot guarantee the reliability of transmission. Therefore, UDP applications need to track each sent group and resend the lost group.

Netperf can simulate two UDP traffic modes:

1) One-Way batch transmission from client to server

2) transaction method of request/Response

Due to the reliability of UDP transmission, when using netperf, make sure that the size of the sent buffer is not greater than the size of the received buffer. Otherwise, data will be lost and netperf will give an incorrect result. Therefore, the statistics of the received group are not necessarily accurate. Therefore, you need to draw a conclusion based on the statistics of the sent group.

Netperf command line parameters

In unix systems, you can directly run executable programs to start netserver, or enable inetd or xinetd to automatically start netserver.

After netserver is started on the server, you can run netperf on the client to test the network performance. Netperf Uses command line parameters to control the test type and specific test options. Depending on the scope, the netperf command line parameters can be divided into two categories: Global command line parameters and test-related local parameters. Use -- to separate the two:

netperf [global options]-- [test-specific options]

Here we only explain the commonly used command line parameters. Other parameters can be queried by the netperf man manual.

-H host: Specify the IP address of the server that runs netserver remotely.

-L testlen: Specify the test duration (in seconds)

-T testname: indicates the testing type, including TCP_STREAM, UDP_STREAM, TCP_RR, TCP_CRR, and UDP_RR.

In subsequent tests, netserver runs at 192.168.0.28, and the server and client are connected through a LAN (100 M Hub ).

Netperf testing network performance

Test the performance of bulk network traffic

Typical examples of batch data transmission include ftp and other similar network applications (that is, one transmission of the entire file ). Depending on the transmission protocol, batch data transmission is divided into TCP batch transmission and UDP batch transmission.

1. TCP_STREAM

By default, Netperf performs TCP batch transmission, that is,-t TCP_STREAM. During the test, netperf sends a batch of TCP data groups to netserver to determine the throughput during data transmission:

 ./netperf -H 192.168.0.28 -l 60TCP STREAM TEST to 192.168.0.28Recv   Send    SendSocket Socket  Message  ElapsedSize   Size    Size     Time     Throughputbytes  bytes   bytes    secs.    10^6bits/sec  87380  16384  16384    60.00      88.00

From the netperf result output, we can know the following information:

1) the remote system (that is, the server) uses a socket buffer of 87380 bytes.

2) the local system (client) uses a 16384-byte socket sending buffer.

3) The size of the test group sent to the far-end system is 16384 bytes.

4) The tested time is 60 seconds.

5) The throughput test result is 88 Mbits/s.

By default, netperf sets the size of the test group sent to the socket sending buffer used by the local system.

Test-related local parameters in TCP_STREAM mode are shown in the following table:

Parameters	Description
-S size	Set the size of the socket sending and receiving buffer in the Local System
-S size	Set the size of the socket sending and receiving buffer in the remote system
-M size	Set the size of the test group sent by the local system
-M size	Set the size of the Remote System Acceptance Test Group
-D	Set the TCP_NODELAY option for the local and remote system socket

By modifying the above parameters and observing the changes, we can determine what affects the connection throughput. For example, if you suspect that the vro lacks sufficient buffer space to cause problems in forwarding large groups, you can increase the size of the test group (-m) to observe the throughput changes:

 ./netperf -H 192.168.0.28 -l 60 -- -m 2048TCP STREAM TEST to 192.168.0.28Recv   Send    SendSocket Socket  Message  ElapsedSize   Size    Size     Time     Throughputbytes  bytes   bytes    secs.    10^6bits/sec  87380  16384   2048    60.00      87.62

Here, the size of the test group is reduced to 2048 bytes, but the throughput is not significantly changed (compared with the size of the test group in the previous example being 16 KB ). On the contrary, if the throughput is greatly increased, it indicates that the router in the middle of the network does have a buffer.

2. UDP_STREAM

UDP_STREAM is used to test the network performance during UDP batch transmission. Note that the size of the test group must not be greater than the size of the socket sending and receiving buffer. Otherwise, netperf reports an error:

./netperf -t UDP_STREAM -H 192.168.0.28 -l 60UDP UNIDIRECTIONAL SEND TEST to 192.168.0.28udp_send: data send error: Message too long

To avoid this situation, you can use the command line parameter to limit the size of the test group, or increase the size of the socket sending/receiving buffer. UDP_STREAM uses the same local command line parameters as TCP_STREAM. Therefore, you can use-m to modify the size of the group used in the test:

 ./netperf -t UDP_STREAM -H 192.168.0.28 -- -m 1024UDP UNIDIRECTIONAL SEND TEST to 192.168.0.28Socket  Message  Elapsed      MessagesSize    Size     Time         Okay Errors   Throughputbytes   bytes    secs            #      #   10^6bits/sec  65535    1024   9.99       114127      0      93.55 65535           9.99       114122             93.54

There are two rows of test data in the UDP_STREAM method. The first row shows the sending statistics of the local system. The throughput here indicates the ability of netperf to send packets to the local socket. However, we know that UDP is an unreliable transmission protocol, and the number of sent groups is not necessarily equal to the number of received groups.

The second line shows the remote system reception. Because the client is directly connected to the server and there is no other traffic in the network, therefore, almost all groups sent by the local system are correctly received by the remote system, and the throughput of the remote system is almost equal to that of the local system. However, in the actual environment, the socket buffer size of the remote system is generally different from the socket buffer size of the local system, and due to the unreliable UDP protocol, the receiving throughput of the remote system is much lower than the sending throughput.

Test the performance of request/response Network Traffic

Another common network traffic type is the request/response Mode Applied in the client/server structure. In each transaction (transaction), the client sends a small query group to the server. The server receives the request and returns large results after processing. As shown in:

1. TCP_RR

The TCP_RR test object is the transaction process of TCP request and response multiple times, but they occur in the same TCP connection. This mode is often used in database applications. After the client program of the database establishes a TCP connection with the server program, the connection transmits the database's transaction process multiple times.

./netperf -t TCP_RR -H 192.168.0.28TCP REQUEST/RESPONSE TEST to 192.168.0.28Local /RemoteSocket Size   Request  Resp.   Elapsed  Trans.Send   Recv   Size     Size    Time     Ratebytes  Bytes  bytes    bytes   secs.    per sec 16384  87380  1        1       10.00    9502.7316384  87380

The output result of Netperf is composed of two rows. The first line shows the local system, and the second line shows the information of the remote system. The average transaction rate is 9502.73 times per second. Note that the size of the request and response groups in each transaction is 1 byte, which is not of great practical significance. You can change the size of the request and response groups by testing related parameters. The parameters in the TCP_RR mode are shown in the following table:

Parameters	Description
-R req, resp	Set the size of the request and reponse groups.
-S size	Set the size of the socket sending and receiving buffer in the Local System
-S size	Set the size of the socket sending and receiving buffer in the remote system
-D	Set the TCP_NODELAY option for the local and remote system socket

By using the-r parameter, we can perform more practical tests:

./netperf -t TCP_RR -H 192.168.0.28 -- -r 32,1024TCP REQUEST/RESPONSE TEST to 192.168.0.28Local /RemoteSocket Size   Request  Resp.   Elapsed  Trans.Send   Recv   Size     Size    Time     Ratebytes  Bytes  bytes    bytes   secs.    per sec 16384  87380  32       1024    10.00    4945.9716384  87380

From the results, we can see that the transaction rate decreases significantly because the size of the request/reponse group increases. Note: compared with the actual system, the transaction rate calculation does not fully consider the application processing latency in the transaction process, so the results are often higher than the actual situation.

2. TCP_CRR

Unlike TCP_RR, TCP_CRR establishes a new TCP connection for each transaction. The most typical application is HTTP. Each HTTP transaction is performed in a separate TCP connection. Therefore, since new TCP connections need to be established constantly and the TCP connections need to be removed after the transaction ends, the transaction rate will be greatly affected.

./netperf -t TCP_CRR -H 192.168.0.28 TCP Connect/Request/Response TEST to 192.168.0.28Local /RemoteSocket Size   Request  Resp.   Elapsed  Trans.Send   Recv   Size     Size    Time     Ratebytes  Bytes  bytes    bytes   secs.    per sec 131070 131070 1        1       9.99     2662.2016384  87380

Even if a byte request/response Group is used, the transaction rate is significantly reduced, with only 2662.20 requests/second. TCP_CRR uses the same local parameter as TCP_RR.

3. UDP_RR

UDP_RR uses UDP grouping for request/response transactions. As there is no burden on TCP connections, we speculate that the transaction rate will definitely increase accordingly.

./netperf -t UDP_RR -H 192.168.0.28 UDP REQUEST/RESPONSE TEST to 192.168.0.28Local /RemoteSocket Size   Request  Resp.   Elapsed  Trans.Send   Recv   Size     Size    Time     Ratebytes  Bytes  bytes    bytes   secs.    per sec 65535  65535  1        1       9.99     10141.1665535  65535

The result confirms our speculation that the transaction rate is 10141.16 times/second, which is higher than the value of TCP_RR. However, if the opposite result is displayed, that is, the transaction rate is reduced, and you do not need to worry about it, because it indicates that in the network, vrouters or other network devices adopt different buffer space and processing technologies for UDP than TCP.

Back to Top

Conclusion

In addition to netperf, there are many other network performance testing tools, such as dbs, iperf, pathrate, nettest, netlogger, tcptrace, and ntop. These tools have their own characteristics and different focuses. We can choose to use them based on the specific application environment, so that these tools can play their maximum effect. Although they are open-source software, these tools are equally powerful and widely used as commercial network testing tools, familiarity with these tools will certainly be of great help to our practical work.