Netperf and network performance measurement (zz)

Http://www.ibm.com/developerworks/cn/linux/l-netperf/#N1003F

 

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.

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 developedProgramThen, we will find that in the actual network environment, the use of network applications is not very good, the problem may occur in the development of the program, 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 indicators for network performance measurement

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 connection from the client, and the client is netperf, which is used to initiate a network test to the server. A control connection is established between the client and the server to pass information about the test configuration and the 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 60 TCP stream test to 192.168.0.28 Recv send Socket socket message elapsed size time throughput bytes secs. 10 ^ 6 bits/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 2048 TCP stream test to 192.168.0.28 Recv send Socket socket message elapsed size time throughput bytes secs. 10 ^ 6 bits/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 60 UDP unidirectional send test to 192.168.0.28 udp_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 1024 UDP unidirectional send test to 192.168.0.28 socket message elapsed messages size time Okay errors throughput bytes secs #10 ^ 6 bits/sec 65535 1024 9.99 114127 0 93.55 65535 9.99 114122

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.28 TCP request/response test to 192.168.0.28 local/remote socket size request resp. elapsed trans. send Recv size time rate bytes secs. per sec 16384 87380 10.00 1 9502.73 16384 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 using test-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, 1024 TCP request/response test to 192.168.0.28 local/remote socket size request resp. elapsed trans. send Recv size time rate bytes secs. per sec 16384 87380 1024 32 10.00 4945.97 16384 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.28 local/remote socket size request resp. elapsed trans. send Recv size time rate bytes secs. per sec 131070 131070 9.99 1 2662.20 16384 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.28 local/remote socket size request resp. elapsed trans. send Recv size time rate bytes secs. per sec 65535 65535 9.99 1 10141.16 65535 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 all are openSource codeBut 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.