SSD Nodes Learn 🎉 VPS $5.50/महिन्यापासून
मार्गदर्शक Matt Connorद्वारे Matt Connor · अपडेटेड 2026-08-13

Dallas VPS Hosting: तुम्हाला नेमका काय फायदा मिळतो?

Dallas VPS मुळे दोन्ही किनाऱ्यांपर्यंत central US latency आणि मजबूत carrier peering मिळते. ERCOT grid, न्यायक्षेत्र आणि इतरांसाठी hosting कधी निवडावे ते जाणून घ्या.

Dallas मधील VPS hosting मुळे तुम्हाला नेटवर्कमधील एक स्थान मिळते

VPS (virtual private server) हा एका विशिष्ट इमारतीतील physical machine चा एक भाग असतो. त्यामुळे ती इमारत वापरकर्त्यांपर्यंत पोहोचण्यासाठी लागणारा round trip time, bandwidth ची किंमत आणि तुमच्या disk पर्यंत कोणत्या न्यायालयांना पोहोचता येते हे ठरवते. Dallas हे United States च्या जवळपास मध्यभागी असून देशातील सर्वाधिक घन carrier markets पैकी एका ठिकाणी आहे. Dallas निवडण्यामागील मुख्य कारण एवढेच आहे. या मार्गदर्शकाच्या उर्वरित भागात हे कारण तुमच्या वापरकर्त्यांना लागू होते का आणि लागू होत नसल्यास काय करावे हे तपासण्याची पद्धत दिली आहे.

तुमचा server नेमका कशासाठी आहे हे अद्याप ठरवले नसेल, तर प्रथम VPS वापरून तुम्ही प्रत्यक्षात काय करू शकता हे वाचा. Location हा पहिला नव्हे, तर शेवटचा निर्णय असतो.

Dallas VPS कडून किती latency अपेक्षित ठेवता येते?

ChartTypical round trip to a Dallas VPS, milliseconds, wired connections
The data behind this chart
[
  {
    "label": "Dallas metro",
    "typical_rtt_ms": 2
  },
  {
    "label": "Houston",
    "typical_rtt_ms": 8
  },
  {
    "label": "Chicago",
    "typical_rtt_ms": 23
  },
  {
    "label": "Miami",
    "typical_rtt_ms": 33
  },
  {
    "label": "New York",
    "typical_rtt_ms": 36
  },
  {
    "label": "Los Angeles",
    "typical_rtt_ms": 35
  },
  {
    "label": "Seattle",
    "typical_rtt_ms": 50
  },
  {
    "label": "Mexico City",
    "typical_rtt_ms": 48
  },
  {
    "label": "Bogota",
    "typical_rtt_ms": 78
  },
  {
    "label": "Sao Paulo",
    "typical_rtt_ms": 140
  },
  {
    "label": "London",
    "typical_rtt_ms": 112
  },
  {
    "label": "Frankfurt",
    "typical_rtt_ms": 125
  },
  {
    "label": "Singapore",
    "typical_rtt_ms": 215
  }
]

या 13 rows हे चांगल्या peering असलेल्या मार्गांवरील wired connections साठी प्रकाशित केलेले सामान्य आकडे आहेत. ते तुमच्या मशीनवर घेतलेली मोजमापे नाहीत. त्यांना प्रारंभिक संदर्भ म्हणून वापरा. तुमचा प्रत्यक्ष परिणाम server पेक्षा तुमच्या internet provider वर अधिक अवलंबून असतो: Wi-Fi मुळे काही milliseconds वाढतात, mobile network मुळे काही tens of milliseconds वाढतात, आणि कमी peering असलेला residential provider अशा मार्गावर 30 ms वाढवू शकतो ज्यासाठी भौतिकशास्त्रानुसार 15 ms पुरेसे असायला हवे.

एका संख्येऐवजी pattern पाहा. continental United States मधील प्रत्येक मोठे शहर साधारण 50 ms किंवा त्यापेक्षा कमी अंतरावर येते. Houston साठी 8 ms आणि Chicago साठी 23 ms आहे. Mexico City सुमारे 48 ms वर आहे. हे US च्या दोन्ही किनाऱ्यांपेक्षा जवळ आहे, कारण Latin American traffic पैकी मोठा भाग आधीच Texas किंवा Florida मार्गे जातो. Sao Paulo साठी 140 ms हा लांब मार्ग आहे. Singapore साठी 215 ms आहे, आणि ही पूर्णपणे वेगळी समस्या आहे.

