New York VPS hosting कधी निवडावे?

न्यूयॉर्क VPS मुळे प्रत्यक्षात काय मिळते

न्यूयॉर्क VPS अमेरिकेच्या पूर्व किनाऱ्यावरील दोन मोठ्या interconnection markets पैकी एका ठिकाणी असतो. दुसरे ठिकाण Ashburn, Virginia आहे. यामुळे Boston ते Washington या पट्ट्यातील वापरकर्त्यांसाठी कमी round-trip वेळ मिळतो. तसेच North America ते Europe या मार्गावरील सर्वात कमी fiber path मिळतो. तुमचे वापरकर्ते संपूर्ण खंडात समान प्रमाणात पसरले असतील, तर मध्यवर्ती location त्यांना सहसा अधिक चांगली सेवा देते. या दोन परिस्थितींमध्ये फरक करण्यासाठी अंदाज नव्हे, तर measurement आवश्यक आहे.

न्यूयॉर्कमधील VPS hosting बहुतेक वेळा न्यू जर्सीमधील hosting का असते

मॅनहॅटनमध्ये carrier hotels आहेत. 60 Hudson Street ही सर्वात प्रसिद्ध इमारत आहे. Tribeca येथील ही Art Deco इमारत 1930 मध्ये पूर्ण झाली. तिच्यामध्ये 300 पेक्षा अधिक carriers आणि cloud providers तसेच या प्रदेशाला सेवा देणारे exchanges आहेत. यामध्ये DE-CIX New York आणि NYIIX यांचा समावेश होतो. काही blocks अंतरावर 32 Avenue of the Americas हेच काम करते. न्यू जर्सीच्या बाजूला 165 Halsey Street, Newark हे त्याचे समतुल्य ठिकाण आहे.

या इमारतींमध्ये networks एकमेकांशी जोडले जातात. मोठ्या प्रमाणावर compute येथे ठेवले जात नाही, कारण मॅनहॅटनमध्ये power आणि floor space महाग आहेत आणि त्यांचा विस्तार करणे कठीण आहे. मोठे halls Hudson नदीपलीकडे Secaucus, Weehawken, Carteret, Piscataway आणि Newark येथे आहेत. "New York" VPS विकणारा provider जवळजवळ नेहमी त्या परिसरातील एखाद्या rack कडे निर्देश करतो. तो rack Midtown पासून साधारण 40 km अंतराच्या आत असतो. अतिरिक्त fiber मुळे well under one millisecond latency वाढते, त्यामुळे web workload ला त्याची जाणीव होत नाही. एखाद्या विशिष्ट network शी cross-connect आवश्यक असेल, तरच कोणत्या इमारतीत rack आहे हे विचारा.

या महानगरात ही क्षमता का आली

चार कारणे आहेत. आणि प्रत्येक कारण इतर कारणांना अधिक बळकट करते.

• ट्रान्सअटलांटिक केबल्स अगदी जवळ येऊन उतरतात. New Jersey किनाऱ्यावरील Wall Township आणि Manasquan हे देशातील सर्वाधिक व्यस्त क्लस्टर आहेत. AEC-2 या नावाने विकली गेलेली Havfrue केबल Wall पासून Denmark मधील Blaabjerg पर्यंत जाते आणि तिच्या शाखा Ireland आणि Norway पर्यंत आहेत. Seabras-1 त्याच स्टेशनपासून Brazil पर्यंत जाते, तर TGN Atlantic Europe पर्यंत जाते. Apollo केबल England मधील Bude आणि France मधील Lannion येथून Manasquan येथे किनाऱ्यावर उतरते. Google's Grace Hopper केबल Long Island वरील Bellport येथे उतरते आणि September 2022 पासून Bude पर्यंत network traffic वाहून नेत आहे.
• Exchanges Wall Street मधून बाहेर गेले. NYSE चे matching engine Mahwah येथे, Nasdaq चे Carteret येथे आणि Cboe चे Secaucus येथे चालते. Traders या ठिकाणांना equity triangle म्हणतात. Microseconds मध्ये market data आवश्यक असलेल्या firms ना यापैकी एखाद्या ठिकाणाशेजारी space घ्यावी लागते. त्या मागणीमुळे fiber infrastructure उभारले गेले आणि आता त्याचा वापर आपण सर्व करतो.
• Media आणि advertising येथे आहेत. Real-time bidding auction ने page loading पूर्ण होण्यापूर्वी उत्तर द्यावे लागते. त्यामुळे ad exchanges ज्या agency networks ना विक्री करतात, त्यांच्या शेजारीच उभारले गेले.
• Networks जिथे आधीच networks आहेत तिथे जातात. एकदा एखाद्या building मध्ये शेकडो carriers एकत्र आल्यावर, नवीन carrier साठी इतरत्र नव्याने infrastructure उभारण्यापेक्षा त्यांच्यात सहभागी होऊन स्वस्त transit आणि चांगले peering मिळवणे अधिक फायदेशीर ठरते.

