Netperf and network performance measurement

http://www.ibm.com/developerworks/cn/linux/l-netperf/

When building or managing a network system, we are more concerned about the availability of the network, that is, whether the network connectivity, but for its overall performance is often not considered, or even consider the problem of performance, but found no appropriate means to test the performance of the network.

When we develop a network application, we will find that in the actual use of the network environment, the use of network applications is not very good, the problem may occur in the development of the program, but also may be due to the actual network environment bottlenecks. In the face of this problem, programmers generally do not know, the reason is not master some network performance measurement tools.

In this paper, we first introduce some basic concepts and methods of network performance measurement, and then combine the use of netperf tools to discuss how to test network performance in different situations. Network Performance Test Overview Five indicators of network performance measurement

Five metrics for measuring network performance are: Availability (availability) response time (response times) Network Utilization (network Utilization) network throughput (network throughput) Network bandwidth capacity (network bandwidth capacity)

1. Availability of

The first step in testing network performance is to determine whether the network is working correctly, and the easiest way is to use the ping command. The network works by sending ICMP echo request to the remote machine and waiting to receive the ICMP echo reply to determine if the remote machine is connected.

The ping command has very rich command options, such as-C to specify the number of Echo request sent, and-s to specify the size of the ping package to send each time.

Network devices typically have multiple buffer pools, and different buffer pools use different buffer sizes, respectively, to handle different sizes of groupings (packet). For example, a switch typically has three types of package buffering: one for small groupings, the other for medium sized groupings, and a class for large groupings. To test such a network device, the test tools must have the ability to send different size groupings. The Ping command-s can be used on this occasion.

2. Response time

The echo request/reply of the Ping command takes time to return to a round trip, which is the response time. There are many factors that affect response time, such as Network load, network host load, broadcast storm, dysfunctional network equipment, and so on.

When the network is working properly, log the normal response time. When users complain that the response time of the network is slow, the response time can be compared with the normal response time, if the difference is very large, it can explain the network equipment failure.

3. Network utilization

Network utilization refers to the proportion of the time that the network is used to the total time (that is, the time used + idle time). For example, while Ethernet is shared, it can only have one message in transit. So at any one time, the Ethernet is either 100% utilization or 0% utilization.

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

4. Network throughput

Network throughput is the remaining bandwidth available to network applications at some point in time, between two nodes in the network.

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

Network throughput is highly dependent on current network load conditions. Therefore, in order to get the correct network throughput, it is best to test them at different times (at different times of the day, or in different days of the week), so that you can gain a comprehensive understanding of network throughput.

Some network applications work correctly during the testing of the development process, but are not working properly in the actual network environment (due to insufficient network throughput). This is because the test is only in the idle network environment, not taking into account the actual network environment there are other kinds of network traffic. Therefore, it is meaningful to define the network throughput as the remaining bandwidth.

5. Network bandwidth capacity

Unlike network throughput, network bandwidth capacity refers to the maximum available bandwidth between two nodes of the network. This is determined by the ability of the equipment that makes up the network.

There are two difficulties in testing network bandwidth capacity: How to know the maximum available bandwidth of the network when other network traffic exists, and how to not affect the existing network traffic during the testing process. Network testing tools generally use packet pairs and packet trains technology to overcome such difficulties. ways to collect network performance data

When the test metrics of network performance are determined, the network test tools are used to collect the corresponding performance data, and there are three ways to get the data from the network respectively:

1. Access via SNMP protocol directly to a network device, such as the Net-snmp tool

2. Listening for related network performance data, the typical tool is tcpdump

3. Generate the appropriate test data for yourself, such as the Netperf tool used in this article

Back to the top of the page Netperf

Netperf is a kind of network performance measurement tool, mainly for TCP or UDP based transmission. Depending on the application, Netperf can perform different modes of network performance testing, that is, bulk data transfer (bulk data transfer) mode and request/reply (request/reponse) mode. The Netperf test results reflect how quickly a system can send data to another system, and that another system can receive data at multiple speeds.

Netperf tools work in a client/server manner. The server side is NetServer, which listens for connections from the client side, and the client side is Netperf, which is used to initiate network testing to the server. Between client and server, first establish a control connection, pass information about the test configuration, and test results; After the control connection establishes and passes the test configuration information, a test connection is established between the client and server to pass the special traffic pattern back and forth. To test the performance of the network. 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 to pay the price. TCP protocol to ensure the reliability of the measures, such as the establishment and maintenance of connections, control of the orderly transmission of data will consume a certain amount of network bandwidth.

Netperf can simulate three different TCP traffic patterns:

1 A single TCP connection, bulk (bulk) transmission of large amounts of data

