Hoe kies je een VPS-locatie voor lage latency

Mensen vergelijken urenlang aantallen vCPU's en zetten de server dan op het verkeerde continent. Voor alles wat interactief is (een shell, een API, een game, een bot die met een beurs praat) telt de locatie vaak meer dan de hardware. Het goede nieuws: latency is vooral natuurkunde, dus je kunt het voorspellen en meten voordat je betaalt.

De natuurkunde in één regel

Licht in glasvezel reist ongeveer 200 km per milliseconde. Kabels lopen niet in rechte lijnen en elke router voegt een beetje toe, dus een solide vuistregel is ongeveer 1 ms round-trip per 100 km werkelijke afstand.

Geen hoeveelheid CPU lost een round-trip van 200 ms op. Zitten je gebruikers in Tokio, dan voelt een server in Duitsland traag, hoe snel hij ook is.

Wat „dichtbij” betekent, hangt af van de taak

Een website of API. Dicht bij de meerderheid van je gebruikers. Een CDN verbergt afstand voor statische bestanden, maar de eerste HTML-respons, logins, API-aanroepen en alles wat dynamisch is reizen nog steeds naar de origin.

Een tradingbot. Dicht bij de API-servers van de beurs, niet bij jou. Waar jij zit is irrelevant; de bot praat honderden keren per dag met de beurs. Bij arbitrage telt elke paar milliseconden; voor een bot die een handvol orders per dag plaatst maakt 30 ms niets uit. Meer in VPS met lage latency voor tradingbots.

Een AI-agent die model-API's aanroept. De locatie maakt nauwelijks uit. Een model doet er seconden over om te antwoorden; 30 ms netwerk is ruis. Kies op prijs en privacy.

Een gameserver. Dicht bij de spelers. Alles onder ~60 ms voelt voor de meeste games prima; competitieve shooters willen veel minder.

Extern bureaublad en SSH. Dicht bij jou. Typen met 150 ms latency is ellende.

Meet het zelf

Controleer vanaf je eigen machine, of vanaf een server bij je gebruikers, het pad naar een kandidaat-locatie:

mtr -rwc 50 example.com

mtr toont elke hop met verlies en latency: veel nuttiger dan één enkele ping, omdat je ziet waar de vertraging ontstaat.

Meet vanaf een VPS de dienst waar je echt van afhankelijk bent, uitgesplitst per fase:

curl -o /dev/null -s -w 'dns %{time_namelookup}s  connect %{time_connect}s  tls %{time_appconnect}s  total %{time_total}s\n' \
  https://api.example.com/health

connect is ruwweg één netwerk-round-trip, tls voegt de handshake toe en total omvat de eigen verwerkingstijd van de server. Is connect 2 ms en total 900 ms, dan is afstand niet je probleem.

Waar EQVPS past

Onze servers staan in Duitsland en Finland, en je kiest de locatie per bestelling. Dat dekt gebruikers in heel Europa goed, het Midden-Oosten redelijk, en Europese beurzen en API-endpoints heel goed. Finland ligt een paar milliseconden verder van West-Europa en iets dichter bij Scandinavië en de Baltische staten; voor de meeste taken werkt allebei.

Eerlijk gezegd: we hebben geen locaties in Azië of Amerika. Zitten je gebruikers daar, dan voegt een server in Europa 80–250 ms toe aan elke round-trip, en kun je beter dichter bij hen hosten.

De korte versie

1. Bepaal waar de server het meest mee praat: gebruikers, een beurs, een API, jou.
2. Zet hem dicht bij dat, met ~1 ms per 100 km als schatting.
3. Meet met mtr en curl -w in plaats van op een kaart te vertrouwen.
4. Betaal niet voor een snellere CPU om een afstandsprobleem op te lossen.

Kies je voor dezelfde machine tussen een NAT-plan en een plan met dedicated IP, dan is dat een andere vraag: hier is de test met één vraag.