يقضي الناس ساعات في مقارنة أعداد vCPU ثم يضعون الخادم في القارة الخطأ. لأي شيء تفاعلي (سطر أوامر، واجهة API، لعبة، بوت يتحدث مع منصة تداول) غالبًا ما يكون الموقع أهم من العتاد. الخبر الجيد: التأخير في معظمه فيزياء، لذا يمكنك توقّعه وقياسه قبل أن تدفع.
الفيزياء في سطر واحد
ينتقل الضوء في الألياف البصرية نحو 200 كم في الملّي ثانية. الكابلات لا تمتد في خطوط مستقيمة وكل راوتر يضيف قليلًا، لذا فالقاعدة العملية الموثوقة هي نحو 1 ms من زمن الذهاب والإياب لكل 100 كم من المسافة الواقعية.
| المسار | زمن الذهاب والإياب النموذجي |
|---|---|
| داخل مدينة واحدة | 1–3 ms |
| فرانكفورت ↔ هلسنكي | 20–25 ms |
| وسط أوروبا ↔ لندن | 10–20 ms |
| أوروبا ↔ الساحل الشرقي للولايات المتحدة | 80–100 ms |
| أوروبا ↔ الساحل الغربي للولايات المتحدة | 140–170 ms |
| أوروبا ↔ سنغافورة / طوكيو | 160–250 ms |
لا توجد كمية من قوة المعالج تصلح زمن ذهاب وإياب قدره 200 ms. إن كان مستخدموك في طوكيو، فسيبدو خادم في ألمانيا بطيئًا مهما كانت سرعته.
معنى «قريب» يعتمد على المهمة
موقع ويب أو واجهة API. قريب من غالبية مستخدميك. يُخفي الـ CDN المسافة للملفات الثابتة، لكن أول استجابة HTML وتسجيلات الدخول واستدعاءات API وكل ما هو ديناميكي يظل يسافر إلى الخادم الأصلي.
بوت تداول. قريب من خوادم API الخاصة بالمنصة، لا منك. مكان جلوسك لا يهمّ؛ البوت يتحدث مع المنصة مئات المرات يوميًا. في المراجحة كل بضع ملّي ثوانٍ تُحتسب؛ أما لبوت يضع بضعة أوامر يوميًا، فـ 30 ms لا تُحدث فرقًا. المزيد في VPS منخفض التأخير لبوتات التداول.
وكيل ذكاء اصطناعي يستدعي واجهات 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بدل الوثوق بخريطة. - لا تدفع مقابل معالج أسرع لإصلاح مشكلة مسافة.
إن كنت تختار بين خطة NAT وخطة بعنوان IP مخصّص للجهاز نفسه، فهذا سؤال منفصل: إليك اختبار السؤال الواحد.
التعليقات
لا تعليقات بعد. كن الأول.