लोग घंटों vCPU की संख्या की तुलना करते हैं और फिर सर्वर ग़लत महाद्वीप पर रख देते हैं। हर इंटरैक्टिव चीज़ (शेल, API, गेम, एक्सचेंज से बात करने वाला बॉट) के लिए स्थान अक्सर हार्डवेयर से ज़्यादा मायने रखता है। अच्छी ख़बर: विलंब ज़्यादातर भौतिकी है, इसलिए आप भुगतान से पहले इसका अनुमान लगा सकते हैं और इसे माप सकते हैं।
एक पंक्ति में भौतिकी
ऑप्टिकल फ़ाइबर में प्रकाश प्रति मिलीसेकंड लगभग 200 किमी चलता है। केबल सीधी रेखा में नहीं बिछे होते और हर राउटर थोड़ा जोड़ता है, इसलिए एक भरोसेमंद नियम है: असली दूरी के हर 100 किमी पर लगभग 1 ms राउंड ट्रिप।
| रास्ता | सामान्य राउंड ट्रिप |
|---|---|
| एक ही शहर के भीतर | 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 में।
मॉडल API बुलाने वाला AI एजेंट। स्थान लगभग मायने नहीं रखता। मॉडल को जवाब देने में सेकंड लगते हैं; 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, या आप।
- उसे उसी के पास रखें, हर 100 किमी पर ~1 ms का अनुमान लगाकर।
- नक्शे पर भरोसा करने के बजाय
mtrऔरcurl -wसे मापें। - दूरी की समस्या ठीक करने के लिए तेज़ CPU पर पैसे न लगाएँ।
अगर आप एक ही मशीन के लिए NAT प्लान और डेडिकेटेड IP प्लान के बीच चुन रहे हैं, तो वह अलग सवाल है: यह रहा एक सवाल वाला टेस्ट।
टिप्पणियाँ
अभी तक कोई टिप्पणी नहीं। पहले बनें।