2 A single TCP connection, the client requests/server reply transaction (transaction) mode

3 Multiple TCP connections, a pair of request/response transactions in each connection UDP network performance

UDP does not have a connection burden, but UDP does not guarantee transmission reliability, so applications that use UDP need to keep track of each outgoing packet and send lost groupings.

Netperf can simulate two types of UDP traffic patterns:

1 one-way bulk transfer from client to server

2. Request/Reply Transaction Mode

Because of the unreliability of UDP transmissions, when using Netperf to ensure that the buffer size being sent is not greater than the receive buffer size, the data will be lost and Netperf will give the wrong result. Therefore, the statistics that receive the packets are not necessarily accurate and need to be concluded in combination with the statistical synthesis of the packets sent. command line arguments for Netperf

In a UNIX system, you can run an executable program directly to start a netserver, or you can have inetd or xinetd come from a dynamic startup NetServer.

When NetServer is started on the server side, it is possible to run Netperf on the client side to test the performance of the network. Netperf controls the type of test and specific test options by using command-line arguments. Depending on the scope of action, the command-line arguments for Netperf can be grouped into two broad categories: Global command-line arguments, test-related local parameters, and separated by:

netperf [Global options]--[test-specific options]

Here we only explain those commonly used command-line parameters, other parameters readers can query the Netperf man manual.

-H Host: Specifies the server IP address of the remote running NetServer.

-L Testlen: Specify the length of time for the test (seconds)

-T testname: Specifies the type of test to be performed, including TCP_STREAM,UDP_STREAM,TCP_RR,TCP_CRR,UDP_RR, which are described separately in the following sections.

In a later test, NetServer runs in 192.168.0.28,server with the client via a LAN connection (100M Hub). netperf Test Network performance

test the performance of bulk (bulk) network traffic

Typical examples of bulk data transfer are FTP and other similar network applications (that is, transferring the entire file at one time). According to the use of transport protocol, the bulk data transmission is divided into TCP bulk transmission and UDP bulk transmission.

1. Tcp_stream

Netperf TCP Bulk Transport By default, that is,-t tcp_stream. During testing, Netperf sends bulk TCP data packets to NetServer to determine throughput during data transfer:

./netperf-h 192.168.0.28-l
TCP STREAM TEST to 192.168.0.28
Recv   send    send
socket socket  Message  Elapsed size size size time     throughput
bytes  bytes   bytes    secs.    10^6bits/sec
 
 87380  16384  16384    60.00      88.00

From the results output of netperf, we can know some of the following information:

1 The remote system (IE server) uses a socket with a size of 87380 bytes to receive the buffer

2 The Local System (IE client) uses a socket with a size of 16384 bytes to send a buffer

3 The test packets sent to the remote system have a size of 16384 bytes

4 The Test experience time is 60 seconds

5 The throughput test result is 88mbits/seconds

By default, Netperf sets the test group size sent to the socket send buffer size used by the local system.

The local parameters associated with testing in the Tcp_stream mode are shown in the following table:

Parameters	Description
-S size	Set the socket send and receive buffer size for the local system
-S size	Set the socket send and receive buffer size for the remote system
-M size	Set the size of the local system to send test groupings
-M size	Set the remote system to receive test grouping size
-D	Setting the Tcp_nodelay option for sockets on local and remote systems

By modifying the above parameters and observing the changes in the results, we can determine what factors affect the throughput of the connection. For example, if a router is suspected of having problems forwarding large groupings due to a lack of sufficient buffer space, you can increase the size of the test group (m) to see the throughput changes:

/netperf-h 192.168.0.28-l---m 2048
TCP STREAM TEST to 192.168.0.28
Recv   send    send
Socket Socke T message Elapsed size size size time     throughput
bytes  bytes   Bytes    secs.    10^6bits/sec
 
 87380  16384   2048    60.00      87.62

Here, the size of the test packet is reduced to 2048 bytes, while the throughput is not significantly changed (compared to the test packet size of 16K bytes in the previous example). Conversely, if there is a significant increase in throughput, it is true that routers in the middle of the network do have a buffer problem.

2. Udp_stream

Udp_stream is used to test network performance for UDP bulk transfers. It is important to note that at this point the size of the test packet must not be greater than the socket's send and receive buffer size, otherwise Netperf will report error prompts:

./netperf-t udp_stream-h 192.168.0.28-l
UDP unidirectional send TEST to 192.168.0.28
udp_send:data send err Or:message too long