Raw figure पेक्षा milliseconds अधिक महत्त्वाचे असतात, कारण connection मध्ये round trips असतात. एक HTTPS request उघडण्यासाठी TCP (transmission control protocol) handshake साठी एक round trip, TLS 1.3 (transport layer security) साठी आणखी एक round trip आणि request साठी आणखी एक round trip लागतो. 35 ms latency असल्यास पहिला byte येण्यापूर्वी 100 ms पेक्षा अधिक वेळ जातो. एखादे page सलग 20 API calls करत असल्यास 35 ms चे 700 ms waiting time मध्ये रूपांतर होते. Interactive SSH मध्ये 35 ms हे 8 ms पेक्षा वेगळे जाणवते. 35 ms असलेला game server ठीक असतो, परंतु तोच server 140 ms वर ठीक नसतो. सर्व users ना एकाच वेळी जाणवणाऱ्या गोष्टीसाठी, जसे VPS वरील Minecraft server, central position प्रत्यक्ष फरक घडवते.

देशाच्या मध्यवर्ती भागातील स्थान किनाऱ्यापेक्षा चांगले आहे का?

फायबरमधील प्रकाशाचा वेग सुमारे 200,000 km प्रति सेकंद असतो. हा निर्वातातील प्रकाशाच्या वेगाच्या दोन-तृतीयांश आहे. त्यामुळे प्रत्येक 100 km फायबरसाठी round trip ला साधारण 1 ms लागतो. दोन शहरांदरम्यान फायबर कधीही पूर्णपणे सरळ मार्गाने जात नाही. ही भौतिकशास्त्राने ठरवलेली किमान मर्यादा आहे. त्यामुळे कितीही पैसे खर्च केले तरी काचेच्या फायबरच्या मर्यादेपेक्षा Dallas ते Frankfurt दरम्यानचे packet वेगाने पाठवता येत नाही. तुमच्याकडे असलेला एकमेव प्रभावी पर्याय म्हणजे location.

Dallas हे New York पासून सुमारे 2,200 km आणि Los Angeles पासून सुमारे 2,000 km अंतरावर आहे. हे अंतर असामान्यपणे संतुलित आहे. बहुतेक लोक प्रथम विचारात घेत असलेल्या दोन किनारी markets च्या तुलनेत ही तफावत पाहा.

ChartTypical round trip from three US hosting metros to both coasts, milliseconds
The data behind this chart
[
  {
    "label": "Northern Virginia",
    "to_new_york_ms": 10,
    "to_los_angeles_ms": 62
  },
  {
    "label": "Dallas",
    "to_new_york_ms": 36,
    "to_los_angeles_ms": 35
  },
  {
    "label": "Los Angeles metro",
    "to_new_york_ms": 68,
    "to_los_angeles_ms": 3
  }
]

ही आकडेवारीही सामान्यतः प्रकाशित केलेल्या figures शी जुळते. मात्र महत्त्वाचा मुद्दा म्हणजे त्यातील भौगोलिक नमुना. Northern Virginia मधील host कडून New York पर्यंत साधारण 10 ms आणि Los Angeles पर्यंत साधारण 62 ms लागतात. म्हणजेच तफावत 50 ms पेक्षा जास्त आहे. Los Angeles मधील host मध्ये याची उलट स्थिती असते: New York पर्यंत 68 ms लागतात. ज्या शहराजवळ प्रत्येक location आहे, त्या शहरासाठी Dallas दोन्हीपेक्षा खराब आहे. मात्र ज्या शहरापासून प्रत्येक location दूर आहे, त्या शहरासाठी Dallas दोन्हीपेक्षा चांगले आहे.

त्यामुळे प्रश्न कोणते शहर सर्वात वेगवान आहे हा नाही. तुम्हाला कोणता भौगोलिक नमुना हवा आहे हा खरा प्रश्न आहे. तुमचे बहुतेक users एका किनाऱ्यावर असतील आणि median latency कमी हवी असेल, तर किनाऱ्यावरील location निवडा. तुमचे users संपूर्ण देशभर पसरलेले असतील आणि worst-case latency कमी हवी असेल, तर Dallas निवडा. हाच trade-off Canadian VPS निवडताना प्रत्यक्षात काय महत्त्वाचे असते येथेही स्पष्ट केला आहे. मात्र तिथे लोकसंख्या दोन किनाऱ्यांऐवजी एका लांब पट्ट्यात पसरलेली आहे.

