netperf Network Benchmark
netperf measures both bulk throughput and request/response transaction rates, plus CPU efficiency, between two hosts. Its RR tests make it ideal for latency-sensitive, chatty workloads, though it is still synthetic.
netperf, originally from Hewlett-Packard, is a long-standing network benchmarking tool. It is distinguished from pure throughput tools by its request/response (RR) tests, which measure transaction rate and latency rather than just bulk bandwidth. This makes netperf especially useful for evaluating networks carrying many small, latency-sensitive exchanges, such as RPC, database queries, and microservice calls, where round-trip time matters far more than streaming bandwidth.
What It Measures
netperf offers two main test families. Stream tests (TCP_STREAM, UDP_STREAM) measure bulk one-way throughput, the classic bandwidth figure. Request/response tests (TCP_RR, UDP_RR) measure how many small request-and-reply transactions complete per second, which inversely reflects round-trip latency: more transactions per second means lower latency. netperf can also report CPU utilization on both ends and derive efficiency as throughput or transactions per unit of CPU, a metric that is invaluable for comparing network-stack overhead, NIC offloads, and virtualization cost.
Methodology
netperf runs against a netserver process on the remote host. A stream test pushes data for a fixed duration and reports throughput. An RR test sends a small request, waits for the reply, and repeats as fast as possible, reporting transactions per second; the inverse gives average round-trip latency. Test parameters include message size, socket buffer sizes, and test duration. Burst-mode RR tests keep multiple transactions in flight simultaneously to measure latency under concurrency rather than strictly serial round trips. CPU measurement requires the tool to calibrate the host's processing capacity beforehand so utilization figures are meaningful.
How to Interpret Results
Use stream throughput to size bulk-transfer links and RR transaction rate to assess latency-bound workloads. A high TCP_RR transactions-per-second value means low round-trip latency, which matters for chatty protocols that make many sequential calls. Read the CPU-efficiency metrics to compare network stacks, NIC offloads, or virtualization overhead: two systems with equal throughput can differ greatly in CPU cost, and the cheaper one frees cycles for the application. Lower latency and higher per-CPU efficiency are better.
Limitations
netperf measures the network and stack between two cooperating hosts, not real application behavior, and requires running netserver on the target, which is not always permitted. Like other synthetic tools, endpoint CPU can cap results and mislead. Its RR tests use trivial payloads, so they isolate network latency rather than application processing time. Configuration of socket-buffer sizes strongly affects outcomes and must be disclosed for fair comparison. Use netperf to characterize throughput, transaction latency, and stack efficiency, then validate with end-to-end application tests.