Come scegliere la posizione di un VPS per bassa latenza

Si passano ore a confrontare il numero di vCPU e poi si mette il server nel continente sbagliato. Per tutto ciò che è interattivo (una shell, un'API, un gioco, un bot che parla con un exchange) la posizione conta spesso più dell'hardware. La buona notizia: la latenza è soprattutto fisica, quindi puoi prevederla e misurarla prima di pagare.

La fisica in una riga

La luce nella fibra ottica viaggia a circa 200 km per millisecondo. I cavi non corrono in linea retta e ogni router aggiunge un po', quindi una regola pratica solida è circa 1 ms di andata e ritorno ogni 100 km di distanza reale.

Nessuna quantità di CPU sistema un'andata e ritorno di 200 ms. Se i tuoi utenti sono a Tokyo, un server in Germania sembrerà lento per quanto veloce sia.

Cosa significa «vicino» dipende dal lavoro

Un sito web o un'API. Vicino alla maggior parte dei tuoi utenti. Una CDN nasconde la distanza per i file statici, ma la prima risposta HTML, i login, le chiamate API e tutto ciò che è dinamico viaggiano comunque fino all'origine.

Un bot di trading. Vicino ai server API dell'exchange, non a te. Dove ti trovi tu è irrilevante; il bot parla con l'exchange centinaia di volte al giorno. Per l'arbitraggio contano pochi millisecondi; per un bot che piazza una manciata di ordini al giorno, 30 ms non cambiano nulla. Di più in VPS a bassa latenza per bot di trading.

Un agente AI che chiama API di modelli. La posizione conta poco. Un modello impiega secondi a rispondere; 30 ms di rete sono rumore. Scegli in base a prezzo e privacy.

Un server di gioco. Vicino ai giocatori. Sotto i ~60 ms la maggior parte dei giochi va bene; gli sparatutto competitivi vogliono molto meno.

Desktop remoto e SSH. Vicino a te. Scrivere con 150 ms di latenza è un tormento.

Misurala da solo

Dalla tua macchina, o da un server vicino ai tuoi utenti, controlla il percorso verso una posizione candidata:

mtr -rwc 50 example.com

mtr mostra ogni salto con perdite e latenza: molto più utile di un singolo ping, perché rivela dove si aggiunge il ritardo.

Da un VPS, misura il servizio da cui dipendi davvero, suddiviso per fasi:

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 è più o meno un'andata e ritorno di rete, tls aggiunge l'handshake e total include il tempo di elaborazione del server. Se connect è 2 ms e total 900 ms, il problema non è la distanza.

Dove si colloca EQVPS

I nostri server sono in Germania e Finlandia, e scegli la posizione a ogni ordine. Questo copre bene gli utenti in tutta Europa, discretamente il Medio Oriente, e molto bene gli exchange e gli endpoint API europei. La Finlandia è qualche millisecondo più lontana dall'Europa occidentale e un po' più vicina ai Paesi nordici e baltici; per la maggior parte dei carichi va bene l'una o l'altra.

Onestamente: non abbiamo posizioni in Asia o nelle Americhe. Se i tuoi utenti sono lì, un server in Europa aggiunge 80–250 ms a ogni andata e ritorno, e dovresti ospitare più vicino a loro.

In breve

1. Decidi con cosa parla di più il server: utenti, un exchange, un'API, te.
2. Mettilo vicino a quello, usando ~1 ms ogni 100 km come stima.
3. Misura con mtr e curl -w invece di fidarti di una mappa.
4. Non pagare una CPU più veloce per risolvere un problema di distanza.

Se per la stessa macchina stai scegliendo tra un piano NAT e uno con IP dedicato, è un'altra domanda: ecco il test con una sola domanda.