Oamenii petrec ore comparând numărul de vCPU și apoi pun serverul pe continentul greșit. Pentru orice e interactiv — un shell, un API, un joc, un bot care vorbește cu o bursă —, locația contează adesea mai mult decât hardware-ul. Vestea bună: latența e mai ales fizică, deci o poți prevedea și măsura înainte să plătești.
Fizica într-un rând
Lumina în fibra optică parcurge aproximativ 200 km pe milisecundă. Cablurile nu merg în linie dreaptă și fiecare router adaugă puțin, așa că o regulă practică solidă e aproximativ 1 ms de drum dus-întors la 100 km de distanță reală.
| Rută | Drum dus-întors obișnuit |
|---|---|
| În același oraș | 1–3 ms |
| Europa Centrală ↔ țările nordice | 20–25 ms |
| Europa Centrală ↔ Londra | 10–20 ms |
| Europa ↔ coasta de est a SUA | 80–100 ms |
| Europa ↔ coasta de vest a SUA | 140–170 ms |
| Europa ↔ Singapore / Tokyo | 160–250 ms |
Niciun CPU nu repară un drum dus-întors de 200 ms. Dacă utilizatorii tăi sunt în Tokyo, un server în Europa va părea lent, oricât de rapid ar fi.
Ce înseamnă „aproape” depinde de treabă
Un site sau un API. Aproape de majoritatea utilizatorilor. Un CDN ascunde distanța pentru fișierele statice, dar primul răspuns HTML, autentificările, apelurile API și tot ce e dinamic tot călătoresc până la origine.
Un bot de trading. Aproape de serverele API ale bursei — nu de tine. Unde stai tu e irelevant; botul vorbește cu bursa de sute de ori pe zi. Pentru arbitraj contează fiecare câteva milisecunde; pentru un bot care plasează câteva ordine pe zi, 30 ms nu fac nicio diferență. Mai multe în VPS cu latență mică pentru boți de trading.
Un agent AI care apelează API-uri de modele. Locația abia contează. Un model are nevoie de secunde ca să răspundă; 30 ms de rețea sunt zgomot. Alege după preț și intimitate.
Un server de jocuri. Aproape de jucători. Orice e sub ~60 ms se simte bine pentru majoritatea jocurilor; shooterele competitive vor mult mai puțin.
Desktop la distanță și SSH. Aproape de tine. Să tastezi peste 150 ms de latență e un chin.
Măsoar-o singur
De pe propria mașină sau de pe un server de lângă utilizatorii tăi, verifică drumul până la o locație candidată:
mtr -rwc 50 example.com
mtr arată fiecare hop, cu pierderi și latență — mult mai util decât un singur ping, pentru că arată unde se adaugă întârzierea.
De pe un VPS, măsoară serviciul de care chiar depinzi, defalcat pe etape:
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 e aproximativ un drum dus-întors prin rețea, tls adaugă handshake-ul, iar total include timpul de procesare al serverului însuși. Dacă connect e 2 ms și total e 900 ms, distanța nu e problema ta.
Unde se potrivește EQVPS
Serverele noastre sunt în UE, iar locația o alegi la fiecare comandă. Asta acoperă bine utilizatorii din toată Europa, rezonabil Orientul Mijlociu și foarte bine bursele și endpointurile API europene. În interiorul UE, locațiile diferă doar cu câteva milisecunde; pentru majoritatea sarcinilor, oricare merge.
Sincer: n-avem locații în Asia sau în cele două Americi. Dacă acolo îți sunt utilizatorii, un server în Europa adaugă 80–250 ms la fiecare drum dus-întors și ar trebui să găzduiești mai aproape de ei.
Pe scurt
- Decide cu ce vorbește serverul cel mai mult — utilizatori, o bursă, un API, tu.
- Pune-l lângă acel lucru, folosind ~1 ms la 100 km ca estimare.
- Măsoară cu
mtrșicurl -w, în loc să ai încredere într-o hartă. - Nu plăti pentru un CPU mai rapid ca să repari o problemă de distanță.
Dacă alegi între un plan NAT și unul cu IP dedicat pentru aceeași mașină, e o întrebare separată — iată testul cu o singură întrebare.
Comentarii
Încă nu există comentarii. Fii primul.