Dallas मधील carrier density मुळे प्रत्यक्षात काय मिळते

Carrier hotel म्हणजे अशी इमारत जिथे अनेक networks terminate होतात आणि एकमेकांशी थेट connect होतात. Dallas मध्ये अशी एक प्रसिद्ध इमारत आहे: 1950 North Stemmons Freeway येथील Infomart. Equinix ने ती 2018 मध्ये $800 million ला खरेदी केली. Internet exchange (IX) म्हणजे अशा इमारतीतील shared switch. येथे networks एकमेकांशी peer करतात. त्यामुळे त्यांच्या दरम्यान traffic वाहून नेण्यासाठी तृतीय पक्षाला पैसे द्यावे लागत नाहीत. DE-CIX ने Dallas मध्ये November 2016 पासून exchange चालवला आहे. Equinix स्वतःचा exchange चालवते.

हे traceroute मध्ये दिसते. तुमचा host आणि तुमच्या वापरकर्त्यांचा internet provider एकाच exchange वर असल्यास, packet एकाच network boundary मधून जातो. ते एकाच exchange वर नसल्यास, packet transit provider कडे पाठवला जातो. तो packet Ashburn किंवा Atlanta मार्गे नेऊन नंतर परत आणू शकतो. त्यानंतर तो packet वितरित केला जातो. अतिरिक्त अंतरामुळे प्रत्यक्ष milliseconds वाढतात. तसेच प्रत्येक अतिरिक्त network हे असे आणखी एक ठिकाण असते जिथे 9 pm वाजता भरलेली link packet loss निर्माण करू शकते.

पैसे देण्यापूर्वी तुम्ही हे सर्व तपासू शकता.

  • Provider कडून त्याचा ASN (autonomous system number) विचारा. BGP (border gateway protocol) वापरणाऱ्या प्रत्येक network कडे एक ASN असतो.
  • तो ASN PeeringDB वर शोधा. त्यात network कोणत्या exchanges मध्ये सहभागी होते आणि कोणत्या buildings मध्ये त्याची उपस्थिती आहे हे दिलेले असते. Networks स्वतःच्या entries maintain करतात.
  • Facility मध्येच कोणते exchanges उपलब्ध आहेत ते तपासा. Provider ज्या exchange मध्ये सहभागी नाही, तो exchange आणि provider एकाच building मध्ये असला तरी तुम्हाला त्याचा उपयोग होत नाही.
  • तुमचे users ज्या network वर आहेत, त्या network पासून path trace करा आणि तो किती वेगवेगळ्या networks मधून जातो ते मोजा.
mtr -rwzc 100 203.0.113.10

Report मध्ये प्रत्येक hop साठी network number, loss percentage आणि timing असलेली एक ओळ छापली जाते. शेवटची ओळ प्रथम वाचा, कारण ती तुमचा server असते. शेवटच्या hop वर loss नसताना मधल्या hop वर दिसणारा loss सामान्य असतो. Routers स्वतः निर्माण करत असलेल्या ICMP (internet control message protocol) replies ला कमी priority देतात. त्यामुळे त्या hop वर loss प्रत्यक्षापेक्षा जास्त दिसतो. एखाद्या hop पासून सुरू झालेला loss त्यानंतरच्या प्रत्येक hop वर कायम राहिला, तर तो प्रत्यक्ष fault असतो. अशा वेळी report जोडून support ticket उघडा.

टेक्सासची वीज ग्रीड तुमच्या uptime साठी जोखीम निर्माण करते का?