VPS खरेदीदारासाठी यापैकी कोणतीही गोष्ट प्रतिष्ठेशी संबंधित नाही. याचा अर्थ transit साठी स्पर्धा आहे, peering दाट आहे आणि Europe पर्यंतचा network path लहान आहे, कारण तो केबल्स जिथे सुरू होतात तिथूनच सुरू होतो.

प्रत्यक्ष round trip ची प्रत्यक्ष किंमत

glass मध्ये प्रकाशाचा वेग सुमारे 200,000 km प्रति सेकंद असतो. हा vacuum मधील प्रकाशाच्या वेगाच्या साधारण दोन-तृतीयांश आहे. त्यामुळे router packet ला स्पर्श करण्यापूर्वीच fiber च्या प्रत्येक 100 km साठी round-trip time 1 ms वाढतो. Fiber सरळ रेषेत जात नाही. तो right of way आणि समुद्रतळावरील मार्गांनुसार जातो. त्यामुळे प्रत्यक्ष मार्ग map वरील अंतरापेक्षा लांब असतो.

यातील गणना एका round trip ची नाही. तुमच्या protocol ला आवश्यक असलेल्या round trips ची ही संख्या आहे. नवीन HTTPS connection मध्ये TCP (transmission control protocol) handshake साठी एक round trip, TLS (transport layer security) 1.3 handshake साठी आणखी एक round trip आणि request पाठवून पहिली bytes परत मिळवण्यासाठी आणखी एक round trip लागतो. त्यामुळे browser ला HTML दिसण्यापूर्वी तीन round trips लागतात. TLS 1.2 मध्ये चौथा round trip लागतो.

[
  {
    "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
  }
]

या columns मधील आकडे measurements नसून arithmetic आहेत. first byte साठी तीन round trips धरले आहेत. chain column मध्ये सलगपणे एकामागोमाग सहा dependent API calls करणारे page दाखवले आहे. metro network मध्ये 5 ms असताना connection setup जाणवत नाही. Atlantic पार 78 ms असताना त्याच page ला HTML ची पहिली byte मिळण्यापूर्वी 234 ms प्रतीक्षा करावी लागते. सहा calls ची chain केवळ प्रतीक्षा करण्यात 468 ms घालवते. New York ते Singapore या मार्गावर 230 ms असताना त्या chain ची किंमत 1380 ms असते.

Server हलवण्यापूर्वी chain column पहा. Connection reuse आणि TLS session resumption मुळे वारंवार द्यावे लागणारे round trips कमी होतात. सहा dependent calls चे दोन parallel calls मध्ये रूपांतर केल्याने continent जवळ server हलवण्यापेक्षा जास्त वेळ वाचतो. Round trips अपरिहार्य असतील तेव्हाच server हलवा. उदाहरणार्थ, login किंवा client batch करू शकत नसलेला database write.

न्यूयॉर्क मेट्रो VPS कडून सामान्य round trip times

[
  {
    "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
  }
]

