How to Find a Network Bottleneck: A Step-by-Step Throughput Test
- Dan LANCaster
- 17 hours ago
- 8 min read
Your network is slow. Okay... but which part? Maybe it's Wi-Fi. Maybe it's the switch. Maybe the router or firewall can't keep up. Maybe a 1 Gbps link is hiding somewhere inside what you thought was a multi-gigabit path. Or maybe one computer has a NIC, driver, or CPU problem and the network itself is perfectly innocent.
Guessing is easy, but finding the actual bottleneck is more useful. The most effective way to troubleshoot network performance is to stop testing the entire path at once. Instead, measure throughput across progressively different sections of the network until you find the point where performance drops. And that's exactly what we're going to do. So...
What Is a Network Bottleneck?
A network bottleneck is the part of a path that limits the performance of everything else.
Imagine this:
PC -> Wi-Fi AP -> switch -> firewall -> server
If every component can handle 2 Gbps except the firewall, which tops out at 700 Mbps, your end-to-end throughput isn't going to exceed roughly 700 Mbps. The limiting component might be:
an Ethernet link
a Wi-Fi connection
a switch
a router or firewall
a VPN gateway
a network adapter
a driver
an overloaded CPU
the server itself
Also, it's useful to remember that bandwidth and actual throughput are not the same thing, and if you want the deeper explanation of this concept, see our article Throughput in Networking: Why Your "Gigabit" Link Doesn't Feel Like Gigabit.
Now, the job is to figure out which component is setting the limit.
The Basic Idea: Move the Test Endpoints
The method is simple: Start with two machines separated by as little network infrastructure as possible. Measure the throughput between them, then move one endpoint farther away, and test again. Keep expanding the path until the numbers change significantly. For example:
Test 1: PC A -> switch -> PC B
Test 2: PC A -> switch -> firewall -> PC C
Test 3: Wi-Fi laptop -> AP -> switch -> PC B
Test 4: Wi-Fi laptop -> AP -> switch -> firewall -> remote server
If Test 1 looks good and Test 2 suddenly doesn't, you have just reduced "the network is slow" to a much smaller problem. That's already progress.
Step 1: Establish a Wired Baseline
Start with the simplest path you can create. Connect two computers by Ethernet through the same switch. Run a throughput test between them, with one machine acting as the test server and the other as the client. In these examples, we'll use Tessabyte, our network performance testing tool, because it lets us control both endpoints and continuously measure the network itself, rather than the path to somebody else's Internet server.
On a healthy 1 GbE LAN, you won't see exactly 1,000 Mbps of application throughput because there is protocol overhead, but a good TCP result should normally be well into the 900 Mbps range:
But suppose you get this instead: 94 Mbps. Before opening Wireshark, redesigning your VLANs, or developing strong opinions about your firewall vendor, check the obvious things:
negotiated Ethernet speed
cables
switch ports
NIC settings
USB Ethernet adapters (by the way, take a look at this post about modern 10 Gigabit USB adapters if you want to know how they behave in real life)
drivers
A link unexpectedly negotiating at 100 Mbps is a textbook example of a physical-layer problem masquerading as a "slow network." And this is a good point to remember that not every problem should be diagnosed from a dashboard. Tony Fortunato makes exactly that case in Why "It's Probably the Cable" Should Send You to the Field: sometimes the fastest troubleshooting method is to go to the jack, patch panel, or connector and inspect the physical path.
So, if your simplest wired test is already slow, fix it before adding more network components to the experiment!
Step 2: Add the Next Network Device
Once the simple LAN test looks healthy, let's extend the path. Move the server or the client to the other side of the next device you want to test. That could be a router, firewall, distribution switch, VPN gateway, or some other part of the infrastructure. Then repeat the same test. Now, suppose you get this:
Test path | TCP throughput |
Same switch | 944 Mbps |
Across firewall | 612 Mbps |
Now we have something useful to work with! We haven't proven that the firewall itself is the cause, but we know that something introduced between those two test paths is costing us roughly 330 Mbps, which is a lot. Possible causes might include:
firewall processing limits
IDS/IPS inspection
QoS rules
NAT processing
CPU saturation
a slower intermediate link
configuration on one of the interfaces
You've probably figured out the important rule by now: Change one meaningful part of the path at a time. If you change the client, server, cable, protocol, switch, and firewall between two measurements, a different result tells you almost nothing.
Step 3: Isolate Wi-Fi
Wi-Fi always deserves its own test because it adds an impressive number of ways for perfectly good-looking specifications to disappoint you. Once you've verified the wired path, keep the server wired and move only the client onto Wi-Fi. Suppose you now get this:
Test path | TCP throughput |
Wired client -> server | 941 Mbps |
Wi-Fi client -> same server | 618 Mbps |
Most of the network path is identical. The meaningful difference is now the wireless segment, so that's where the investigation should move next. Repeat the test:
close to the access point
farther away
through walls
on different bands
on different channels
at different times of day
while other clients are active
This is exactly why a local throughput test is more useful than an Internet speed test when diagnosing Wi-Fi. The ISP and Internet path are no longer contaminating the measurement. And if you really want to dig deeper into Wi-Fi, read The Wi-Fi Test That Passes in the Lab and Fails in the Real World.
Step 4: Compare TCP and UDP
TCP and UDP tests answer different questions. A TCP test tells you how much useful throughput the path can sustain while TCP handles congestion control, retransmission, and flow control. A good UDP test tool lets you send traffic at a user-defined rate and see what happens. Suppose a UDP test produces:
Rate limit (set by you in the test app) | Packet loss |
500 Mbps | 1% |
700 Mbps | 1% |
800 Mbps | 7.4% |
900 Mbps | 11.2% |
That tells a much richer story than one big speed number. Somewhere between 700 and 800 Mbps, this path stops carrying the offered load comfortably. Tessabyte measures UDP throughput, packet loss, and jitter, so you can see not only how much traffic arrives, but also what happens to traffic quality as the link approaches saturation.
Whether you can tolerate, say, 10% UDP loss is a genuinely difficult question. A lot depends on what kind of traffic the LAN in question normally sends or receives and what quality requirements your organization might have. In brief, on a healthy LAN operating comfortably below capacity, you may see virtually no loss at all. As the UDP rate approaches or exceeds the path's capacity, however, packet loss is expected to rise. For a deeper look at interpreting those numbers, see Understanding UDP Metrics in Network Speed Tests, especially the Is UDP Loss Bad section.
Step 5: Don't Watch Throughput Alone
The largest Mbps number isn't always the most important result. Watch the other metrics too.
Packet Loss
A path can behave perfectly under moderate load and begin dropping UDP packets as it approaches saturation.
Jitter
Jitter matters particularly for real-time applications such as voice and video. A network can have adequate average throughput and still deliver poor application performance because packet timing has become unstable.
RTT
Watch what happens to round-trip time while the network is busy. Let me illustrate this. Imagine two networks that both deliver 900 Mbps.
On Network A:
RTT: 2 ms -> 4 ms under load
On Network B:
RTT: 2 ms -> 150 ms under load
The throughput number is similar, but the user experience probably won't be. A sharp rise in latency under load can point to queueing, congestion, or bufferbloat. If you specifically want to see how a network behaves when you push it hard, our network load and stress testing guide covers that scenario in detail.
Step 6: Test Both Directions
Don't assume that uplink and downlink performance will be identical. Suppose you measure:
Downlink: 938 Mbps Uplink: 327 Mbps
That asymmetry is a clue here. Possible causes include:
Wi-Fi behavior
NIC or driver problems
traffic shaping
router configuration
CPU limitations
different processing paths in a network appliance
Run the same topology in both directions before declaring a link healthy. A bottleneck that appears only in one direction is often easier to diagnose than a vague "it's slow sometimes" complaint.
Step 7: Keep Moving Until the Number Breaks
Eventually, you want to build a sequence like this:
Test path | TCP throughput |
PC -> local switch -> server | 942 Mbps |
PC -> distribution switch -> server | 939 Mbps |
PC -> firewall -> server | 931 Mbps |
PC -> VPN -> remote server | 417 Mbps |
Now compare that with the original complaint:
"The network is slow."
The local switching infrastructure looks fine and the path through the firewall looks fine; performance collapses when the VPN segment is introduced. So, without wasting effort elsewhere, you now have a much smaller problem to investigate. That's the entire point of endpoint-based bottleneck testing.
Three Easy Ways to Fool Yourself
Having given you the "the dos", it would be wrong not to give you "don'ts", right? There we go.
Test the Internet First
An Internet speed test combines:
client + Wi-Fi + LAN + router + firewall + ISP + Internet + remote server
If the result is poor, any of those components could be responsible. Internet tests have their place, but they're a poor first tool for isolating a problem inside your own network. We've written about that distinction before in Speedtest Is for Civilians. You're Not a Civilian. So again: Start locally and work outward.
Change Five Things at Once
Good troubleshooting is a controlled experiment, so please, keep everything you can constant. Change one variable and measure again. Otherwise, even a dramatic improvement may not tell you what fixed the problem.
Trust the Link Speed
A NIC reporting "1 Gbps" doesn't mean you're transferring application data at 1 Gbps. Similarly, a Wi-Fi client displaying a 2.4 Gbps PHY rate certainly doesn't mean your applications are receiving 2.4 Gbps (not even close, in the case of Wi-Fi). Those numbers simply describe the connection at a particular layer. What you actually care about is how fast useful traffic travels between your endpoints. Measure it.
The Short Version
If you want to find a network bottleneck:
Start with two nearby wired endpoints.
Measure your baseline throughput.
Move one endpoint across the next network component.
Run exactly the same test again.
Compare TCP and UDP behavior when useful.
Watch packet loss, jitter, and RTT, not just Mbps.
Test both directions.
Repeat until performance deteriorates.
The first part of the path where the numbers go bad is where your investigation should begin. You don't need to guess whether Wi-Fi, the switch, firewall, VPN, or some other link is responsible; just make each part of the network prove itself.
Find the Bottleneck on Your Own Network
Tessabyte lets you run controlled TCP and UDP tests between endpoints you choose, measuring throughput, packet loss, jitter, and RTT.
Comments