टेक्सास स्वतःची वीज ग्रीड चालवतो. ERCOT (Electric Reliability Council of Texas) राज्याच्या सुमारे 90 टक्के load साठी जबाबदार आहे आणि उत्तर अमेरिकेतील उर्वरित ग्रीडशी synchronized नाही. एकूण अंदाजे 1.2 GW क्षमतेच्या काही direct current ties द्वारे ते शेजारील ग्रीडशी जोडलेले आहे. 22 July 2026 रोजी नोंदवलेल्या 91 GW पेक्षा अधिक peak demand च्या तुलनेत ही क्षमता कमी आहे. त्यामुळे टेक्सासमध्ये वीज कमी पडली, तर बाहेरून वीज import करून समस्या सोडवता येत नाही. February 2021 मध्ये Winter Storm Uri मुळे ERCOT मध्ये अनेक दिवस rolling blackouts लागू झाले. त्यामागची यंत्रणा हीच होती.

तुमच्या server साठी मुख्य प्रश्न वीज ग्रीड नाही. इमारत आहे. Utility outage झाल्यावर data center काही मिनिटे UPS (uninterruptible power supply) batteries वर चालते. त्यानंतर fuel उपलब्ध असेपर्यंत diesel generators वर चालते. चार प्रश्न विचारा आणि त्यांची उत्तरे लिखित स्वरूपात घ्या: power path N+1 आहे की 2N, site वर साठवलेल्या fuel वर generators full load ला किती तास चालतात, priority fuel delivery contract आहे का, आणि real load अंतर्गत generators ची शेवटची चाचणी कधी झाली. शेवटच्या प्रश्नाचे उत्तर देऊ न शकणाऱ्या provider ने चाचणी केलेली नाही.

याच ग्रीडमुळे येथे capacity स्वस्त आहे. Texas मधील industrial electricity ची किंमत US average पेक्षा कमी आहे. Data center चा सर्वात मोठा running cost power असल्यामुळे, northern Virginia सारख्या constrained markets च्या तुलनेत Dallas मधील किंमत कमी असते. हा फरक तुमच्या invoice मध्ये दिसतो. वेगवेगळ्या शहरांतील quotes ची तुलना करताना VPS ची प्रत्यक्ष किंमत काय असते हे त्यांच्यासोबत उघडे ठेवा. त्यामुळे base rate च्या तुलनेत location premium अधिक सहज दिसतो.

Dallas मधील data center ला tornado आणि Texas मधील उष्णतेचा धोका आहे का?

या दोन प्रश्नांची दोन वेगवेगळी उत्तरे आहेत.

वारा आणि गारपीट हा इमारतीशी संबंधित प्रश्न आहे. 20 October 2019 रोजी जवळपास 140 mph वेगाच्या EF3 tornado ने Dallas Love Field जवळ जमिनीला स्पर्श केला आणि north Dallas मध्ये 15 mile लांबीचा मार्ग कापला. त्यामुळे सुमारे $1.5 billion इतके नुकसान झाले. हा मार्ग Stemmons Freeway data center corridor पासून काही miles अंतरावर आहे. Purpose-built data hall ही खिडक्या नसलेली concrete structure असते. त्यामुळे strip mall चे छत उडवून नेणारा वारा ती सहन करू शकते. उघडे भाग तिच्या वर असतात: condensers आणि cooling towers. मोठ्या आकाराची गारपीट बहुतेक वसंत ऋतूंमध्ये होते आणि नेमकी या equipment वर पडते. बाह्य संरचना कोणत्या क्षमतेसाठी rated आहे आणि mechanical plant कुठे आहे, हे विचारा.

उष्णता हा खर्चाशी संबंधित प्रश्न आहे. July आणि August मध्ये Dallas मध्ये दीर्घकाळ 100 F (38 C) पेक्षा जास्त तापमान राहते. स्थानिक design day नुसार cooling ची क्षमता निश्चित केली जाते, त्यामुळे room चे तापमान स्थिर राहते. वाढते ते PUE (power usage effectiveness, म्हणजे total facility power भागिले servers पर्यंत पोहोचणारी power), कारण February पेक्षा August मध्ये chillers अधिक मेहनत करतात. हा खर्च तुमच्या price मध्ये आधीच समाविष्ट असतो. उष्णतेचा खरा धोका म्हणजे heat wave दरम्यान cooling failure. बाहेरचे तापमान 104 F (40 C) असताना cooling नसलेली room एका तासाऐवजी काही minutes मध्ये shutdown temperature पर्यंत पोहोचते. त्यामुळे chiller दुरुस्त करण्यासाठी staff कडे खूपच कमी वेळ असतो. केवळ power आहे का हे न पाहता cooling N+1 आहे का, हे विचारा.

