Measuring latency and throughput to your server

Which tool answers which question

Run each from where your users or upstream services actually are. A test from the server to itself proves nothing.

ping: round-trip time and jitter

$ ping -c 20 203.0.113.10
...
--- 203.0.113.10 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19027ms
rtt min/avg/max/mdev = 8.112/8.904/11.630/0.701 ms

The example output is illustrative; yours will differ. Read it as:

• min: the floor set by distance and routing. You cannot tune below it.
• avg minus min: queueing somewhere, often your own Wi-Fi or a busy home uplink.
• mdev: jitter. Matters more than average for voice, gaming and interactive SSH.
• loss: anything above zero over a sustained run is worth investigating.

On Windows use ping -n 20. If ping is blocked, the server's firewall may be dropping ICMP; allow echo requests, as the nftables guide does by default.

mtr: the path, hop by hop

mtr combines traceroute and ping and keeps sampling. Use report mode for something you can paste into a support ticket:

sudo apt install mtr-tiny      # or: dnf install mtr
mtr -rwzbc 100 203.0.113.10

Flags: -r report, -w wide, -z show AS numbers, -b names and IPs, -c 100 probes per hop. Reading it:

• Latency should rise in steps where the path covers distance and stay roughly flat after.
• Loss at an intermediate hop that disappears by the next hop is ICMP rate limiting. Ignore it.
• Loss that starts at hop N and continues to the destination is real, and hop N or the link before it is the suspect.
• A jump in latency that persists to the end shows where the delay is added.

Run it in both directions. Routing is often asymmetric, so run mtr from the server back to your public IP too; the return path can be the slow one. If you raise a ticket with support, include both reports and the time of the test.

iperf3: throughput

Start a server on the VPS, allow the port from your IP only, test, then close it again.

# on the VPS
sudo apt install iperf3
iperf3 -s -1            # -1: exit after one test

# from your machine
iperf3 -c 203.0.113.10 -t 15            # upload: you -> server
iperf3 -c 203.0.113.10 -t 15 -R         # download: server -> you
iperf3 -c 203.0.113.10 -t 15 -P 4 -R    # four parallel streams

Each plan has a 1 Gbps port. A test from a home connection will usually show your broadband speed, not ours, which is useful in itself: it tells you the bottleneck is at your end. To test the server's own path, run iperf3 between the VPS and another server you control with a fast connection.

If a single stream is much slower than four parallel streams, the limit is TCP window and latency, not bandwidth. Modern kernels with BBR help long paths:

echo 'net.core.default_qdisc=fq' | sudo tee /etc/sysctl.d/90-bbr.conf
echo 'net.ipv4.tcp_congestion_control=bbr' | sudo tee -a /etc/sysctl.d/90-bbr.conf
sudo sysctl --system

curl: where a real request spends its time

For a website or API, the network is one part of the wait. curl's write-out variables split the request into phases:

curl -so /dev/null https://api.example.co.uk/v1/health -w '
   dns: %{time_namelookup}s
   tcp: %{time_connect}s
   tls: %{time_appconnect}s
  ttfb: %{time_starttransfer}s
 total: %{time_total}s
'

All values are cumulative from the start. Subtract to get each phase:

• tcp minus dns: one round trip. Should match ping.
• tls minus tcp: the handshake, one or two round trips. TLS 1.3 and session resumption shrink it.
• ttfb minus tls: your application thinking. If this is large, the network is not the problem; look at the app, the database or server load.

Run it ten times and look at the spread, not one result. The first request may include DNS cache misses and cold application caches.

Why a London server, and when it matters

Every round trip your users make costs at least the network floor. A page that needs a DNS lookup, TCP, TLS and three dependent API calls pays that floor six times or more. Hosting in London keeps it small for a UK audience, which is the whole case for our single London region. It matters most for chatty APIs, real-time apps and SSH sessions you use all day; it matters least for large file downloads, where throughput dominates.

Recording a baseline

Run the four tests once when the server is new and things feel fine, and save the output with a date. When someone later says "it feels slow", you can compare against a number instead of a memory.