Network as a Performance Symptom

System Monitoring & Performance Diagnosis

Chapter 6 · Network as a Performance Symptom

Chapters 2 through 5 covered CPU, memory, and disk — all local to the machine you're standing on. This chapter is deliberately short, and deliberately doesn't try to re-teach a topic this site already covers in full: it's about recognizing when "slow" isn't a local resource problem at all, running one quick local-side check before committing to that conclusion, and handing off cleanly to this site's own Network Troubleshooting (netdiag1) course once that's confirmed.

The Tell: Everything Local Looks Healthy

The single clearest signal that a symptom is network-related rather than a local resource problem: CPU, memory, and disk all check out clean using Chapters 2 through 5's own tools, and the complaint persists anyway. A machine with plenty of spare CPU, healthy memory, and fast disk I/O that's still "slow" from a user's point of view is very likely waiting on something outside itself — the network path to it, or the network path from it to something it depends on.

Two Genuinely Different Network Symptoms

Direction	What it looks like
Slow to receive requests	Something upstream of this machine — a user's own connection, a CDN, a load balancer — is the bottleneck, not this server
Slow to call something else	This machine is healthy, but it's waiting on a downstream dependency — a database on another host, a third-party API — over a slow or lossy network path

A process waiting on the network can look deceptively idle

A process stuck waiting on a slow remote call — a database query over the network, an outbound API request — often shows up as low CPU usage, since it genuinely isn't doing any computation while it waits. That can look like "the app isn't under any resource pressure" when what's actually happening is the app is stuck, doing nothing, purely because something it depends on hasn't answered yet. Low CPU alongside a slow response is itself a real clue pointing toward network or dependency latency, not away from it.

A Quick Local Check Before Handing Off

Before fully escalating, one more local-machine check is worth running: TCP retransmissions, a rough but genuinely useful local-side signal that packets are actually being lost somewhere on the network.

# First check
$ netstat -s | grep -i retrans
    2841 segments retransmitted

# Same check, 60 seconds later
$ netstat -s | grep -i retrans
    3960 segments retransmitted

The absolute number matters less than the trend — over 1,100 additional retransmitted segments in one minute, on a machine that isn't under heavy load per Chapters 2–5, is a real, active signal that packets are being lost somewhere on the path, not just background noise.

When to Hand Off to Network Troubleshooting

Once local resources are confirmed clean and retransmissions confirm real packet loss is actually occurring, the right next step is this site's own netdiag1 course, not a deeper local investigation — its own ladder (from that course's Chapter 2 onward) is built exactly for this:

Confirming DNS resolution and basic reachability — netdiag1 Chapters 4–5
Checking whether the specific port/service is actually reachable — netdiag1 Chapter 6
Firewalls, proxies, VPNs, and NAT possibly altering the path — netdiag1 Chapters 7–8
Reading the actual HTTP/TLS-level result once a connection is made — netdiag1 Chapter 9

Repeating any of that material here would just be a shallower copy of a course this site already has — this chapter's own job is recognizing the handoff point, not replacing the course on the other side of it.

Working Example: The Slow Checkout Page

A ticket: the checkout page is slow, intermittently, for some users. CPU (Chapter 2) sits comfortably under load; memory (Chapter 3) shows healthy "available" figures with no active swapping; disk I/O (Chapter 4) is unremarkable. Everything local genuinely looks fine. A quick netstat -s check, repeated a minute apart, shows retransmissions climbing steadily — real, active packet loss. Handing off to netdiag1's own techniques (a traceroute to the specific dependency the checkout flow calls) finds the actual cause: intermittent loss on the path to a third-party payment provider's own API, not anything on this application server at all. The checkout page isn't slow because of anything this machine is doing — it's slow because it's waiting on a lossy network path to someone else's service.

Hands-On Exercises

Exercise 1

Explain what this chapter says is the clearest signal that a "slow" complaint is network-related rather than a local resource problem.

📄 View solution

Exercise 2

A colleague sees low CPU usage on a slow server and concludes there's no resource problem at all, so the app itself must be broken. Explain why this chapter says that conclusion can be wrong.

📄 View solution

Exercise 3

Explain why this chapter checks TCP retransmissions twice, a minute apart, rather than just once, and what the difference between the two readings tells you that a single reading wouldn't.

📄 View solution

Chapter 6 Quick Reference

The clearest network tell: CPU/memory/disk all check out clean, but the complaint persists anyway
Two directions: slow to receive requests (something upstream) vs. slow to call something else (a downstream dependency)
A process waiting on a slow network call can show deceptively low CPU — that's a clue toward network latency, not away from it
netstat -s's retransmission count, checked twice and compared, is a quick local-side signal of real packet loss
Once local resources are clean and retransmits confirm loss, hand off to Network Troubleshooting (netdiag1) rather than re-diagnosing locally
Next chapter: Reading Monitoring Dashboards: Grafana & Cloud Console Metrics at a Glance