Network Test Tool Netperf

In general, we conduct network testing, mainly testing network connectivity, network bandwidth, network response time and so on. Common tools include ping, traceroute, Telnet, FTP, and so on. such as testing network connectivity, you can use Ping,traceroute, if the test firewall is configured correctly, you can use Telnet and traceroute-p, use the ping command to test the network latency, and FTP to test the network bandwidth.

However, if you need to do some more in-depth testing, such as testing different packet size of different types of business network processing capacity, you need more professional tools, such as Netperf,iperf.

Netperf Test Tool Introduction

Netperf is an open-source network performance testing tool. Can be installed on AIX and Linux platforms to support cross-platform use.

Netperf can test TCP network performance, UDP network performance, and can simulate client/server long connection or short connection scene, so it can be more close to the actual network environment for testing and evaluation.

Installation

The source code can be downloaded from the official website for compilation and installation. The installation process is basically a old three step, i.e.

./configcuremakemake install

The default installation path is the directory under/usr/local. In systems such as AIX, you may need to set the PATH environment variable yourself or change the installation path using the –prefix parameter.

For SuSE, during the installation, a compile error occurs when the kernel version is 2.6.16 (SuSE 10):

nettest_omni.o: In function `recv_data_no_copy‘:nettest_omni.c:(.text+0x6e44): undefined reference to `splice‘nettest_omni.c:(.text+0x6e7b): undefined reference to `splice‘collect2: ld returned 1 exit statusmake[3]: *** [netperf] Error 1make[3]: Leaving directory `/root/py/netperf-2.6.0/src‘make[2]: *** [all-recursive] Error 1make[2]: Leaving directory `/root/py/netperf-2.6.0/src‘make[1]: *** [all-recursive] Error 1make[1]: Leaving directory `/root/py/netperf-2.6.0‘

After checking that the splice system call was made after the 2.6.17 kernel version, it was compiled by SuSE 11.

If it's a version like Ubuntu, because Netperf is already available in the software library, you can install it with the Package manager. For example, use in Ubuntu:

sudo apt-get install netperf

Using the Start service

Netperf consists of two programs. One is the client netperf, which simulates various types of network behavior. The other is the server program NetServer. The request to receive the client. The operation to start the service resembles the following:

# netserverStarting netserver with host ‘IN(6)ADDR_ANY‘ port ‘12865‘ and family AF_UNSPEC

By default, the TCP service listener starts on port 12865. Can be modified with the-P parameter.

No UDP port was found, and it is estimated that the port will be enabled at test time based on the test project enabled by Netperf.

Netperf parameter Description

The Netperf parameter format is as follows:

Among them, the global options for the general parameters, all test projects are related to or common parameters, commonly used are:

-H host name or IP specifies the IP of the server running NetServer

-L Test length specifies the duration of the test in seconds

The-T test project specifies the content of the test. The test items are as follows:

TCP Bulk data transfer test Tcp_stream

                 TCP_SENDFILE                 TCP_MAERTS

TCP Request Answer (long connection) mode test TCP_RR

                 TCP_CRR

UCP Batch data transfer test Udp_stream

                 UDP_RR                 DLCO_STREAM                 DLCO_RR                 DLCL_STREAM                 DLCL_RR                 STREAM_STREAM                 STREAM_RR                 DG_STREAM                 DG_RR                 SCTP_STREAM                 SCTP_STREAM_MANY                 SCTP_RR                 SCTP_RR_MANY                 LOC_CPU                 REM_CPU

The test specific options is the parameter used for testing the item, and it is separated from the global parameter by a "–" similar

netperf -H 127.0.0.1 -l 30 -- -m 2048

The test item parameters are related to the test project.

Common test Project network bandwidth test

Bandwidth testing typically uses the-T Tcp_stream test item, which is also the default test project for Netperf. This test is similar to FTP to test the bandwidth of the system, but can be set more by parameters. Like what:

$ netperf -H 127.0.0.1 -l 60MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1 () port 0 AF_INET : demoRecv   Send    Send                          Socket Socket  Message  Elapsed              Size   Size    Size     Time     Throughput  bytes  bytes   bytes    secs.    10^6bits/sec   87380  16384  16384    60.00    

The first column is the socket buffer size of the service-side receive packet, not 87380

The second column is the size of the socket buffer where the client sends the data, 16384

The third column is the size of the message sent, here is 16384

The IV column is the test duration

The rate of the test is measured in m, where the result is 2.7G. Because localhost is used, it is actually the data that is sent and received in the native memory.

Common test parameters for Tcp_stream are:

-S buffer size specifies the buffer size of the client send data-s buffer size specifies the buffer size for the server to receive data

-m Send Message size unit bytes

-m Receive Message size unit bytes

You can adjust these parameters to see what factors affect the transfer rate. For example, the sending buffer is larger, the test results vary little:

1 2 3 4 5 6 7 8

$ Netperf- H 127.0.0.1-l---s 65535 migrated TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 af_inet to 1 27.0.0.1 () port 0 af_inet:demo recv send send socket sockets Message Elapsed size size size time throughput bytes bytes bytes secs. 10^6bits/sec 87380 131070 131070 60.00 2672.42

Changing the receive buffer and the packet size can improve performance:

$ netperf -H 127.0.0.1 -l 60 -- -S 65535 MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1 () port 0 AF_INET : demoRecv   Send    Send                          Socket Socket  Message  Elapsed              Size   Size    Size     Time     Throughput  bytes  bytes   bytes    secs.    10^6bits/sec  131070  16384  16384    60.00    3058.22   $ netperf -H 127.0.0.1 -l 60 -- -m 65535MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1 () port 0 AF_INET : demoRecv   Send    Send                          Socket Socket  Message  Elapsed              Size   Size    Size     Time     Throughput  bytes  bytes   bytes    secs.    10^6bits/sec   87380  16384  65535    60.00    3266.55   

Transmission performance of UDP protocol

Similar to the network bandwidth test, just replaced the protocol, so this project is Udp_stream:

$ netperf -H 127.0.0.1 -l 60 -t UDP_STREAMMIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1 () port 0 AF_INET : demoSocket  Message  Elapsed      Messages                Size    Size     Time         Okay Errors   Throughputbytes   bytes    secs            #      #   10^6bits/sec212992   65507   60.00      440506      0    3847.46212992           60.00      433151           3783.22

Unlike Tcp_stream, there are two rows of data in the test results. The first line is the client, and the second line is the service side.

The first column is the buffer size, and in the Netperf test, the buffer size on both sides is set as large.

Second column message size

Third column test transfer time

The IV is the amount of packets transmitted, UDP because the protocol does not guarantee transmission reliability, the number of messages sent and received is not the same, and the actual production environment can receive less than the package. From the data, the number of packets should be the number per second (the message size and speed of the unit is different)

Finally, the rate of testing can be seen faster than the TCP protocol. This is a decision of the agreement.

TCP Long Connection request Response mode test

In addition to network data transmission, a large amount of network traffic is request/response, that is, one party sends a message, the other side replies. And usually this kind of request and reply the message size is not the same big, even big difference. Netperf can simply simulate this type of scenario and conduct network performance testing. The test usage type is TCP_RR.

The simplest TCP_RR test is as follows:

$ netperf -H 127.0.0.1 -l 60 -t TCP_RRMIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1 () port 0 AF_INET : demo : first burst 0Local /RemoteSocket Size   Request  Resp.   Elapsed  Trans.Send   Recv   Size     Size    Time     Rate         bytes  Bytes  bytes    bytes   secs.    per sec   16384  87380  1        1       60.00    13517.65   16384  

The test result is divided into two lines, the first row is local, the second line is the remote (server side)

The first and second columns should still be buffers, just as opposed to the sequence of stream tests.

The third to fourth column is the size of the request and return package. The default is 1 bits.

Five as test time

The six is the transaction rate, this time the number of pens per second, no longer the bandwidth.

The default package size does not occur in the actual business, and can be adjusted by parameters to simulate the real situation. Use the test parameter-R to request packet size, answer packet size (-R request,response) to test. Note that this parameter unit is bytes, and the actual business is typically a byte-unit message:

$ netperf -H 127.0.0.1 -l 60 -t TCP_RR -- -r 64,2048MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1 () port 0 AF_INET : demo : first burst 0Local /RemoteSocket Size   Request  Resp.   Elapsed  Trans.Send   Recv   Size     Size    Time     Rate         bytes  Bytes  bytes    bytes   secs.    per sec   16384  87380  64       2048    60.00    13129.09   16384  

This test uses a 8-byte request, a 256-byte rebate package for testing, and a slight drop in the test result relative to the default value.

TCP Short Connection request response mode test

Another large class of TCP requests is a short connection request response message similar to the HTTP service. The corresponding test item is TCP_CRR:

$ netperf -H 127.0.0.1 -l 60 -t TCP_CRR             MIGRATED TCP Connect/Request/Response TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1 () port 0 AF_INET : demoLocal /RemoteSocket Size   Request  Resp.   Elapsed  Trans.Send   Recv   Size     Size    Time     Rate         bytes  Bytes  bytes    bytes   secs.    per sec   16384  87380  1        1       60.00    2210.55   16384  

Test parameters and display are similar to TCP_RR. The rate dropped sharply due to the impact of the business type.

UDP connection Request response mode test

Because of the UDP protocol, the UDP request answer is connected with no length. Only UDP_RR a test project, the test parameters are similar to the TCP class test:

$ netperf -H 127.0.0.1 -l 60 -t UDP_RR              MIGRATED UDP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1 () port 0 AF_INET : demo : first burst 0Local /RemoteSocket Size   Request  Resp.   Elapsed  Trans.Send   Recv   Size     Size    Time     Rate         bytes  Bytes  bytes    bytes   secs.    per sec   212992 212992 1        1       60.00    15837.63   212992 212992

Theoretically, UDP test results are better than TCP, but in the actual network, may be affected by network equipment configuration, there is a certain unknown.

How to perform a simulation test

First of all, test cases need to be well done. To identify the type of business, the agreement, to determine which test project to choose, to understand the characteristics of the business, such as the size of the general package information, in order to select the appropriate parameters. These parameters can be determined according to the business design or may need to be obtained through business monitoring data. For example, by monitoring the maximum amount of traffic and maximum IO in the data, the packet size can be roughly evaluated, which is, of course, imprecise.

Because the factors that determine network performance are part and configuration related, parameters such as buffer size can be changed in the test to see if the network parameters need to be adjusted.

Original link Address: http://pangyi.github.io/blog/20141210/wang-luo-ce-shi-gong-ju-netperf/
Written by pangyi?posted at Http://pangyi.github.io

Network Test Tool Netperf