ही आकडेवारी कोणत्याही एका मशीनवरून केलेल्या मोजमापांऐवजी सामान्यतः प्रकाशित केलेली आकडेवारी म्हणून पहा. सामान्य transit वर चांगल्या प्रकारे जोडलेल्या hosts साठी ही नेहमी उद्धृत केली जाणारी range आहे. तुमचा स्वतःचा network path या range च्या कोणत्याही बाजूला असू शकतो. Ashburn सुमारे 8 ms अंतरावर आहे. त्यामुळे New York VPS कडून Virginia cluster मधील services ना प्रत्यक्षात जाणवेल असा penalty न येता requests पाठवता येतात. Toronto सुमारे 14 ms अंतरावर आहे. London सुमारे 78 ms आणि Frankfurt सुमारे 88 ms वर आहे. त्यामुळे east coast वरील एक box युरोपीय users ना स्वीकारार्ह कामगिरी देऊ शकतो, पण west coast वरील box ते करू शकत नाही.

जेव्हा East Coast placement योग्य पर्याय ठरते

• तुमचे बहुतेक वापरकर्ते Boston ते Washington या corridor मध्ये आहेत. या पट्ट्यात United States मधील इंटरनेट मागणीचा मोठा हिस्सा आहे आणि या सर्व वापरकर्त्यांपर्यंत metro पासून काही milliseconds मध्ये पोहोचता येते.
• तुम्ही एकाच मशीनवरून eastern United States आणि Europe ला सेवा देता. New York हा सर्वात कमी खर्चाचा तडजोडीचा पर्याय आहे, कारण transatlantic leg येथून सुरू होतो.
• तुम्ही metro मध्ये आधीपासून उपलब्ध असलेल्या एखाद्या सेवेवर अवलंबून आहात: Secaucus किंवा Ashburn मधील market data feed, ad exchange किंवा partner API.
• Canadian hosting न करता Canada पर्यंतचा मार्ग लहान ठेवायचा आहे. Toronto पर्यंतचा RTT सुमारे 14 ms आहे. Canadian data residency ही कठोर आवश्यकता असल्यास तो वेगळा निर्णय आहे आणि Canadian VPS hosting निवडताना प्रत्यक्षात काय महत्त्वाचे आहे हा मुद्दा स्पष्ट करते.

मध्यवर्ती US location पूर्व किनाऱ्यापेक्षा अधिक योग्य ठरण्याची वेळ

सरासरी परिस्थितीऐवजी सर्वात वाईट परिस्थितीसाठी रचना करा. दूरच्या किनाऱ्यावरील वापरकर्त्याला विलंब जाणवतो. शेजारच्या राज्यातील वापरकर्त्याला तो जाणवत नाही.

