Network Benchmarking with iperf3 and netperf

How network benchmarking with iperf3 and netperf identifies bottlenecks

Before diving into why PostgreSQL replication between nodes is lagging or why file copying yields 200 MB/s instead of the expected 900, you need numbers. Not gut feelings, not "it feels slow"—but precise throughput, latency, and jitter. Without systematic tools, such measurements become guesswork. Our certified DevOps engineers with seven years of experience have completed over 50 benchmarking projects for clients in FinTech and E-commerce. Implementing regular benchmarking reduces problem search time by 80%.

A recent example: on a client's project, PostgreSQL replication lagged 20 seconds in synchronous mode. iperf3 showed 8.5 Gbps on a 10G link—within normal range. But netperf TCP_RR returned only 5,000 trans/sec instead of the expected 8,000. The cause was suboptimal IRQ distribution on the virtual machine. After binding processes to cores (taskset) and configuring RPS, the issue resolved.

Load test: step-by-step instructions

1. Install iperf3 on both nodes (available in repositories).
2. Server side: iperf3 -s -p 5201.
3. Client: TCP throughput with 4 streams: iperf3 -c <IP> -t 30 -P 4.
4. UDP test with fixed bandwidth: iperf3 -c <IP> -u -b 1G -t 30 --length 1400.
5. Analysis: compare with expected link capacity.

Here is a basic run:

# on the server
iperf3 -s -p 5201
# on the client — TCP throughput
iperf3 -c 10.0.1.10 -p 5201 -t 30 -P 4
# UDP test with fixed bandwidth (for jitter and packet loss)
iperf3 -c 10.0.1.10 -u -b 1G -t 30 --length 1400

The -P 4 flag enables parallel streams. A single TCP stream rarely utilizes a 10G link due to TCP window size limitations. Four parallel streams give a realistic picture.

A common mistake is running the test without considering MTU. If a tunnel (GRE, VXLAN, WireGuard) exists somewhere on the path, the effective MTU drops. Testing with --length 8972 (jumbo frames) on a network without jumbo frame support will show fragmentation or drops instead of real throughput. Another typical error is ignoring CPU bottlenecks: on 10G+ tests, virtual machines often hit vCPU limits or IRQ balancing issues. In such cases, binding processes to cores (taskset) and configuring RPS/XPS helps.

netperf is more convenient for testing latency and RPC patterns:

# TCP_RR — request/response latency (critical for databases)
netperf -H 10.0.1.10 -t TCP_RR -l 30 -- -r 1,1
# TCP_STREAM — throughput
netperf -H 10.0.1.10 -t TCP_STREAM -l 30 -- -m 65536

TCP_RR shows transactions/sec—a metric iperf3 can't provide. For PostgreSQL replication or Redis, it's important to know how many round-trips per second the network can deliver.

What to measure and how to interpret

If throughput between two servers in the same VLAN shows 4-5 Gbps instead of 9+, diagnose sequentially: ethtool eth0 to check negotiated speed, ip -s link show eth0 for error counters, ss -tin on the active connection for TCP retransmits and zero-window events.

Record results in a structured format—iperf3 supports JSON output (-J), convenient for automation and baseline storage:

iperf3 -c 10.0.1.10 -t 60 -P 4 -J > baseline_$(date +%Y%m%d).json 

Running the same command in cron once a day provides a historical performance trend—degradation becomes noticeable before it turns into an incident. Time savings on diagnostics can reach 80% with regular monitoring.

Why standard tools (ping, traceroute) are unsuitable for performance assessment

ping shows the round-trip time of a single ICMP packet but provides no information about throughput or behavior under full link load. traceroute only shows the route. For real performance assessment, load tests that simulate actual traffic—TCP and UDP with various packet sizes and patterns—are needed.

How to interpret results and when to worry

Base your assessment on a baseline taken after network setup. If throughput drops by 20%, check switch configurations, new tunnels, or virtualization settings changes. If jitter exceeds 1 ms, look for buffering issues or CPU overload. For critical applications (databases, VoIP), we use SLOs: latency < 0.5 ms RTT, packet loss = 0%. Implementing regular monitoring with iperf3 and netperf helps detect problems before they manifest—the cost of such a solution is significantly lower than alternatives.

How often to perform benchmarking

Frequency depends on system criticality. For production environments, we recommend running basic tests (throughput + latency) once a day—this catches degradation before incidents. For dev/stage, once a week is sufficient. Automation via cron and iperf3's JSON output makes the process painless.

Tool comparison: iperf3 vs netperf

What's included in the work

Installation and configuration of iperf3/netperf on target nodes. Development of a test suite tailored to specific load patterns (throughput, latency, RPC). Conducting measurements and establishing baselines. Interpreting results and providing recommendations to eliminate bottlenecks. If needed, a script for regular monitoring with history retention.

Timeline: 1-2 business days depending on the number of nodes and topology complexity. The cost is calculated individually.

Contact us to discuss your project and order network benchmarking. Our certified DevOps engineers with seven years of experience guarantee measurement accuracy and practical recommendations. Order network benchmarking today—start with diagnostics to avoid downtime.

According to iperf3, parallel streams increase throughput on multi-processor systems.