Как да избереш локация на VPS за ниска латентност

Хората прекарват часове в сравняване на броя vCPU и после слагат сървъра на грешния континент. За всичко интерактивно (shell, API, игра, бот, който говори с борса) локацията често има по-голямо значение от хардуера. Добрата новина: латентността е най-вече физика, така че можеш да я предвидиш и измериш, преди да платиш.

Физиката в един ред

Светлината в оптичното влакно пътува около 200 km за милисекунда. Кабелите не вървят по прави линии и всеки рутер добавя по малко, така че солидно правило е около 1 ms двупосочно време на 100 km реално разстояние.

Никакво количество CPU не оправя двупосочно време от 200 ms. Ако потребителите ти са в Токио, сървър в Германия ще изглежда бавен, колкото и бърз да е.

«Близо» зависи от задачата

Уебсайт или API. Близо до мнозинството от потребителите ти. CDN скрива разстоянието за статичните файлове, но първият HTML отговор, входовете, API извикванията и всичко динамично пак пътуват до изходния сървър.

Търговски бот. Близо до API сървърите на борсата, не до теб. Къде седиш ти, е без значение; ботът говори с борсата стотици пъти на ден. При арбитраж всеки няколко милисекунди се броят; за бот, който пуска няколко поръчки на ден, 30 ms не променят нищо. Повече в VPS с ниска латентност за търговски ботове.

AI агент, който вика APIs на модели. Локацията почти няма значение. Моделът отговаря за секунди; 30 ms мрежа са шум. Избирай по цена и поверителност.

Сървър за игри. Близо до играчите. Всичко под ~60 ms се усеща добре за повечето игри; състезателните шутъри искат много по-малко.

Отдалечен работен плот и SSH. Близо до теб. Писането при 150 ms латентност е мъчение.

Измери сам

От собствената си машина или от сървър близо до потребителите си провери пътя до кандидат-локация:

mtr -rwc 50 example.com

mtr показва всеки hop със загуби и латентност, много по-полезно от единичен ping, защото разкрива къде се добавя забавянето.

От VPS измери услугата, от която реално зависиш, разбита по фази:

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 е грубо един мрежов двупосочен цикъл, tls добавя ръкостискането, а total включва и собственото време за обработка на сървъра. Ако connect е 2 ms, а total 900 ms, разстоянието не е твоят проблем.

Къде се вписва EQVPS

Сървърите ни са в Германия и Финландия, а локацията избираш за всяка поръчка. Това покрива добре потребители из цяла Европа, Близкия изток разумно добре и европейските борси и API endpoints много добре. Финландия е с няколко милисекунди по-далеч от Западна Европа и малко по-близо до скандинавските и балтийските страни; за повечето натоварвания и двете работят.

Честно: нямаме локации в Азия или Америка. Ако потребителите ти са там, сървър в Европа добавя 80–250 ms към всеки двупосочен цикъл и трябва да хостваш по-близо до тях.

Накратко

1. Реши с кого говори сървърът най-много: потребители, борса, API, ти.
2. Сложи го близо до това, с оценка ~1 ms на 100 km.
3. Мери с mtr и curl -w, вместо да вярваш на карта.
4. Не плащай за по-бърз CPU, за да оправиш проблем с разстоянието.

Ако избираш между NAT план и план с dedicated IP за същата машина, това е отделен въпрос: ето теста с един въпрос.