Where Network Throughput Actually Disappears
Applications get blamed for latency that belongs to the network. Here is the order in which to look, and what each layer typically costs you.
When a business application feels slow, the network is usually the second thing blamed and the first thing at fault. Not because network hardware is unreliable — modern switching silicon is extraordinarily good — but because the losses are distributed across half a dozen layers, each individually small enough to look innocent. Diagnosing them in the wrong order costs weeks.
Here is a workable order, roughly from most to least commonly responsible.
Oversubscription at the aggregation layer
Access switches are almost always oversubscribed toward the core, and reasonably so — no design assumes every port transmits at line rate simultaneously. The problem is that the assumed ratio was set when the traffic pattern was north-south, and modern workloads are heavily east-west. Virtualisation, replication and backup traffic all move between hosts rather than out to users.
A 24-port gigabit access switch with a single gigabit uplink was defensible when those ports served desktops. Serving hypervisor hosts, it is a bottleneck with a twenty-four-to-one ratio. Check uplink utilisation over a full week before touching anything else; if the uplink saturates during backup windows, everything downstream of it is a symptom.
Duplex and speed mismatches on the edge
Auto-negotiation has been reliable for a long time, but hard-coded settings survive in configurations for decades, usually applied to work around a fault on hardware that was retired two refreshes ago. A hard-coded full-duplex port facing an auto-negotiating peer will negotiate half duplex, and the resulting collision and late-collision counters are frequently the only visible symptom.
The performance signature is distinctive: throughput that collapses under load rather than degrading smoothly, and error counters that climb in proportion to traffic. It takes five minutes to check the interface counters on both ends and is worth doing early precisely because it is so cheap to rule out.
Buffer exhaustion during microbursts
Average utilisation of 30% tells you very little. Traffic arrives in bursts measured in microseconds, and a switch buffer that cannot absorb a burst will drop frames whatever the five-minute average says. TCP recovers, but recovery means retransmission and a collapsed congestion window, which the application experiences as latency rather than loss.
This is the failure mode that most often produces the complaint "the network graphs look fine but the application is slow", and it is a genuine hardware characteristic: buffer depth per port varies widely between platforms at similar price points. Where a workload is bursty by nature — distributed storage, map-reduce style analytics, backup fan-in — buffer capacity deserves the same scrutiny as port count.
MTU inconsistency across a path
Jumbo frames are enabled for storage and replication traffic and then applied inconsistently, so one hop in the path silently fragments or, worse, drops with the don't-fragment bit set. Path MTU discovery is supposed to handle this and frequently cannot, because the ICMP messages it depends on are filtered somewhere along the way.
Test the actual path with a fixed-size, do-not-fragment probe rather than trusting the interface configuration. Configuration says what was intended; the probe says what happens.
Fibre transition points
Where copper meets fibre — media converters, transceiver-based uplinks, mode conversion between multimode and single-mode — there is a transition that is easy to specify incorrectly and hard to observe afterwards. Wavelength and mode mismatches produce links that come up, pass small frames, and degrade badly under sustained load or across the upper end of the supported distance.
Optical budget is the thing to check: transmit power, receive sensitivity, and the loss introduced by distance, connectors and splices. A link operating within a decibel of its receive threshold works in the lab and fails in August when the building warms up.
The host itself
Finally, the endpoint. A network adapter with interrupt coalescing tuned for throughput will add latency to small transactional traffic. Offload features interact badly with some virtual switch implementations. Driver versions on a hypervisor host drift out of step with firmware in a way that produces intermittent, load-dependent packet loss that looks exactly like a cabling fault.
Because host-side problems mimic every other category on this list, they are worth checking after the path has been cleared rather than before — but they are worth checking, and a surprising proportion of "unexplained" network faults end here.
The economic argument
None of this is exotic, and most of it is fixed with hardware that costs a fraction of the compute it serves. That asymmetry is the practical point. A rack of well-specified servers throttled by a decade-old aggregation switch is an expensive way to run a slow network, and the remedy — an uplink upgrade, a better-buffered aggregation switch, correctly specified optics — is usually the cheapest performance improvement available in the entire estate.