यापैकी कोणतेही उत्तर Dallas टाळण्याचे कारण नाही. मात्र तुमच्या data ची copy दुसऱ्या ठिकाणी ठेवण्याचे हे दोन्ही कारणे आहेत. त्याच building मधील backup हा backup नसतो. तसेच restic वापरून encrypted off site backups तयार करण्यासाठी एक afternoon पुरेसा असतो.

Dallas हे चुकीचे उत्तर कधी ठरते?

Dallas हा योग्य default आहे; तो नियम नाही. पुढील परिस्थितींमध्ये दुसऱ्या ठिकाणी host करा.

  • तुमचे users Europe मध्ये आहेत. Dallas server कडून Frankfurt ला उत्तर देण्यासाठी सुमारे 125 ms आणि London ला सुमारे 112 ms लागतात. हा फरक अंतरामुळे आहे, त्यामुळे कोणताही configuration बदल त्यात सुधारणा करू शकत नाही.
  • तुमचे users Asia किंवा Australia मध्ये आहेत. Singapore साठी 215 ms हा latency पुन्हा अधिक आहे. त्या users जवळचा दुसरा server, पहिल्या server वर करता येणाऱ्या कोणत्याही tuning पेक्षा अधिक परिणामकारक ठरतो.
  • तुमचे सर्व users Dallas नसलेल्या एका metro मध्ये आहेत. तुमचे app वापरणारे सर्वजण Seattle मध्ये असतील, तर Seattle मध्ये host करा. Users वेगवेगळ्या ठिकाणी पसरलेले असतील तेव्हाच मध्यवर्ती स्थानाचा फायदा होतो.
  • करार किंवा regulator नुसार data एखाद्या देशातच ठेवणे आवश्यक आहे. हा performance चा प्रश्न नाही आणि कोणताही benchmark याचे उत्तर देऊ शकत नाही.
  • US exchange वर latency ही तुमची strategy आहे. CME Group चे matching engine Aurora, Illinois येथे आहे. NYSE Mahwah, New Jersey येथून चालते आणि Nasdaq Carteret, New Jersey येथून चालते. Dallas हे या सर्व ठिकाणांपासून 20 ms पेक्षा अधिक अंतरावर आहे. बहुतेक retail automation ला याची चिंता नसते आणि trading bots साठी VPS निवडणे हे प्रत्यक्षात ही मर्यादा कुठे येते यावर अवलंबून असते.

डॅलसमधील सर्व्हरवर कोणते कायदे लागू होतात?

डॅलसमधील सर्व्हरवर US federal law आणि Texas state law लागू होतात. प्रत्येक security review मध्ये दोन मुद्दे समोर येतात.

US CLOUD Act मुळे US authorities एखाद्या US provider कडे असलेला data, disk प्रत्यक्षात कुठेही असला तरी, सादर करण्याचे आदेश देऊ शकतात. US मधील वेगळे शहर निवडल्याने यामध्ये काहीही बदलत नाही. तसेच US बाहेरील शहर निवडले तरी provider ही US company असल्यास या कायद्यापासून सुटका होत नाही.

Texas मध्ये hosting केल्याने तुमच्यावर Texas privacy law लागू होत नाही. TDPSA (Texas Data Privacy and Security Act), जो 1 July 2024 पासून लागू आहे, Texas मध्ये कार्यरत असलेल्या किंवा Texas residents ना product किंवा service विकणाऱ्या अशा business ला लागू होतो, जर तो federal Small Business Administration च्या व्याख्येनुसार small business नसेल. हा कायदा तुमच्या rack चे स्थान नव्हे, तर तुमच्या customers चे स्थान विचारात घेतो. सर्व्हर Chicago येथे हलवल्याने तुम्हाला सूट मिळत नाही. तो Dallas येथे हलवल्याने तुम्ही या कायद्याच्या कक्षेत आपोआप येत नाही.