To avoid this situation, you can limit the size of the test group by command-line arguments or increase the Send/Receive buffer size for the socket. The Udp_stream method uses the same local command-line arguments as the Tcp_stream method, so here 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    size     time         Okay Errors   throughput
bytes            bytes secs #      #   10^6bits/sec
 
 65535    1024   9.99       114127      0      93.55
 65535           9.99       114122             93.54

The results of the Udp_stream method have two rows of test data, the first line showing the local system's send statistics, where throughput represents the ability of netperf to send packets to the local socket. However, we know that UDP is an unreliable transport protocol and that the number of packets sent out does not necessarily equal the number of packets received.

The second line shows what the remote system receives, because the client is connected directly to the server, and there is no other traffic in the network, so the local system sends past packets that are almost all received by the remote system, and the throughput of the remote system is almost equal to the delivery throughput of the local system. However, in the actual environment, the general remote system's socket buffer size is different from the local system socket buffer size, and because of the reliability of UDP protocol, the receiving throughput of the remote system is much less than the throughput sent out.

test the performance of request/Answer (Request/response) network traffic

Another kind of common network traffic type is the Request/response mode applied in client/server structure. In each transaction (transaction), the client sends a small query packet to the server, and the server receives the request and returns large result data after processing. As shown in the following illustration:

1. Tcp_rr

The test object in TCP_RR mode is the transaction process of multiple TCP request and response, but they occur in the same TCP connection, which often occurs in database applications. After the client program of the database establishes a TCP connection with the server program, a multiple transaction process of the database is transmitted in this connection.

./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     size    time     Rate
bytes  bytes  bytes    bytes   .    Per sec
 
16384  87380  1        1       10.00    9502.73
16384  87380

The result of the Netperf output is also made up of two rows. The first line shows the local system, and the second line shows the remote system information. The average transaction rate (transaction rate) is 9502.73 times/sec. Note that the size of the request and response groupings in each transaction is 1 bytes, which is not of great practical significance. The user can change the size of the request and response groupings by testing the relevant parameters, and 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 groupings
-S size	Set the socket send and receive buffer size for the local system
-S size	Set the socket send and receive buffer size for the remote system
-D	Setting the Tcp_nodelay option for sockets on local and remote systems

By using the-r parameter, we can do more practical testing:

./netperf-t tcp_rr-h 192.168.0.28---R 32,1024
TCP request/response TEST to 192.168.0.28 local/remote sock
ET Size   Request  Resp.   Elapsed  Trans.
Send   Recv   size     size    time     Rate
bytes  bytes  bytes    bytes   .    Per sec
 
16384  87380       1024    10.00    4945.97
16384  87380

As can be seen from the results, the Request/reponse packet size increased, resulting in a significant decline in the transaction rate. Note: In contrast to the actual system, the transaction rate calculation does not fully take into account the application processing delay in the transaction process, so the results tend to be 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, where each HTTP transaction is performed in a separate TCP connection. Therefore, the transaction rate is bound to be greatly affected by the need to constantly establish new TCP connections and to remove TCP connections after the transaction is over.

./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     size    time     Rate
bytes  bytes  bytes    bytes   .    Per sec
 
131070 131070 1        1       9.99     2662.20
16384  87380

Even with a byte of Request/response grouping, the transaction rate is significantly reduced, only 2662.2 times per second. TCP_CRR uses the same local parameters as the TCP_RR.

3. Udp_rr

The UDP_RR method uses UDP to group the Request/response transaction process. Due to the lack of the burden of TCP connections, we speculate that the transaction rate will certainly increase accordingly.

./netperf-t udp_rr-h 192.168.0.28 
UDP request/response TEST to 192.168.0.28
local/remote
Socket size< C28/>request  Resp.   Elapsed  Trans.
Send   Recv   size     size    time     Rate
bytes  bytes  bytes    bytes   .    Per sec
 
65535  65535  1        1       9.99     10141.16
65535  65535

The result confirms our assumption that the transaction rate is 10141.16 times per second, higher than the TCP_RR value. However, if the opposite results, that is, the transaction rate has decreased, there is no need to worry, because this shows that in the network, routers or other network devices to UDP with TCP different buffer space and processing technology.

Back to first closing

In addition to Netperf, there are many other network performance testing tools, such as DBS, Iperf, Pathrate, Nettest, NetLogger, Tcptrace, ntop, and so on. These tools have their own characteristics and different focus, we can according to the specific application environment, selective use of them, so that these tools can play the most effective. Although they are open source software, but the functionality of these tools and commercial network testing tools as strong, but also has been widely used, familiar with these tools for our practical work will be a great help. reference materials Network performance Open Source Toolkit, Richard Blum, Wiley Publishing, Inc. netperf website, http://www.netperf.org