Linux performance / Basic: measurement and resource signals / Lesson 6

Measure the network path and application boundary

Separate resolution, connection setup, transport behavior, server work, and payload transfer in a slow network request.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain RTT, bandwidth, loss, retransmission, and goodput.
Inspect local interfaces and socket evidence safely.
Avoid tuning buffers before identifying the limiting path.

A network request includes several clocks

A slow HTTP report can spend time resolving a name, opening TCP, negotiating TLS, waiting for the server, and receiving the body. Connection reuse can remove some setup stages from later requests. State whether the measurement uses a fresh or reused connection and where the client runs. RTT describes a round-trip path measurement, not the application’s compute time or a guaranteed one-way delay. A geographically distant service may have a different feasible latency budget from a local dependency even when both have abundant bandwidth.

Capacity and delivered goodput differ

Link speed is a physical or virtual interface property, while application goodput is useful payload delivered per interval. Protocol headers, retransmissions, encryption, request size, CPU processing, and endpoint flow control affect the difference. A high nominal link rate does not prove that one connection can fill it. Bandwidth-delay product describes data in flight needed to keep a path busy at a stated rate and RTT, but it is a model rather than an instruction to set every socket buffer to that number. Verify units before using the calculation.

bash Calculate a hypothetical bandwidth-delay product

awk 'BEGIN { bytes_per_second=12500000; rtt_seconds=0.04; printf "synthetic_flight=%.0f bytes\n",bytes_per_second*rtt_seconds }'

Expected output

synthetic_flight=500000 bytes

The chosen 12.5 million bytes/s and 40 ms imply 500,000 bytes in flight. This arithmetic does not measure a real link or recommend a kernel setting.

Inspect the local observation boundary

Read interface counters and socket state before assuming a distant bottleneck. Errors, drops, retransmissions, queue sizes, and receiver window information describe different parts of the path and may have tool-specific units. A counter total needs an interval and a reset check. A host may route a container through an extra namespace and virtual interface, so inspect from the application’s context. Interface drops do not automatically identify wire loss, and clean local counters do not prove the remote service is healthy. Preserve the destination and time window with every observation.

bash Inspect local counters and existing TCP sockets

ip -s link
ss -tin

These prepared-lab commands initiate no external connections. ss output can include sensitive endpoint details; collect only the relevant authorized socket and compare matched intervals.

Queues can add latency without link failure

A queue absorbs bursts but also stores waiting time. Increasing a buffer may reduce drops while increasing delay, so evaluate the user objective rather than celebrating one counter. TCP adapts to congestion and receiver limits; a retransmission is evidence to correlate, not proof of one particular faulty cable. Packet size, offload, virtual switching, and host CPU distribution can change observed counts. Avoid packet capture as an automatic first step because payloads may be sensitive and collection has cost. Start with bounded metadata and escalate only when a hypothesis requires deeper authorized evidence.

Correlate network and server evidence

If server work time rises while network setup stays stable, follow application or dependency work. If connection setup grows but reused connections remain healthy, inspect connection rate, listener queues, resolution, and handshake work. If payload transfer slows, compare sender, receiver, and path evidence under the same payload size. A single ping or a test from another machine does not reproduce the full application path. This lesson never generates traffic or changes congestion control, MTU, offloads, or buffers on the host; proposed experiments belong in a controlled, independently recoverable lab.

Common errors and fixes

Treating link speed as application throughput

Why it happens: Payload and protocol costs were omitted.
How to fix it: Measure successful useful bytes over a defined interval.
Prevent it next time: Record payload, connection reuse, and endpoints.

Increasing buffers without a queueing hypothesis

Why it happens: Drops were optimized while latency was ignored.
How to fix it: Compare delay, drops, and goodput in a bounded lab.
Prevent it next time: Use a complete service objective for acceptance.

A remote test is assumed to match the failing client

Why it happens: Network namespace, route, or connection behavior differs.
How to fix it: Observe the authorized failing context.
Prevent it next time: Keep origin and path metadata with timings.

Check your understanding

1. A reused connection is fast but fresh requests are slow. What should be separated?

Show worked solution

Separate resolution, connection establishment, TLS negotiation, and application response. Compare their timing and connection arrival rate. A bulk-transfer bandwidth test alone cannot explain setup-specific delay and may measure an entirely different limiting mechanism.

2. Why can fewer drops and worse p99 both occur after a buffer increase?