New York VPS hosting के फायदे और सही चुनाव कैसे करें
New York VPS hosting का चयन करते समय नेटवर्क क्षमता और लोकेशन का महत्व समझें। जानें कि East Coast VPS कब Central US सर्वर से बेहतर प्रदर्शन करता है और इसे कैसे मापें।
New York VPS वास्तव में आपको क्या प्रदान करता है
एक New York VPS संयुक्त राज्य अमेरिका के पूर्वी तट पर स्थित दो बड़े इंटरकनेक्शन बाजारों में से एक में स्थित होता है। दूसरा बाजार Ashburn, Virginia है। आप जो खरीदते हैं, वह Boston और Washington के बीच के उपयोगकर्ताओं के लिए एक छोटा राउंड ट्रिप है, साथ ही उत्तरी अमेरिका से यूरोप तक का सबसे छोटा फाइबर पाथ है। यदि आपके उपयोगकर्ता पूरे महाद्वीप में समान रूप से फैले हुए हैं, तो एक केंद्रीय स्थान आमतौर पर उन्हें बेहतर सेवा देता है। इन दोनों स्थितियों में अंतर करना अनुमान लगाने के बजाय मापन (measurement) का विषय है।
New York VPS hosting असल में New Jersey hosting क्यों है
Manhattan में carrier hotels स्थित हैं। 60 Hudson Street सबसे प्रसिद्ध है: यह Tribeca में 1930 में बनी एक Art Deco इमारत है, जिसके भीतर 300 से अधिक carriers और cloud providers मौजूद हैं। यहाँ DE-CIX New York और NYIIX जैसे exchanges भी हैं जो इस क्षेत्र को सेवा प्रदान करते हैं। 32 Avenue of the Americas कुछ ही ब्लॉक दूर यही काम करती है, और New Jersey की तरफ 165 Halsey Street (Newark) इसका समकक्ष है।
ये इमारतें वे स्थान हैं जहाँ networks आपस में मिलते हैं। यहाँ compute की भारी मात्रा नहीं रखी जाती, क्योंकि Manhattan में बिजली और जगह बहुत महंगी है और उसे बढ़ाना कठिन है। बड़े सर्वर हॉल Hudson नदी के पार Secaucus, Weehawken, Carteret, Piscataway और Newark में स्थित हैं। जो provider "New York" VPS बेचता है, उसका मतलब लगभग हमेशा उस दायरे में स्थित कोई rack होता है, जो Midtown से लगभग 40 km के भीतर है। अतिरिक्त fiber के कारण latency एक millisecond से काफी कम रहती है, इसलिए web workload को इसका पता नहीं चलेगा। यदि आपको किसी विशिष्ट network से cross-connect की आवश्यकता हो, तभी पूछें कि सर्वर किस इमारत में है।
इस मेट्रो क्षेत्र में क्षमता किन कारणों से आई
चार मुख्य कारण हैं, और प्रत्येक कारण दूसरों को और अधिक मजबूत बनाता है।
- ट्रांसअटलांटिक केबल पास में ही लैंड करती हैं। न्यू जर्सी तट पर स्थित Wall Township और Manasquan देश का सबसे व्यस्त क्लस्टर हैं। Havfrue, जिसे AEC-2 के रूप में बेचा जाता है, Wall से डेनमार्क के Blaabjerg तक जाती है और इसकी शाखाएं आयरलैंड और नॉर्वे तक जाती हैं। Seabras-1 उसी स्टेशन से ब्राजील तक जाती है, और TGN Atlantic यूरोप को जोड़ती है। Apollo केबल Manasquan में इंग्लैंड के Bude और फ्रांस के Lannion से आती है। Google की Grace Hopper केबल Long Island के Bellport पर लैंड करती है और सितंबर 2022 से यूरोप के Bude तक ट्रैफिक ले जा रही है।
- एक्सचेंज Wall Street से बाहर चले गए। NYSE का मैचिंग इंजन Mahwah में चलता है, Nasdaq का Carteret में, और Cboe का Secaucus में। ट्रेडर्स इन साइटों को इक्विटी ट्रायंगल कहते हैं। जिन फर्मों को माइक्रोसेकंड के भीतर मार्केट डेटा चाहिए, उन्हें इनमें से किसी एक के बगल में जगह खरीदनी पड़ती है, और उस मांग ने उस फाइबर का खर्च उठाया जिसे अब हम बाकी लोग साझा करते हैं।
- मीडिया और विज्ञापन यहीं स्थित हैं। एक रीयल-टाइम बिडिंग ऑक्शन को पेज लोड होने से पहले जवाब देना होता है, इसलिए विज्ञापन एक्सचेंजों ने उन एजेंसी नेटवर्कों के बगल में अपना बुनियादी ढांचा बनाया है जिन्हें वे सेवाएं बेचते हैं।
- नेटवर्क वहां जाते हैं जहां नेटवर्क पहले से मौजूद हैं। एक बार जब कई सौ कैरियर एक ही बिल्डिंग साझा करने लगते हैं, तो किसी अन्य स्थान पर निर्माण करने की तुलना में वहां शामिल होकर सस्ता ट्रांजिट और बेहतर पीयरिंग प्राप्त करना आसान हो जाता है।
एक VPS खरीदार के लिए इसमें से कुछ भी प्रतिष्ठा के बारे में नहीं है। इसका मतलब है कि ट्रांजिट प्रतिस्पर्धी है, पीयरिंग सघन है, और यूरोप का रास्ता छोटा है क्योंकि यह वहीं से शुरू होता है जहां केबल शुरू होती हैं।
राउंड ट्रिप की वास्तविक लागत
कांच के भीतर प्रकाश लगभग 200,000 किलोमीटर प्रति सेकंड की गति से चलता है, जो निर्वात (vacuum) में इसकी गति का लगभग दो-तिहाई है। राउटर द्वारा पैकेट को छूने से पहले ही, यह फाइबर के प्रत्येक 100 किलोमीटर के लिए 1 ms का राउंड-ट्रिप समय है। वास्तविक रास्ते मानचित्र की दूरी से अधिक लंबे होते हैं, क्योंकि फाइबर सीधी रेखाओं के बजाय अधिकारों के रास्तों (rights of way) और समुद्री मार्गों का अनुसरण करता है।
बिल केवल एक राउंड ट्रिप का नहीं होता है। यह उन राउंड ट्रिप्स की संख्या है जिनकी आपके प्रोटोकॉल को आवश्यकता होती है। एक नया HTTPS कनेक्शन TCP (transmission control protocol) हैंडशेक पर एक राउंड ट्रिप, TLS (transport layer security) 1.3 हैंडशेक पर एक और, तथा अनुरोध भेजने और पहले बाइट्स वापस प्राप्त करने के लिए एक और राउंड ट्रिप खर्च करता है। ब्राउज़र द्वारा कोई भी HTML देखने से पहले यह तीन राउंड ट्रिप्स हैं। TLS 1.2 इसमें एक चौथा राउंड ट्रिप जोड़ देता है।
The data behind this chart
[
{
"label": "Same metro",
"rtt_ms": 5,
"https_first_byte_ms": 15,
"six_call_chain_ms": 30
},
{
"label": "New York to Dallas",
"rtt_ms": 38,
"https_first_byte_ms": 114,
"six_call_chain_ms": 228
},
{
"label": "New York to London",
"rtt_ms": 78,
"https_first_byte_ms": 234,
"six_call_chain_ms": 468
},
{
"label": "New York to Singapore",
"rtt_ms": 230,
"https_first_byte_ms": 690,
"six_call_chain_ms": 1380
}
]ये कॉलम मापों के बजाय अंकगणितीय हैं: पहला बाइट तीन राउंड ट्रिप्स है, और चेन कॉलम एक ऐसा पेज है जो एक के बाद एक छह आश्रित API कॉल फायर करता है। मेट्रो के भीतर 5 ms पर, कनेक्शन सेटअप अदृश्य होता है। अटलांटिक के पार 78 ms पर, वही पेज HTML के पहले बाइट से पहले 234 ms प्रतीक्षा करता है, और छह-कॉल वाली चेन केवल प्रतीक्षा करने में 468 ms खर्च करती है। न्यूयॉर्क से सिंगापुर तक 230 ms पर, उस चेन की लागत 1380 ms होती है।
सर्वर को स्थानांतरित करने से पहले चेन कॉलम को पढ़ें। कनेक्शन का पुन: उपयोग और TLS सत्र का फिर से शुरू होना उन राउंड ट्रिप्स को हटा देता है जिनके लिए आप बार-बार भुगतान कर रहे थे। छह आश्रित कॉल्स को दो समानांतर कॉल्स में बदलने से महाद्वीप को करीब लाने की तुलना में अधिक समय बचता है। सर्वर को तब स्थानांतरित करें जब राउंड ट्रिप्स को कम करना असंभव हो: जैसे कि लॉगिन, या डेटाबेस राइट जिसे आपका क्लाइंट बैच नहीं कर सकता।
New York metro VPS से सामान्य round trip times
The data behind this chart
[
{
"label": "Within the NY and NJ metro",
"rtt_ms": 2
},
{
"label": "Ashburn, Virginia",
"rtt_ms": 8
},
{
"label": "Toronto",
"rtt_ms": 14
},
{
"label": "Chicago",
"rtt_ms": 22
},
{
"label": "Dallas",
"rtt_ms": 38
},
{
"label": "Miami",
"rtt_ms": 40
},
{
"label": "Los Angeles",
"rtt_ms": 70
},
{
"label": "London",
"rtt_ms": 78
},
{
"label": "Frankfurt",
"rtt_ms": 88
},
{
"label": "Sao Paulo",
"rtt_ms": 120
}
]इन्हें किसी एक मशीन से लिए गए मापन के बजाय सामान्य प्रकाशित आंकड़े मानें। ये आंकड़े अच्छी कनेक्टिविटी वाले hosts के लिए सामान्य transit पर आमतौर पर उद्धृत किए जाते हैं, और आपका अपना path इनसे थोड़ा कम या ज्यादा हो सकता है। Ashburn लगभग 8 ms की दूरी पर है, जो इतना करीब है कि एक New York VPS बिना किसी वास्तविक बाधा के Virginia cluster में मौजूद services को कॉल कर सकता है। Toronto लगभग 14 ms की दूरी पर है। London लगभग 78 ms और Frankfurt लगभग 88 ms के करीब स्थित है, यही कारण है कि एक east coast box यूरोपीय उपयोगकर्ताओं को संतोषजनक ढंग से सेवा दे सकता है, जबकि एक west coast box ऐसा नहीं कर सकता।
जब East Coast पर placement सही निर्णय हो
- आपके अधिकांश users Boston से Washington के corridor में स्थित हैं। यह क्षेत्र United States की internet demand का एक बड़ा हिस्सा संभालता है, और यह पूरा क्षेत्र metro से कुछ milliseconds की दूरी पर है।
- आप एक ही machine से eastern United States और Europe को serve करते हैं। New York सबसे सस्ता समझौता है, क्योंकि transatlantic leg यहीं से शुरू होती है।
- आप metro में पहले से मौजूद किसी चीज़ पर निर्भर हैं: जैसे market data feed, ad exchange, या Secaucus या Ashburn में कोई partner API।
- आप वहां host किए बिना Canada के लिए एक छोटा path चाहते हैं। Toronto लगभग 14 ms की दूरी पर है। यदि Canadian data residency एक अनिवार्य आवश्यकता है, तो यह एक अलग निर्णय है, और Canadian VPS hosting चुनते समय वास्तव में क्या मायने रखता है इस पर विस्तार से चर्चा करता है।
जब central US location, East Coast से बेहतर प्रदर्शन करती है
औसत के बजाय सबसे खराब स्थिति (worst case) के लिए design करें। दूर के coast पर बैठा user lag महसूस करता है। बगल के राज्य का user इसे महसूस नहीं करता।
The data behind this chart
[
{
"label": "New York metro",
"to_new_york_ms": 2,
"to_los_angeles_ms": 70
},
{
"label": "Dallas",
"to_new_york_ms": 38,
"to_los_angeles_ms": 35
},
{
"label": "Chicago",
"to_new_york_ms": 22,
"to_los_angeles_ms": 50
},
{
"label": "Los Angeles",
"to_new_york_ms": 70,
"to_los_angeles_ms": 2
}
]New York का एक server, Los Angeles से 70 ms की दूरी पर है। Dallas का एक server, New York से 38 ms और Los Angeles से 35 ms की दूरी पर है, इसलिए पूरे देश में इसका worst case, New York की तुलना में लगभग आधा है। जब आपका traffic map वास्तव में राष्ट्रीय स्तर का हो, तो यह एक मजबूत स्थिति होती है, और Dallas में VPS रखने का तर्क उस market का विस्तार से विश्लेषण करता है। Chicago दूसरा समझदारी भरा मध्य स्थान है, और यह east की ओर झुका हुआ है।
दो और स्थितियाँ New York से दूर जाने का संकेत देती हैं। यदि आपके users Ontario या Quebec में केंद्रित हैं, तो एक Toronto VPS उन्हें सीधे serve करता है, बजाय इसके कि New York से 14 ms का hop जोड़ा जाए। और यदि आपका लगभग सारा traffic आपके अपने servers के बीच चलता है, तो उन्हें एक ही region में रखें और भूगोल के बारे में सोचना बंद करें, क्योंकि एक cross-region hop, users के करीब रहने से मिलने वाले किसी भी लाभ को खत्म कर देगा।
इसे मापें, मार्केटिंग के दावों पर भरोसा न करें
कवरेज मैप आपको यह बताता है कि बिल्डिंग कहाँ है। यह यह नहीं बताता कि पैकेट उस बिल्डिंग तक कैसे पहुँचते हैं, और वह रास्ता दूरी से नहीं, बल्कि ट्रांजिट कॉन्ट्रैक्ट्स और पीयरिंग एग्रीमेंट्स से तय होता है। इसलिए, जहाँ आपके उपयोगकर्ता हैं, वहाँ से मापें। होम ब्रॉडबैंड पर लगा एक लैपटॉप, स्वयं VPS की तुलना में बेहतर प्रोब है, क्योंकि VPS नेटवर्क के अच्छे हिस्से में स्थित होता है।
sudo apt update
sudo apt install -y mtr-tiny traceroute iperf3एक साधारण राउंड ट्रिप से शुरुआत करें और चार के बजाय बीस प्रोब्स भेजें। होस्टनेम को अपने सर्वर से बदलें।
ping -c 20 your-server.example.comअंतिम पंक्ति rtt min/avg/max/mdev की रिपोर्ट देती है। औसत वहाँ सबसे कम उपयोगी संख्या है। mdev जिटर (jitter) है, और उच्च जिटर औसत के सही दिखने पर भी वॉयस और इंटरैक्टिव सत्रों को खराब कर देता है। वायर्ड पाथ पर, शून्य से अधिक कोई भी पैकेट लॉस शोर नहीं, बल्कि एक फॉल्ट है।
फिर पता लगाएँ कि समय कहाँ खर्च हो रहा है।
mtr -rwzbc 100 your-server.example.commtr हर हॉप पर 100 प्रोब्स भेजता है और प्रति हॉप लॉस और लेटेंसी प्रिंट करता है, और -z इसमें AS (ऑटोनॉमस सिस्टम) नंबर जोड़ता है ताकि आप देख सकें कि कौन सा नेटवर्क किस हॉप का मालिक है। बीच के किसी हॉप पर दिखने वाला लॉस जो बाद के हॉप्स पर गायब हो जाता है, वह वास्तविक नहीं है: वह राउटर उन ICMP रिप्लाई को रेट-लिमिट कर रहा है जिन्हें उसे खुद जनरेट करना पड़ता है, जिससे आपके ट्रैफिक पर कोई असर नहीं पड़ता। जो लॉस एक हॉप से शुरू होकर उसके बाद के हर हॉप में बना रहता है, वही वास्तविक है।
वेब सर्विस को जज करने के लिए ICMP गलत प्रोटोकॉल है, क्योंकि कई नेटवर्क इसे कम प्राथमिकता देते हैं। उस चीज़ का समय मापें जिसे आप वास्तव में सर्व करते हैं।
curl -o /dev/null -s -w 'dns %{time_namelookup}\ntcp %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://example.com/प्रत्येक मान शुरुआत से संचयी सेकंड है, इसलिए पढ़ने के लिए आपको घटाना होगा। time_connect माइनस time_namelookup एक राउंड ट्रिप है। time_appconnect माइनस time_connect TLS हैंडशेक है। time_starttransfer माइनस time_appconnect एक और राउंड ट्रिप है, जिसमें वह समय भी शामिल है जो आपके एप्लिकेशन ने उत्तर देने में लिया। वह अंतिम घटाव ही निदान है। यदि यह एक राउंड ट्रिप के करीब है, तो नेटवर्क सीमा है और एक करीबी सर्वर मदद करेगा। यदि यह राउंड ट्रिप से कई गुना अधिक है, तो आपका एप्लिकेशन धीमा है और उसे कहीं और ले जाने से कुछ नहीं बदलेगा।
एक दोहराने योग्य टाइमिंग रन
एक सैंपल केवल शोर है। बीस रन करें और बीच के मानों को पढ़ें, उस समय जब आपके उपयोगकर्ता वास्तव में जाग रहे हों।
for i in $(seq 1 20); do
curl -o /dev/null -s -w '%{time_starttransfer}\n' https://example.com/
done | sort -n | awk 'NR==10 || NR==11'यह बीस में से बीच के दो सैंपल प्रिंट करता है। यदि उनमें कुछ मिलीसेकंड से अधिक का अंतर है, तो पाथ अस्थिर है, और कोई भी एक संख्या आपको गुमराह कर देगी। लेटेंसी के बजाय थ्रूपुट के लिए आपको दूर के छोर पर एक iperf3 सर्वर की आवश्यकता है जिसे आप नियंत्रित करते हैं, और फिर iperf3 -c your-server.example.com -R उस दिशा को मापता है जिसकी आपके उपयोगकर्ताओं को परवाह है, जो कि सर्वर से क्लाइंट की दिशा है।
किसी एक स्थान को चुनने से पहले प्रत्येक संभावित स्थान पर एक ट्रायल इंस्टेंस के खिलाफ यही टेस्ट चलाएँ। VPS बेंचमार्किंग के लिए पूरी विधि नेटवर्क के साथ-साथ डिस्क और CPU को भी कवर करती है, ताकि आप केवल लेटेंसी के आधार पर चुनाव न करें।
New York address के साथ और क्या बदलता है
कीमत सबसे पहली चीज है। New York metro में बिजली और floor space की लागत Texas या Midwest की तुलना में अधिक है, और कुछ providers इसे per-location surcharge के रूप में ग्राहकों से लेते हैं, जबकि अन्य इसे अपने पूरे fleet पर औसत (average) कर देते हैं। August 2026 तक इसके लिए कोई एक नियम नहीं है, इसलिए यह मान लेने से पहले कि कोई अतिरिक्त शुल्क (penalty) लगेगा, provider के अपने order page पर दो अलग-अलग locations के लिए समान specification की कीमत जाँच लें। एक VPS की वास्तविक मासिक लागत बिल के बाकी हिस्सों को कवर करता है।
कानून सर्वर का पीछा नहीं करता है। New York का SHIELD Act किसी भी व्यक्ति के लिए breach notification और उचित सुरक्षा उपाय (reasonable-safeguard) के कर्तव्य निर्धारित करता है जो New York के निवासी की निजी जानकारी रखता है, चाहे वह data कहीं भी स्थित हो। अपने सर्वर को Dallas ले जाने से यह कर्तव्य समाप्त नहीं होता है, और इसे Manhattan ले जाने से यह शुरू नहीं होता है। यही बात GDPR (general data protection regulation) और आपके European users पर भी लागू होती है। स्थान तब मायने रखता है जब कोई contract या sector rule किसी देश का नाम लेता है, जो healthcare और कुछ financial services में आम है।
बिजली और बाढ़ के जोखिम के लिए एक paragraph आवश्यक है। जब October 2012 में Hurricane Sandy आया था, तो Lower Manhattan की कई carrier buildings की सेवा बाधित हो गई थी क्योंकि basement में लगे fuel pumps में पानी भर गया था और ऊपर रखे generators का ईंधन खत्म हो गया था। किसी भी metro में एक single site विफलता का एक single point होती है। backups को एक अलग power grid पर रखें, और कम से कम एक बार कहीं और restore करके देखें ताकि आप सुनिश्चित हो सकें कि restore प्रक्रिया काम करती है।
FAQ
क्या यूरोपीय उपयोगकर्ताओं के लिए New York VPS, central US VPS की तुलना में तेज़ है?
हाँ, और यह अंतर अनुमानित है। New York metro से London की दूरी लगभग 78 ms है, क्योंकि transatlantic cables New Jersey के तट और Long Island पर आती हैं। Dallas स्थित सर्वर पहले east coast तक पहुँचता है, इसलिए इसमें Dallas से New York के बीच का लगभग 38 ms का अतिरिक्त समय भी जुड़ जाता है। यदि किसी एक मशीन को eastern United States और Europe दोनों को सेवा देनी है, तो New York सबसे कम लागत वाला विकल्प है।
मेरा "New York" VPS वास्तव में New Jersey में क्यों है?
क्योंकि वहीं पर floor space और power उपलब्ध है। 60 Hudson Street जैसी Manhattan की इमारतें बड़े compute halls के बजाय interconnection hubs हैं, इसलिए racks Secaucus, Weehawken, Carteret, Piscataway या Newark में स्थित हैं। अतिरिक्त fiber के कारण latency में एक millisecond से भी कम की वृद्धि होती है, जिसे कोई भी web workload महसूस नहीं करेगा। किसी विशिष्ट इमारत के भीतर किसी विशेष network से cross-connect की आवश्यकता होने पर ही सटीक facility के लिए पूछें।
मुझे कैसे पता चलेगा कि latency ही मेरी समस्या है?
curl timing breakdown चलाएं और घटाएं। time_appconnect और time_starttransfer के बीच का अंतर एक network round trip और आपके सर्वर के स्वयं के processing time का योग है। यदि यह अंतर ping के साथ मापे गए round trip से काफी अधिक है, तो देरी आपके application के भीतर है और अधिक नज़दीकी data center इसे ठीक नहीं करेगा। यदि यह अंतर एक round trip के करीब है और page फिर भी धीमा है, तो देखें कि page क्रम में कितने requests करता है, क्योंकि प्रत्येक request के लिए फिर से round trip का समय लगता है।
क्या New York में hosting करने से मुझ पर लागू होने वाले privacy laws बदल जाते हैं?
ज्यादातर नहीं। New York का SHIELD Act और GDPR जैसे नियम इस पर निर्भर करते हैं कि आप किसका data रखते हैं, न कि इस पर कि disk कहाँ घूम रही है। सर्वर का स्थान तब निर्णायक कारक बनता है जब कोई अनुबंध या sector rule किसी विशिष्ट देश का नाम लेता है, जो अक्सर healthcare और financial services के कुछ हिस्सों में होता है। किसी स्थान को चुनने से पहले वास्तविक आवश्यकता को पढ़ें।
क्या एक CDN, अच्छी तरह से स्थित VPS की जगह ले सकता है?
static files के लिए, हाँ। एक CDN (content delivery network) आपके उपयोगकर्ताओं के नज़दीक images और scripts को cache करता है और उन requests के लिए अधिकांश दूरी को समाप्त कर देता है। यह logged-in dashboard या database में write को cache नहीं कर सकता, इसलिए वे अभी भी आपके origin server तक जाते हैं और पूरा round trip समय लेते हैं। origin को उन उपयोगकर्ताओं के नज़दीक रखें जो data write करते हैं, और बाकी काम CDN पर छोड़ दें।