ადამიანები საათობით ადარებენ vCPU-ების რაოდენობას და შემდეგ სერვერს არასწორ კონტინენტზე ათავსებენ. ნებისმიერი ინტერაქტიულისთვის (shell, API, თამაში, ბირჟასთან მოსაუბრე ბოტი) მდებარეობა ხშირად აპარატურაზე მნიშვნელოვანია. კარგი ამბავი: დაყოვნება ძირითადად ფიზიკაა, ამიტომ გადახდამდე შეგიძლიათ მისი წინასწარმეტყველება და გაზომვა.
ფიზიკა ერთ სტრიქონში
სინათლე ოპტიკურ ბოჭკოში ერთ მილიწამში დაახლოებით 200 კმ-ს გადის. კაბელები სწორ ხაზებზე არ გადის და ყოველი როუტერი ცოტას ამატებს, ამიტომ საიმედო წესია დაახლოებით 1 ms ორმხრივი დრო რეალური მანძილის ყოველ 100 კმ-ზე.
| მარშრუტი | ტიპიური ორმხრივი დრო |
|---|---|
| ერთი ქალაქის შიგნით | 1–3 ms |
| ფრანკფურტი ↔ ჰელსინკი | 20–25 ms |
| ცენტრალური ევროპა ↔ ლონდონი | 10–20 ms |
| ევროპა ↔ აშშ-ის აღმოსავლეთ სანაპირო | 80–100 ms |
| ევროპა ↔ აშშ-ის დასავლეთ სანაპირო | 140–170 ms |
| ევროპა ↔ სინგაპური / ტოკიო | 160–250 ms |
CPU-ს არანაირი რაოდენობა არ გამოასწორებს 200 ms ორმხრივ დროს. თუ თქვენი მომხმარებლები ტოკიოში არიან, გერმანიის სერვერი ნელი მოეჩვენებათ, რაც არ უნდა სწრაფი იყოს.
«ახლოს» ამოცანაზეა დამოკიდებული
ვებსაიტი ან API. თქვენი მომხმარებლების უმრავლესობასთან ახლოს. CDN სტატიკური ფაილებისთვის მანძილს მალავს, მაგრამ პირველი HTML პასუხი, შესვლები, API გამოძახებები და ყველაფერი დინამიკური მაინც წყარო სერვერამდე მოგზაურობს.
სავაჭრო ბოტი. ბირჟის API სერვერებთან ახლოს და არა თქვენთან. სად ზიხართ, მნიშვნელობა არ აქვს; ბოტი ბირჟას დღეში ასობითჯერ ესაუბრება. არბიტრაჟში ყოველი რამდენიმე მილიწამი ითვლება; ბოტისთვის, რომელიც დღეში რამდენიმე ორდერს დებს, 30 ms არაფერს ცვლის. მეტი დაბალი დაყოვნების VPS სავაჭრო ბოტებისთვის-ში.
AI აგენტი, რომელიც მოდელების API-ებს იძახებს. მდებარეობას თითქმის არ აქვს მნიშვნელობა. მოდელს პასუხისთვის წამები სჭირდება; 30 ms ქსელი ხმაურია. აირჩიეთ ფასითა და კონფიდენციალურობით.
სათამაშო სერვერი. მოთამაშეებთან ახლოს. ~60 ms-ზე ნაკლები თამაშების უმეტესობისთვის კარგად იგრძნობა; კონკურენტულ შუტერებს გაცილებით ნაკლები სჭირდებათ.
დისტანციური სამუშაო მაგიდა და SSH. თქვენთან ახლოს. 150 ms დაყოვნებით ბეჭდვა ტანჯვაა.
გაზომეთ თვითონ
თქვენი მანქანიდან ან მომხმარებლებთან ახლოს მყოფი სერვერიდან შეამოწმეთ გზა კანდიდატ მდებარეობამდე:
mtr -rwc 50 example.com
mtr აჩვენებს ყოველ ჰოპს დანაკარგითა და დაყოვნებით, რაც ერთ 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 წერტილებს ძალიან კარგად. ფინეთი დასავლეთ ევროპიდან რამდენიმე მილიწამით შორსაა და ოდნავ ახლოსაა სკანდინავიურ და ბალტიის ქვეყნებთან; დატვირთვების უმეტესობისთვის ორივე მუშაობს.
გულწრფელად: აზიასა და ამერიკაში მდებარეობები არ გვაქვს. თუ თქვენი მომხმარებლები იქ არიან, ევროპის სერვერი ყოველ ორმხრივ მოგზაურობას 80–250 ms-ს ამატებს და მათთან უფრო ახლოს უნდა დაჰოსტოთ.
მოკლედ
- გადაწყვიტეთ, ვის ესაუბრება სერვერი ყველაზე მეტად: მომხმარებლებს, ბირჟას, API-ს, თქვენ.
- განათავსეთ იგი მასთან ახლოს, ~1 ms ყოველ 100 კმ-ზე შეფასებით.
- გაზომეთ
mtr-ით დაcurl -w-ით რუკის ნდობის ნაცვლად. - ნუ გადაიხდით უფრო სწრაფ CPU-ში მანძილის პრობლემის მოსაგვარებლად.
თუ ერთი და იმავე მანქანისთვის NAT-სა და გამოყოფილი IP-ის ტარიფს შორის ირჩევთ, ეს სხვა კითხვაა: აი ერთი კითხვის ტესტი.
კომენტარები
ჯერ არ არის კომენტარები. იყავით პირველი.