Network PerformanceIntermediate
Fast from Frankfurt, 2.4 seconds from Sydney — and the server is idle
Symptoms
- Users in Australia report the dashboard takes 2–3 s to load; European users see ~300 ms.
- Server-side timing shows every request handled in 20–30 ms, from either region.
- CPU on the API servers is under 10%.
- The dashboard makes 8 sequential API calls, each opening a new HTTPS connection.
# from a Frankfurt probe
$ curl -sw 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
-o /dev/null https://api.example.com/v1/me
dns=0.004 tcp=0.012 tls=0.031 ttfb=0.058 total=0.059
# from a Sydney probe
$ curl -sw 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
-o /dev/null https://api.example.com/v1/me
dns=0.041 tcp=0.298 tls=0.590 ttfb=0.884 total=0.886
$ ping -c 5 api.example.com # from Sydney
rtt min/avg/max/mdev = 283.9/286.1/289.4/1.9 ms
$ traceroute api.example.com # from Sydney, abbreviated
3 syd-core 2 ms
9 sin-transit 97 ms
14 fra-edge 281 ms
15 api (Frankfurt) 284 ms
# browser waterfall (Sydney): 8 requests, each: connect → TLS → request, serialised
# 8 × ~0.9 s ≈ 7 s worst case; observed 2.4 s with some parallelismInvestigate
Inspect areas in any order (0/6 inspected). When you think you know the root cause, commit to it.
Server-side processing time
The `curl` timing breakdown from Sydney
The RTT itself
How the dashboard uses connections
Packet loss
DNS