http://pangyi.github.io/blog/20141210/wang-luo-ce-shi-gong-ju-netperf/
Network testing tools netperf
Generally, we tested the network, primarily to test network connectivity, network bandwidth, network response time. Common tools include ping, traceroute, telnet, ftp and so on. The test network connectivity, ping may be used, the traceroute, test if the firewall is configured properly, can use telnet and traceroute -p, ping command to test network delays, ftp to test the network bandwidth.
But if you need to do some more in-depth testing, such as testing different types of service packages of different sizes of network processing power, you need more specialized tools, such as netperf, iperf and so on.
netperf testing tools
netperf is an open source network performance testing tool. It can be installed on AIX and LINUX platforms to support cross-platform use.
TCP network performance test can be performed netperf, UDP network performance, and can simulate Client / Server short or long connect the scenes, and therefore can be closer to the actual network environment for testing and evaluation.
installation
From the official website you can download the source code to compile and install. The installation process is basically the old three steps, namely
./configcure
make
make install
Each path is the default installation directory under / usr / local. In AIX systems, you may need to set your PATH environment variable, change the installation path or use -prefix parameters.
For SUSE , installation found is 2.6.16 (SUSE 10), a compilation error will appear in the kernel version:
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 status
make[3]: *** [netperf] Error 1
make[3]: Leaving directory `/root/py/netperf-2.6.0/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/root/py/netperf-2.6.0/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/py/netperf-2.6.0'
The investigation, splice system call appeared after the 2.6.17 version of the kernel, thus changing the compiler by using SUSE 11.
If you are like UBUNTU version, because the software library has been netperf, you can install with your package manager. For example, use UBUNTU:
sudo apt-get install netperf
use
Start Service
netperf includes two programs. A client netperf, used to simulate various types of network behavior. Another netserver for the server program. Receiving a request for the client. Operation Starting services like:
# netserver
Starting netserver with host 'IN(6)ADDR_ANY' port '12865' and family AF_UNSPEC
By default start listening TCP service on port 12865. It can be modified through the -p parameter.
No use UDP port which is estimated to be re-enabled port when tested in accordance with netperf enabled test items.
netperf Parameter Description
netperf parameters following format:
netperf [global options] -- [test options]
Which, global options for the common parameters, all test projects involve public or parameters commonly used are:
-H server's host name or IP designated to run the IP netserver
-l specified test duration test duration, in seconds
-t test items specified content of the test. Test items are as follows:
TCP bulk data transfer test TCP_STREAM
TCP_SENDFILE
TCP_MAERTS
TCP request response (long link) mode test TCP_RR
TCP_CRR
UCP bulk 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
test specific options parameters used to test items, use global parameters between it and "-" to separate similar
netperf -H 127.0.0.1 -l 30 -- -m 2048
Test parameters associated with the test project.
Common test project
Network bandwidth test
-T TCP_STREAM bandwidth test commonly used test item, which is netperf default test project. This test and the ftp bandwidth test system can be similar, but more can be set via parameters. such as:
$ netperf -H 127.0.0.1 -l 60
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 : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 60.00 2760.70
Socket buffer size as a first terminal for receiving the packet service, where did 87380
A second client as the transmission data buffer size Socket, 16384
The third message sent as the size, 16384
The fourth long as the test
The fifth rate as test units of M, where the result is 2.7G. Because using localhost, actually send and receive data in the memory of the machine.
TCP_STREAM common test parameters are:
-s client buffer size specified transmission data buffer size -S buffer size specified service terminal for receiving data buffer size
-m bytes to send a message size unit
-M receiving message size in units of bytes
You can adjust these parameters to understand what factors influence the transmission rate. For example the transmit buffer becomes large, little change in the test results:
1
2
3
4
5
6 7 8 |
|
Receiving buffer is changed and the size of the contract, it is possible to 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 : demo
Recv 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 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 : demo
Recv 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
UDP protocol transmission performance
And network bandwidth testing similar, but replaced the agreement, so this project is UDP_STREAM:
$ netperf -H 127.0.0.1 -l 60 -t UDP_STREAM
MIGRATED 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 : demo
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
212992 65507 60.00 440506 0 3847.46
212992 60.00 433151 3783.22
And TCP_STREAM not the same, the test results have two rows of data. The first line is the client, and the second line is the server.
As a first buffer size, in netperf test, both ends of the buffer size will be set to the same size.
The second message size as
The third time as a test transmission
As a fourth transport packet quantity, UDP protocol does not guarantee the transmission reliability because the number of messaging is not as much, and the actual production yield packet amount may be less further than contracting. From the data, the number should be the number of packets per second (message size and speed of the units are not the same)
Finally, the rate of testing, we can see faster than the TCP protocol. This is a protocol decision.
TCP connection request response pattern test length
In addition to data transmission network, a lot of network traffic is a request / response type, i.e., one sending a message, a reply to the other. And often such requests and reply message sizes as large, or even very different. netperf can simply simulate such scenarios, the network performance testing. Tests using type TCP_RR.
The easiest TCP_RR tests are as follows:
$ netperf -H 127.0.0.1 -l 60 -t TCP_RR
MIGRATED 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 0
Local /Remote
Socket 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 87380
Test results are divided into two rows, the first local row, the second row is the distal end (server)
The first and second columns should still buffer, and just opposite to the order STREAM tests.
Third and fourth as the request and returns the size of the package. The default is 1.
The fifth time as a test
Sixth as a trading rate, this is the amount in / sec, not the bandwidth.
The default packet size can not occur in actual service, the parameters can be adjusted to simulate the real situation. Using the test parameter -r request packet size, the size of the response packet (-r request, response) test. Note that this parameter units BYTES, real business generally in bytes of messages:
$ netperf -H 127.0.0.1 -l 60 -t TCP_RR -- -r 64,2048
MIGRATED 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 0
Local /Remote
Socket 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 87380
This test uses 8 bytes request, returns a response 256 byte packets test results relative to a default value decreased slightly.
Short TCP connection request response pattern test
The other type is similar to the HTTP request TCP service short connection request response message. 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 : demo
Local /Remote
Socket 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 87380
Test parameters and display TCP_RR similar. Due to the influence of the type of service, worse than the drop rate.
UDP connection request response pattern test
Due to the UDP protocol, UDP, regardless of the length of the connection request response. Only UDP_RR a test project, test parameters are also similar test TCP class:
$ 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 0
Local /Remote
Socket 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
In theory, UDP test results better than TCP, but in real networks, may be affected by network equipment configuration, etc., there are some unknowns.
How to simulate tests
We first need to do a good job of test cases. To clear business type, protocol, a good test to determine which project selection, to understand the characteristics of the business, such as general packet size and other information, in order to select the appropriate parameters. These parameters can be determined based on business design, you may also need to get through the traffic monitoring data. For example, by monitoring the data amount of the maximum flow rate and the maximum IO can be roughly assess the size of the data packets, of course, this evaluation is very accurate.
Since the factors that determine network performance and configuration-related part, so you can change the buffer size and other parameters in the test, to see if you need to adjust the network parameters.