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 parallelism

Investigate

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