European Union मधील personal data साठी, transfer mechanism उपलब्ध असल्यास US hosting अनुमत आहे. August 2026 पर्यंत EU to US Data Privacy Framework ची adequacy decision लागू आहे. EU General Court ने September 2025 मध्ये ती कायम ठेवली आहे आणि Court of Justice समोरील appeal प्रलंबित आहे. व्यावहारिक पाऊल म्हणून, तुमचा provider त्या framework अंतर्गत self certifies करतो का किंवा standard contractual clauses वर स्वाक्षरी करतो का, हे त्याला लेखी विचारावे. त्यानंतर auditor ला ते सापडेल अशा ठिकाणी मिळालेले उत्तर जतन करावे. उर्वरित legal question साठी lawyer चा सल्ला घ्या, कारण हा विषय बदलत राहतो.

स्वतःच्या मशीनवरून Dallas VPS ची चाचणी कशी करावी

वरील प्रत्येक संख्या ही दुसऱ्या व्यक्तीने केलेली मोजणी आहे. निर्णायक मोजणी तुमची असते. ती गोळा करण्यासाठी सुमारे वीस मिनिटे लागतात.

  1. Provider कडे त्याच्या Dallas location मधील test IP address आणि test file मागा. बहुतेक provider दोन्हींसह looking glass page प्रकाशित करतात.
  2. तुमचे users ज्या प्रत्येक network वर आहेत, त्या प्रत्येक network वरून किमान 20 ping पाठवा आणि summary line वाचा.
  3. मार्गाचा trace घ्या आणि तो किती networks मधून जातो ते मोजा.
  4. Test file download करा आणि sustained speed वाचा.
  5. तुमचे users सर्वाधिक वापर करत असलेल्या वेळेत, weekday evening दरम्यान, किमान दोन दिवस ही चाचणी पुन्हा करा. Congestion सकाळी 11 वाजता नाही, तर रात्री 9 वाजता दिसते.
ping -c 20 203.0.113.10
mtr -rwzc 100 203.0.113.10
curl -o /dev/null -s -w 'connect=%{time_connect}s ttfb=%{time_starttransfer}s speed=%{speed_download} B/s\n' "https://<test file host>/100mb.bin"

Windows वर पहिला command ping -n 20 203.0.113.10 आहे. ping च्या शेवटी असलेली summary line जतन करा:

rtt min/avg/max/mdev = 34.112/34.905/41.203/0.884 ms

mdev (mean deviation) हे jitter म्हणून वाचा. 35 ms चा average आणि 2 ms पेक्षा कमी mdev असलेला मार्ग स्थिर असतो. तोच 35 ms average आणि 20 ms mdev असल्यास मार्गातील काही भाग अस्थिर आहे. Interactive वापरात तो स्थिर 60 ms पेक्षा वाईट जाणवेल. Final hop वर 100 packets दरम्यान सतत दिसणारे zero पेक्षा जास्त packet loss ही त्रुटी आहे; तो किरकोळ अपवाद नाही.

Throughput साठी वेगळी चाचणी आवश्यक आहे. लांब मार्गावर एक TCP connection receive window ला round trip time ने भागल्याइतक्या वेगाने मर्यादित होते. त्यामुळे single stream download धीमे आहे म्हणून link धीमा आहे असे सिद्ध होत नाही. त्याऐवजी parallel streams वापरा. VPS वर iperf3 -s चालवा आणि तो port फक्त तुमच्या address साठी उघडा. त्यानंतर तुमच्या मशीनवरून:

iperf3 -c 203.0.113.10 -P 4 -t 30
iperf3 -c 203.0.113.10 -P 4 -t 30 -R

-P 4 चार parallel streams उघडते आणि -R दिशा उलटते. त्यामुळे दुसऱ्या run मध्ये तुमचे users प्रत्यक्षात वापरणार असलेल्या download path चे मोजमाप होते. काम पूर्ण झाल्यावर port पुन्हा बंद करा, कारण iperf3 मध्ये authentication नसते.

Network हा एक स्वतंत्र घटक आहे. CPU steal आणि disk speed हे वेगळे घटक आहेत. उत्कृष्ट location मध्ये असलेला स्वस्त plan देखील host machine वर overselling असल्यास धीमा चालतो. प्रत्यक्ष workload हलवण्यापूर्वी VPS चे benchmark कसे करावे ही प्रक्रिया पूर्ण करा. त्यानंतर नवीन VPS वरची पहिली दहा मिनिटे वापरून तो सुरक्षित करा.

FAQ

दोन्ही US coasts वरील वापरकर्त्यांसाठी Dallas मधील VPS पुरेसा वेगवान आहे का?