[
  {
    "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 अंतरावर आहे. त्यामुळे संपूर्ण देशातील त्याची सर्वात वाईट स्थिती New York च्या तुलनेत साधारण निम्मी आहे. तुमचा traffic map खरोखरच राष्ट्रीय स्वरूपाचा असेल, तर ही अधिक सक्षम location ठरते. Dallas मध्ये VPS ठेवण्याच्या बाजूने असलेले कारण या market चे सविस्तर विश्लेषण करते. Chicago हा दुसरा योग्य मध्यवर्ती पर्याय आहे; मात्र त्याचा कल पूर्वेकडे आहे.

आणखी दोन परिस्थितींमध्ये New York टाळणे योग्य ठरते. तुमचे वापरकर्ते Ontario किंवा Quebec मध्ये केंद्रित असतील, तर Toronto VPS त्यांना थेट सेवा देतो. त्यामुळे New York मधून जाणारा 14 ms चा hop जोडला जात नाही. तुमचा जवळजवळ सर्व traffic तुमच्या स्वतःच्या servers दरम्यान चालत असेल, तर ते एकाच region मध्ये ठेवा आणि geography चा विचार करणे थांबवा. कारण cross-region hop मुळे वापरकर्त्यांच्या जवळ server ठेवून मिळणारा कोणताही फायदा नष्ट होईल.

मार्केटिंग नकाशावर विश्वास ठेवू नका; प्रत्यक्ष मोजमाप करा

Coverage map इमारत कुठे आहे हे सांगतो. मात्र packets त्या इमारतीपर्यंत कसे पोहोचतात हे तो सांगत नाही. हा मार्ग distance ने नव्हे, तर transit contracts आणि peering agreements ने ठरतो. त्यामुळे तुमचे users जिथे आहेत तिथून मोजमाप करा. Home broadband वरील laptop हा VPS पेक्षा चांगला probe असतो, कारण VPS network च्या चांगल्या बाजूला असतो.

sudo apt update
sudo apt install -y mtr-tiny traceroute iperf3

सुरुवात साध्या round trip ने करा आणि चारऐवजी twenty probes पाठवा. hostname ऐवजी तुमचा स्वतःचा server वापरा.

ping -c 20 your-server.example.com

शेवटची line rtt min/avg/max/mdev दाखवते. तिथला average हा सर्वात कमी उपयुक्त number आहे. mdev म्हणजे jitter. Average चांगला दिसत असला तरी high jitter मुळे voice आणि interactive sessions खंडित होतात. Wired path वर zero पेक्षा जास्त packet loss ही noise नसून fault आहे.

त्यानंतर वेळ कुठे खर्च होतो ते शोधा.

mtr -rwzbc 100 your-server.example.com

mtr प्रत्येक hop ला 100 probes पाठवते आणि प्रत्येक hop साठी loss व latency दाखवते. -z मध्ये AS (autonomous system) number जोडला जातो. त्यामुळे प्रत्येक hop कोणत्या network च्या मालकीचा आहे ते दिसते. एखाद्या मधल्या hop वर loss दिसला, पण नंतरच्या hops वर तो दिसेनासा झाला, तर तो खरा loss नाही. त्या router ने स्वतः तयार करावयाच्या ICMP replies वर rate limiting लागू केली आहे. त्यामुळे तुमच्या traffic ला कोणताही खर्च होत नाही. एखाद्या hop पासून सुरू झालेला loss त्यानंतरच्या प्रत्येक hop वर सुरू राहिला, तर तो खरा loss आहे.

Web service चे परीक्षण करण्यासाठी ICMP हेही चुकीचे protocol आहे, कारण अनेक networks त्याला low priority देतात. तुम्ही प्रत्यक्षात serve करता त्या गोष्टीचा वेळ मोजा.

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/

प्रत्येक value ही सुरुवातीपासूनची cumulative seconds असते. त्यामुळे वाचनासाठी वजाबाकी करा. time_connect मधून time_namelookup वजा केल्यास एक round trip मिळतो. time_appconnect मधून time_connect वजा केल्यास TLS handshake मिळतो. time_starttransfer मधून time_appconnect वजा केल्यास आणखी एक round trip आणि तुमच्या application ने उत्तर देण्यासाठी घेतलेला वेळ मिळतो. ही शेवटची वजाबाकी diagnosis देते. ती एका round trip च्या जवळ असल्यास network ही मर्यादा आहे आणि जवळचा server उपयुक्त ठरेल. ती round trip पेक्षा अनेक पटींनी जास्त असल्यास तुमचे application slow आहे; ते हलवल्याने काहीही बदलणार नाही.

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'

एकाच निर्णयावर commit करण्यापूर्वी प्रत्येक candidate location मधील trial instance विरुद्ध हीच test चालवा. VPS benchmarking ची संपूर्ण पद्धत network सोबत disk आणि CPU चेही benchmarking करते. त्यामुळे तुम्ही केवळ latency वर आधारित निवड करत नाही.

New York पत्त्यामुळे आणखी काय बदलते

सर्वप्रथम किंमत बदलते. New York महानगर क्षेत्रातील वीज आणि floor space यांची किंमत Texas किंवा Midwest पेक्षा जास्त असते. काही providers हा खर्च प्रति-location surcharge म्हणून ग्राहकाकडून घेतात. इतर providers तो संपूर्ण fleet मध्ये सरासरीने विभागतात. August 2026 पर्यंत यासाठी एकच नियम नाही. त्यामुळे penalty आहे असे गृहीत धरण्यापूर्वी, provider च्या स्वतःच्या order page वर दोन locations साठी समान specification ची किंमत तपासा. VPS ची प्रतिमहिना वास्तविक किंमत या बिलातील उर्वरित भागाचे स्पष्टीकरण देते.

कायदा server चे स्थान पाहून लागू होत नाही. New York च्या SHIELD Act नुसार New York रहिवाशाची private information ज्या व्यक्ती किंवा संस्थेकडे आहे, त्या व्यक्ती किंवा संस्थेवर breach notification आणि reasonable safeguards यांची कर्तव्ये असतात. हा data Dallas येथे हलवल्याने ते कर्तव्य संपत नाही. तो Manhattan येथे हलवल्याने ते कर्तव्य नव्याने निर्माणही होत नाही. GDPR (general data protection regulation) आणि तुमचे European users यांनाही हेच लागू होते. Contract किंवा sector rule मध्ये एखाद्या देशाचा स्पष्ट उल्लेख असल्यास location महत्त्वाचे ठरते. Healthcare आणि काही financial services क्षेत्रांत हे सामान्य आहे.

Power आणि flood risk यांना स्वतंत्रपणे विचारात घ्या. October 2012 मध्ये Hurricane Sandy आला तेव्हा Lower Manhattan मधील अनेक carrier buildings ची सेवा खंडित झाली. Basement मधील fuel pumps पुराच्या पाण्यात बुडाले आणि वरच्या मजल्यांवरील generators मधील इंधन संपले. कोणत्याही महानगरातील एकच site हा single point of failure असतो. Backups वेगळ्या power grid वर ठेवा. Restore कार्यरत आहे याची खात्री करण्यासाठी किमान एकदा ते दुसऱ्या ठिकाणी restore करून पाहा.

FAQ

युरोपमधील वापरकर्त्यांसाठी New York VPS मध्यवर्ती US सर्व्हरपेक्षा जलद आहे का?

होय, आणि फरक अंदाज करता येण्याजोगा असतो. transatlantic cables New Jersey coast आणि Long Island येथे किनाऱ्यावर येत असल्यामुळे London हे New York metro पासून सुमारे 78 ms अंतरावर आहे. Dallas मधील सर्व्हरला प्रथम east coast पर्यंत जावे लागते. त्यामुळे त्यावर Dallas ते New York या सुमारे 38 ms मार्गाचा अतिरिक्त वेळ येतो. एकाच मशीनने eastern United States आणि Europe या दोन्ही भागांना सेवा द्यायची असल्यास, सर्वात कमी खर्चाचा तडजोडीचा पर्याय New York आहे.

माझा "New York" VPS प्रत्यक्षात New Jersey मध्ये का आहे?

कारण तिथे rack space आणि वीज उपलब्ध असते. 60 Hudson Street सारख्या Manhattan मधील इमारती मोठ्या compute halls नसून interconnection hubs आहेत. त्यामुळे racks Secaucus, Weehawken, Carteret, Piscataway किंवा Newark येथे असतात. अतिरिक्त fiber मुळे एक 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 कुठे फिरते यावर नाही. एखाद्या contract किंवा sector rule मध्ये विशिष्ट देशाचे नाव दिले असल्यास server location निर्णायक ठरते. Healthcare आणि financial services च्या काही भागांत असे अनेकदा होते. एखादी location निवडण्यापूर्वी प्रत्यक्ष requirement वाचा.

योग्य ठिकाणी ठेवलेला VPS CDN ची जागा घेऊ शकतो का?

Static files साठी होय. CDN (content delivery network) images आणि scripts तुमच्या users जवळ cache करते आणि त्या requests साठीचे अंतर बहुतांश कमी करते. Logged-in dashboard किंवा तुमच्या database मधील write ते cache करू शकत नाही. त्यामुळे त्या requests अजूनही तुमच्या origin server पर्यंत जातात आणि पूर्ण round trip साठीचा वेळ लागतो. Data लिहिणारे users ज्या ठिकाणी आहेत त्यांच्या जवळ origin ठेवा आणि उर्वरित traffic CDN कडे द्या.