Cara memilih lokasi VPS untuk latensi rendah

Orang menghabiskan berjam-jam membandingkan jumlah vCPU lalu menaruh server di benua yang salah. Untuk apa pun yang interaktif (shell, API, game, bot yang berbicara dengan bursa), lokasi sering kali lebih penting daripada perangkat keras. Kabar baiknya: latensi sebagian besar soal fisika, jadi Anda bisa memprediksi dan mengukurnya sebelum membayar.

Fisika dalam satu baris

Cahaya di serat optik bergerak sekitar 200 km per milidetik. Kabel tidak membentang lurus dan setiap router menambah sedikit, jadi patokan yang andal adalah sekitar 1 ms pulang-pergi per 100 km jarak nyata.

Tidak ada jumlah CPU yang bisa memperbaiki pulang-pergi 200 ms. Jika pengguna Anda di Tokyo, server di Jerman akan terasa lambat secepat apa pun ia.

Makna “dekat” bergantung pada pekerjaannya

Situs web atau API. Dekat dengan mayoritas pengguna Anda. CDN menyembunyikan jarak untuk file statis, tetapi respons HTML pertama, login, panggilan API, dan semua hal dinamis tetap berjalan ke server asal.

Bot trading. Dekat dengan server API bursa, bukan dengan Anda. Di mana Anda duduk tidak relevan; bot berbicara dengan bursa ratusan kali sehari. Untuk arbitrase, setiap beberapa milidetik berarti; untuk bot yang memasang segelintir order per hari, 30 ms tidak membuat perbedaan. Selengkapnya di VPS latensi rendah untuk bot trading.

Agen AI yang memanggil API model. Lokasi hampir tidak berpengaruh. Model butuh beberapa detik untuk menjawab; 30 ms jaringan hanyalah derau. Pilih berdasarkan harga dan privasi.

Server game. Dekat dengan para pemain. Di bawah ~60 ms terasa baik untuk sebagian besar game; game tembak-menembak kompetitif butuh jauh lebih rendah.

Desktop jarak jauh dan SSH. Dekat dengan Anda. Mengetik dengan latensi 150 ms sangat menyiksa.

Ukur sendiri

Dari mesin Anda sendiri, atau dari server dekat pengguna Anda, periksa jalur ke lokasi kandidat:

mtr -rwc 50 example.com

mtr menampilkan setiap lompatan beserta paket hilang dan latensinya: jauh lebih berguna daripada satu ping, karena menunjukkan di mana penundaan terjadi.

Dari VPS, ukur layanan yang benar-benar Anda andalkan, dipecah per tahap:

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 kira-kira satu kali pulang-pergi jaringan, tls menambahkan handshake, dan total mencakup waktu pemrosesan server itu sendiri. Jika connect 2 ms dan total 900 ms, masalah Anda bukan jarak.

Posisi EQVPS

Server kami ada di Jerman dan Finlandia, dan Anda memilih lokasinya di setiap pesanan. Itu mencakup pengguna di seluruh Eropa dengan baik, Timur Tengah dengan cukup baik, serta bursa dan endpoint API Eropa dengan sangat baik. Finlandia beberapa milidetik lebih jauh dari Eropa Barat dan sedikit lebih dekat ke negara-negara Nordik dan Baltik; untuk sebagian besar beban kerja, keduanya sama-sama cocok.

Jujur saja: kami tidak punya lokasi di Asia atau benua Amerika. Jika pengguna Anda di sana, server di Eropa menambah 80–250 ms pada setiap pulang-pergi, dan sebaiknya Anda meng-hosting lebih dekat dengan mereka.

Versi singkatnya

1. Tentukan dengan apa server paling sering berkomunikasi: pengguna, bursa, API, atau Anda.
2. Letakkan di dekat itu, dengan patokan ~1 ms per 100 km.
3. Ukur dengan mtr dan curl -w, jangan hanya percaya peta.
4. Jangan membayar CPU yang lebih cepat untuk memperbaiki masalah jarak.

Jika Anda memilih antara paket NAT dan paket IP khusus untuk mesin yang sama, itu pertanyaan lain: inilah tes satu pertanyaan.