होय, real time games आणि latency sensitive trading वगळता इतर सर्व कामांसाठी तो पुरेसा आहे. Dallas वरून wired round trip साधारणपणे New York पर्यंत 36 ms आणि Los Angeles पर्यंत 35 ms असतो. त्यामुळे continental United States मधील कोणताही वापरकर्ता server पासून फार दूर नाही. New York साठी northern Virginia मधील server सुमारे 10 ms सह अधिक चांगला ठरतो. मात्र Los Angeles साठी तो सुमारे 62 ms सह लक्षणीयरीत्या खराब ठरतो. Median latency कमी करण्याऐवजी worst case कमी ठेवायचा असेल, तर Dallas निवडा.

Texas power grid मुळे Dallas VPS कमी विश्वासार्ह होतो का?

ERCOT हा स्वतंत्र grid आहे. त्याचे शेजारील grids सोबत सुमारे 1.2 GW direct current ties आहेत. त्यामुळे वीजटंचाईच्या काळात Texas फारशी वीज आयात करू शकत नाही. याच कारणामुळे February 2021 मध्ये Winter Storm Uri दरम्यान अनेक दिवस rolling blackouts झाले. तुमचा uptime grid पेक्षा building वर अधिक अवलंबून असतो. UPS batteries काही मिनिटे load सांभाळतात आणि diesel generators उपलब्ध fuel संपेपर्यंत load चालवतात. Provider कडे site वर साठवलेल्या fuel वर full load असताना generator किती वेळ चालतो आणि शेवटची full load test कोणत्या तारखेला झाली, हे विचारा.

Tornado किंवा Texas heat wave मुळे माझा server offline होईल का?

स्वतःहून नाही. 20 October 2019 रोजी north Dallas मधून गेलेल्या EF3 tornado ने strip malls आणि घरे उद्ध्वस्त केली. मात्र purpose built data hall ही त्या वेगासाठी बांधलेली, खिडक्यांविना concrete structure असते. उघड्यावर असलेले भाग rooftop cooling units असतात. Large spring hail मुळेही याच units चे नुकसान होऊ शकते. Heat मुळे uptime पेक्षा खर्च वाढतो, कारण cooling local design day साठी आकारलेली असते. मात्र heat wave दरम्यान cooling failure झाल्यास staff कडे प्रतिसाद देण्यासाठी खूपच कमी वेळ उरतो. Backups दुसऱ्या region मध्ये ठेवा, कारण संपूर्ण site गमावण्याचा धोका तुम्ही design करून दूर करू शकत नाही.

माझे वापरकर्ते Europe मध्ये असतील, तर Dallas मध्ये host करावे का?

नाही. Dallas server Frankfurt ला सुमारे 125 ms आणि London ला सुमारे 112 ms मध्ये उत्तर देतो. हा फरक अंतरामुळे आहे. Configuration मधील कोणताही बदल तो दूर करू शकत नाही. वापरकर्त्यांच्या जवळ host करा. ज्या कामांसाठी त्वरित प्रतिसाद आवश्यक नाही, जसे backups किंवा batch jobs, त्यासाठी Dallas मधील box ठेवा. European personal data संबंधित असल्यास, EU location वापरल्यामुळे transfer संबंधी असा प्रश्नही टाळता येतो, अन्यथा त्याचे documentation करावे लागेल.

खरेदी करण्यापूर्वी Dallas VPS ची latency कशी मोजावी?

Provider कडून test IP address घ्या. त्यानंतर वापरकर्ते वापरत असलेल्या प्रत्येक network वरून त्यावर ping -c 20 आणि mtr -rwzc 100 चालवा. ping summary मध्ये average सोबत mdev value वाचा. कमी average आणि जास्त mdev असल्यास jitter असतो. स्थिर पण जास्त असलेल्या संख्येपेक्षा असा अनुभव अधिक खराब वाटतो. वापरकर्त्यांच्या busy evening hour मध्ये दोन दिवस ही चाचणी पुन्हा करा, कारण congestion ही time of day ची समस्या असते. Throughput साठी चार parallel streams सह iperf3 वापरा. लांब path वर एक TCP stream link मुळे नव्हे, तर window size मुळे मर्यादित असतो.

#vps#datacenter#dallas#latency#hosting-location