Choisir l'emplacement d'un VPS pour une faible latence

On passe des heures à comparer des nombres de vCPU, puis on place le serveur sur le mauvais continent. Pour tout ce qui est interactif — un shell, une API, un jeu, un bot qui parle à une plateforme d'échange — l'emplacement compte souvent plus que le matériel. La bonne nouvelle : la latence, c'est surtout de la physique, on peut donc la prévoir et la mesurer avant de payer.

La physique en une ligne

Dans la fibre optique, la lumière parcourt environ 200 km par milliseconde. Les câbles ne vont pas en ligne droite et chaque routeur ajoute un peu, d'où une règle solide : environ 1 ms d'aller-retour par 100 km de distance réelle.

Aucun CPU ne corrige un aller-retour de 200 ms. Si vos utilisateurs sont à Tokyo, un serveur en Allemagne paraîtra lent, aussi rapide soit-il.

« Proche » dépend de la tâche

Un site web ou une API. Près de la majorité de vos utilisateurs. Un CDN masque la distance pour les fichiers statiques, mais la première réponse HTML, les connexions, les appels d'API et tout le dynamique voyagent toujours jusqu'au serveur d'origine.

Un bot de trading. Près des serveurs d'API de la plateforme — pas près de vous. Où vous êtes n'a pas d'importance ; le bot parle à la plateforme des centaines de fois par jour. Pour l'arbitrage, chaque milliseconde compte ; pour un bot qui passe quelques ordres par jour, 30 ms ne changent rien. Plus de détails dans VPS à faible latence pour bots de trading.

Un agent IA qui appelle des API de modèles. L'emplacement compte à peine. Un modèle met des secondes à répondre ; 30 ms de réseau, c'est du bruit. Choisissez sur le prix et la confidentialité.

Un serveur de jeu. Près des joueurs. Tout ce qui est sous ~60 ms convient à la plupart des jeux ; les jeux de tir compétitifs veulent bien moins.

Bureau à distance et SSH. Près de vous. Taper avec 150 ms de latence, c'est un supplice.

Mesurez vous-même

Depuis votre machine, ou depuis un serveur proche de vos utilisateurs, vérifiez le chemin vers un emplacement candidat :

mtr -rwc 50 example.com

mtr affiche chaque saut avec les pertes et la latence — bien plus utile qu'un simple ping, car on voit où le délai s'ajoute.

Depuis un VPS, mesurez le service dont vous dépendez vraiment, étape par étape :

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 correspond à peu près à un aller-retour réseau, tls ajoute la négociation, et total inclut le temps de traitement du serveur. Si connect vaut 2 ms et total 900 ms, la distance n'est pas votre problème.

Où se situe EQVPS

Nos serveurs sont en Allemagne et en Finlande, et vous choisissez l'emplacement à chaque commande. Cela couvre bien les utilisateurs de toute l'Europe, correctement le Moyen-Orient, et très bien les plateformes et points d'accès API européens. La Finlande est à quelques millisecondes de plus de l'Europe de l'Ouest et un peu plus proche des pays nordiques et baltes ; pour la plupart des usages, l'un ou l'autre convient.

Honnêtement : nous n'avons pas d'emplacements en Asie ni en Amérique. Si vos utilisateurs sont là-bas, un serveur en Europe ajoute 80 à 250 ms à chaque aller-retour, et mieux vaut héberger plus près d'eux.

En bref

1. Déterminez avec qui le serveur échange le plus — utilisateurs, plateforme d'échange, API, vous.
2. Placez-le près de cela, en comptant ~1 ms par 100 km.
3. Mesurez avec mtr et curl -w au lieu de vous fier à une carte.
4. Ne payez pas un CPU plus rapide pour corriger un problème de distance.

Si vous hésitez entre une offre NAT et une offre avec IP dédiée pour la même machine, c'est une autre question — voici le test en une question.