Jinsi ya kuchagua eneo la VPS kwa ucheleweshaji mdogo

Watu wanatumia saa nyingi kulinganisha idadi ya vCPU kisha wanaweka seva kwenye bara lisilo sahihi. Kwa chochote cha maingiliano (shell, API, mchezo, bot inayozungumza na exchange) eneo mara nyingi ni muhimu kuliko vifaa. Habari njema: ucheleweshaji mara nyingi ni fizikia, kwa hivyo unaweza kuutabiri na kuupima kabla ya kulipa.

Fizikia kwa mstari mmoja

Mwanga kwenye fiber ya macho unasafiri takriban km 200 kwa millisekunde. Nyaya hazipiti kwenye mistari iliyonyooka na kila router inaongeza kidogo, kwa hivyo kanuni thabiti ya kukadiria ni takriban 1 ms ya muda wa kwenda na kurudi kwa kila km 100 za umbali halisi.

Hakuna kiasi cha CPU kinachorekebisha muda wa kwenda na kurudi wa 200 ms. Ikiwa watumiaji wako wako Tokyo, seva iliyo Ujerumani itaonekana polepole bila kujali kasi yake.

«Karibu» inategemea kazi

Tovuti au API. Karibu na watumiaji wako wengi. CDN inaficha umbali kwa faili tuli, lakini jibu la kwanza la HTML, kuingia, simu za API na chochote kinachobadilika bado vinasafiri hadi seva ya asili.

Bot ya biashara. Karibu na seva za API za exchange, si kwako. Mahali unapokaa hapana umuhimu; bot inazungumza na exchange mamia ya mara kwa siku. Kwa arbitrage kila millisekunde chache zinahesabika; kwa bot inayoweka oda chache kwa siku, 30 ms hazileti tofauti. Zaidi kwenye VPS yenye ucheleweshaji mdogo kwa bots za biashara.

AI agent anayeita APIs za modeli. Eneo halina umuhimu sana. Modeli inachukua sekunde kujibu; 30 ms za mtandao ni kelele tu. Chagua kwa bei na faragha.

Seva ya michezo. Karibu na wachezaji. Chochote chini ya ~60 ms kinahisi sawa kwa michezo mingi; michezo ya ushindani ya kufyatua risasi inataka kidogo zaidi.

Kompyuta ya mbali na SSH. Karibu nawe. Kuandika kwa ucheleweshaji wa 150 ms ni mateso.

Pima mwenyewe

Kutoka kwenye mashine yako, au kutoka seva iliyo karibu na watumiaji wako, angalia njia hadi eneo linalowezekana:

mtr -rwc 50 example.com

mtr inaonyesha kila hop pamoja na upotevu na ucheleweshaji, yenye manufaa zaidi kuliko ping moja, kwa sababu inaonyesha ucheleweshaji unaongezwa wapi.

Kutoka kwenye VPS, pima huduma unayoitegemea kweli, ikigawanywa kwa awamu:

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 ni takriban safari moja ya kwenda na kurudi ya mtandao, tls inaongeza handshake, na total inajumuisha muda wa usindikaji wa seva yenyewe. Ikiwa connect ni 2 ms na total ni 900 ms, umbali si tatizo lako.

EQVPS inafaa wapi

Seva zetu ziko Ujerumani na Finland, na unachagua eneo kwa kila oda. Hilo linashughulikia vizuri watumiaji kote Ulaya, Mashariki ya Kati kwa kiasi cha kuridhisha, na exchanges na endpoints za API za Ulaya vizuri sana. Finland iko millisekunde chache mbali zaidi na Ulaya Magharibi na karibu kidogo na nchi za Nordic na Baltic; kwa kazi nyingi yoyote inafanya kazi.

Kwa uwazi: hatuna maeneo Asia au Amerika. Ikiwa watumiaji wako wako huko, seva iliyo Ulaya inaongeza 80–250 ms kwa kila safari ya kwenda na kurudi, na unapaswa kupangisha karibu nao.

Kwa ufupi

1. Amua seva inazungumza na nani zaidi: watumiaji, exchange, API, wewe.
2. Iweke karibu na hicho, ukitumia ~1 ms kwa kila km 100 kama makadirio.
3. Pima kwa mtr na curl -w badala ya kuamini ramani.
4. Usilipie CPU yenye kasi zaidi kurekebisha tatizo la umbali.

Ikiwa unachagua kati ya mpango wa NAT na mpango wenye dedicated IP kwa mashine hiyohiyo, hilo ni swali tofauti: hapa kuna jaribio la swali moja.