Frankfurt मधील VPS hosting कोणासाठी योग्य आहे?

Frankfurt मधील VPS hosting कोणासाठी योग्य आहे

Frankfurt मधील VPS hosting अशा प्रकल्पांसाठी योग्य आहे ज्यांचे वापरकर्ते Germany मध्ये, विस्तृत German-speaking बाजारपेठेत किंवा European Union मध्ये विखुरलेले आहेत. Frankfurt हे European networks एकत्र येऊन network traffic एकमेकांकडे थेट पाठवतात अशा प्रमुख ठिकाणांपैकी एक आहे. त्यामुळे तेथील server काही दहापट milliseconds मध्ये खंडातील बहुतांश ठिकाणांपर्यंत पोहोचतो. तुमचे वापरकर्ते मुख्यतः North America मध्ये असतील, तर machine कितीही वेगवान असली तरी European server त्यांना धीमा वाटेल. कारण अंतरामुळे निर्माण होणारी किमान latency tuning ने दूर करता येत नाही.

Location ठरवताना दोन स्वतंत्र प्रश्न महत्त्वाचे असतात. हे प्रश्न एकत्र मिसळल्यामुळे चुकीचे निर्णय घेतले जातात. पहिला प्रश्न म्हणजे तुमचे वापरकर्ते कुठे आहेत. हा अंतर आणि round-trip time यांच्याशी संबंधित प्रश्न आहे. दुसरा प्रश्न म्हणजे तुमचा data कुठे ठेवण्याची परवानगी आहे. हा कायदेशीर आणि contractual प्रश्न आहे. European वापरकर्त्यांसाठी पहिल्या प्रश्नाचे Frankfurt कडे ठोस उत्तर आहे. दुसऱ्या प्रश्नात ते एक विशिष्ट समस्या दूर करते; मात्र इतर कोणत्याही बाबींचे आपोआप निराकरण करत नाही.

फ्रँकफुर्टची नेटवर्कशी जोडणी इतकी चांगली का आहे?

फ्रँकफुर्टमध्ये DE-CIX (Deutsche Commercial Internet Exchange) आहे. हा IXP (internet exchange point) peak traffic आणि जोडलेल्या networksच्या संख्येनुसार जगातील सर्वात मोठ्या IXPपैकी एक आहे. IXP म्हणजे data centreमधील shared switching fabric. येथे स्वतंत्र networks एकमेकांशी जोडले जातात. त्यामुळे traffic एका मोठ्या networkकडून वाहून नेण्यासाठी अधिक शुल्क द्यावे लागत नाही. DE-CIX त्याची सध्याची traffic statistics त्याच्या स्वतःच्या siteवर प्रकाशित करते. ही आकडेवारी बदलत असते. त्यामुळे articleमध्ये कॉपी केलेल्या आकडेवारीवर विश्वास ठेवण्याऐवजी ती तेथेच पाहा.

याचा व्यावहारिक परिणाम एकूण trafficवर नव्हे, तर pathsवर होतो. तुमच्या providerचे network आणि visitorचा ISP (internet service provider) एकाच exchangeला जोडलेले असतील, तर त्यांच्यातील traffic त्या exchangeवरून जाणाऱ्या एका routed hopमधून जाते. ते स्थानिक पातळीवर peer करत नसतील, तर traffic दोन्ही networksना वाहून नेणाऱ्या तिसऱ्या networkपर्यंत जावे लागते. त्या networkचा सर्वात जवळचा handover point दुसऱ्या देशात असू शकतो. दोन German networks Amsterdam किंवा Londonमार्गे trafficची देवाणघेवाण करत असतील, तर अतिरिक्त अंतर दोन्ही दिशांनी एकदा असे मोजले जाते. Network engineers याला tromboning म्हणतात. जवळचा server प्रत्यक्षात दूर असल्याचे मोजले जाण्याचे हे नेहमीचे कारण आहे.

हे गृहीत न धरता तुम्ही प्रत्यक्ष पाहू शकता. तुम्हाला महत्त्वाच्या असलेल्या networkवरून तुमच्या serverविरुद्ध mtr चालवा आणि reverse DNSमधील hop names वाचा. Router hostnamesमध्ये सहसा IATA airport codes असतात. त्यामुळे hop nameमधील fra म्हणजे Frankfurt, ams म्हणजे Amsterdam आणि lhr म्हणजे London. German consumer connectionपासून German serverपर्यंतच्या pathमध्ये मध्यभागी lhr दिसत असेल, तर अतिरिक्त milliseconds नेमके कुठे खर्च झाले हे त्यातून कळते.

तुमच्या वापरकर्त्यांपासून Frankfurt किती दूर आहे?

फायबरमधील प्रकाश निर्वातातील वेगाच्या साधारण दोन-तृतीयांश वेगाने प्रवास करतो. हा वेग जवळपास 200,000 किलोमीटर प्रति सेकंद आहे. राउंड ट्रिपमध्ये मार्ग दोनदा पार करावा लागतो. त्यामुळे d किलोमीटर अंतरासाठी शक्य तितक्या जलद राउंड ट्रिपचा कालावधी d/100 मिलीसेकंद असतो. ही किमान सैद्धांतिक मर्यादा आहे. ती उपयुक्त आहे, कारण कोणतीही गोष्ट यापेक्षा वेगवान असू शकत नाही.

[
  {
    "label": "Zurich",
    "distance_km": 304,
    "min_rtt_ms": 3.0
  },
  {
    "label": "Amsterdam",
    "distance_km": 365,
    "min_rtt_ms": 3.7
  },
  {
    "label": "Berlin",
    "distance_km": 424,
    "min_rtt_ms": 4.2
  },
  {
    "label": "Paris",
    "distance_km": 479,
    "min_rtt_ms": 4.8
  },
  {
    "label": "Milan",
    "distance_km": 519,
    "min_rtt_ms": 5.2
  },
  {
    "label": "Vienna",
    "distance_km": 600,
    "min_rtt_ms": 6.0
  },
  {
    "label": "London",
    "distance_km": 640,
    "min_rtt_ms": 6.4
  },
  {
    "label": "Warsaw",
    "distance_km": 903,
    "min_rtt_ms": 9.0
  },
  {
    "label": "Stockholm",
    "distance_km": "1,197",
    "min_rtt_ms": 12.0
  },
  {
    "label": "Madrid",
    "distance_km": "1,419",
    "min_rtt_ms": 14.2
  },
  {
    "label": "New York",
    "distance_km": "6,206",
    "min_rtt_ms": 62.1
  }
]

ही गणना प्रत्यक्ष मोजमापावर नव्हे, तर सरळ रेषेतील अंतरावर आधारित आहे. शेवटचा स्तंभ भौतिकशास्त्रानुसार शक्य असलेली सर्वोत्तम स्थिती दर्शवतो. प्रत्यक्ष मोजमापे साधारणपणे या किमान मर्यादेच्या 1.5 ते 2 पट असतात. याचे कारण म्हणजे फायबरचे मार्ग great circle प्रमाणे नसून रस्ते आणि नदीखोऱ्यांनुसार जातात. तसेच मार्गातील प्रत्येक router मुळे forwarding आणि queuing मध्ये थोडासा विलंब वाढतो.

Berlin हे Frankfurt पासून 424 km अंतरावर आहे. त्यासाठी किमान मर्यादा 4.2 ms आहे. Madrid 1,419 km अंतरावर आहे. त्यासाठी किमान मर्यादा 14.2 ms आहे. या ठिकाणापासून ते EU मधील सर्वांत दूरचे टोक आहे. New York 6,206 km अंतरावर आहे आणि त्यासाठी किमान मर्यादा 62.1 ms आहे. म्हणून transatlantic वापरकर्त्यांसाठी हा स्थाननिवडीचा निर्णय आहे; tuning करून सोडवता येणारी समस्या नाही.

मंद round trip मुळे page load ला किती विलंब होतो?

एक round trip क्वचितच फक्त एक round trip असतो. HTTPS connection उघडण्यासाठी TCP (transmission control protocol) handshake साठी एक round trip आणि TLS (transport layer security) 1.3 handshake साठी आणखी एक round trip लागतो. त्यानंतर request साठी तिसरा round trip लागतो आणि मग response चा पहिला byte परत येतो. TLS 1.2 मध्ये चौथा round trip लागतो. आधीपासून cache मध्ये नसलेला DNS (domain name system) lookup केल्यास किमान आणखी एक round trip लागतो आणि तो पुन्हा वेगळ्या server कडे होतो.

[
  {
    "label": "User in Frankfurt",
    "rtt_ms": 5,
    "first_byte_ms": 15
  },
  {
    "label": "User in Warsaw",
    "rtt_ms": 20,
    "first_byte_ms": 60
  },
  {
    "label": "User in Madrid",
    "rtt_ms": 30,
    "first_byte_ms": 90
  },
  {
    "label": "User in New York",
    "rtt_ms": 90,
    "first_byte_ms": 270
  },
  {
    "label": "User in Singapore",
    "rtt_ms": 170,
    "first_byte_ms": 510
  }
]

इथला round-trip column हा Frankfurt server पर्यंतच्या शक्य मार्गावरील गृहीतक आहे. दुसरा column त्यावरील गणित दाखवतो: पहिला byte येण्यापूर्वी तीन round trips. Frankfurt मधील user 15 ms प्रतीक्षा करतो. Singapore मधील user, ज्याचा round-trip time 170 ms आहे, तो browser ने काहीही render करण्यापूर्वी त्याच response साठी 510 ms प्रतीक्षा करतो.

हा multiplier महत्त्वाचा आहे. RTT (round-trip time) मधील प्रत्येक अतिरिक्त millisecond मुळे पहिला byte येण्यापूर्वी सुमारे तीन milliseconds चा विलंब वाढतो. त्यानंतरही हाच परिणाम सुरू राहतो. HTML मध्ये stylesheet चे नाव दिलेले असते आणि stylesheet मध्ये font चे नाव दिलेले असते. यापैकी प्रत्येक शोधासाठी त्याच connection वर आणखी एक round trip लागतो. अंतरामुळे दोनशे milliseconds चा अतिरिक्त विलंब आला, तर क्षणार्धात उघडणारे page slow वाटू लागते. मात्र server तेच काम त्याच वेळेत करत असतो.

यामुळे CDN (content delivery network) कोणती समस्या सोडवू शकतो याची मर्यादा स्पष्ट होते. User जवळच्या cache मधून दिल्या जाणाऱ्या static files साठी लांब network path टाळता येतो. पण logged-in dashboard ला database कडे query पाठवावी लागत असल्यास तसे होत नाही. त्या request ला अजूनही पूर्ण अंतर दोनदा पार करावे लागते. Login करणारे users ज्या ठिकाणी आहेत त्यांच्या जवळ origin ठेवणे ही अशी बाब आहे जी कोणताही cache तुमच्यासाठी करू शकत नाही.

हे मी माझे वापरकर्ते जिथे आहेत तिथून कसे मोजू?

तुम्हाला ज्या नेटवर्कबद्दल माहिती हवी आहे त्या नेटवर्कवरील मशीनवरून ही commands चालवा. शक्य असल्यास, तुम्ही सेवा देत असलेल्या देशातील घरगुती किंवा कार्यालयीन connection चा वापर करा. दुसऱ्या data centre मधील server वरून मोजमाप केल्यास वापरकर्त्यांच्या मार्गांऐवजी data centre चे network paths समजतात. खालील commands स्वतः चालवण्याची उदाहरणे आहेत. तुम्ही प्रत्यक्ष मोजलेल्या latency figures वरच कृती करणे उपयुक्त ठरते.

ping -c 20 your-server.example.com

Summary line मध्ये rtt min/avg/max/mdev = ... दिसते. नेहमीच्या स्थितीसाठी avg आणि packets मधील फरक असलेल्या jitter साठी mdev वाचा. जास्त mdev असलेले सामान्य avg network path अस्थिर असल्याचे दर्शवते. किंचित जास्त average latency पेक्षा याचा SSH किंवा voice सारख्या interactive कामांवर अधिक परिणाम होतो.

sudo apt update && sudo apt install -y mtr-tiny
mtr -rwzc 50 your-server.example.com

-r live display ऐवजी report छापते, -w मोठी hostnames पूर्णपणे दाखवते, -z प्रत्येक hop चा AS (autonomous system) number दाखवते आणि -c 50 पन्नास cycles पाठवते. मधल्या एका hop वर loss दिसत असेल, पण अंतिम hop वर loss नसेल, तर ते सामान्य आहे आणि fault नाही. अनेक routers स्वतःसाठी तयार होणाऱ्या ICMP replies वर rate-limit लावतात, परंतु इतर traffic नीट forward करतात. एखाद्या hop पासून सुरू झालेला loss त्यानंतरच्या प्रत्येक hop वर कायम राहिला, तर तो वास्तविक loss आहे.

curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://your-server.example.com/

प्रत्येक field मध्ये request सुरू झाल्यापासूनचे cumulative seconds असतात. त्यामुळे ते वजाबाकी करून वाचा. time_namelookup हा DNS साठीचा वेळ आहे. time_connect मधून तो वजा केल्यास TCP handshake चा वेळ मिळतो. तो साधारणपणे one round trip इतका असतो. time_appconnect मधून time_connect वजा केल्यास TLS handshake चा वेळ मिळतो. time_starttransfer मधून time_appconnect वजा केल्यास तुमच्या application चा स्वतःचा processing time आणि आणखी one round trip मिळतो. हे time gaps लहान असतील आणि total तरीही मोठे असेल, तर समस्या city मध्ये नाही, तर तुमच्या code मध्ये आहे.

Latency ऐवजी throughput मोजण्यासाठी VPS वर iperf3 -s चालवा, firewall मध्ये त्याचा port उघडा आणि download direction तपासण्यासाठी client वरून iperf3 -c your-server.example.com -R चालवा. ज्या ठिकाणी तुमच्याकडे machine नाही, तेथून मोजमाप करण्यासाठी RIPE Atlas संपूर्ण Europe मध्ये probes उपलब्ध करून देते. दोन networks ऐवजी दोन servers ची तुलना करताना एकदाच घेतलेल्या numbers ऐवजी निश्चित method वापरा. यासाठी पुनरावृत्ती करता येणारा VPS benchmark उपयुक्त आहे.

फ्रँकफर्टमधील सर्व्हरमुळे माझा प्रकल्प GDPR अनुरूप होतो का?

नाही. याचे कारण अचूकपणे समजून घेणे महत्त्वाचे आहे. GDPR (General Data Protection Regulation) कोणाचा वैयक्तिक डेटा तुम्ही प्रक्रिया करता आणि तुमची संस्था कुठे स्थापन झाली आहे यावर लागू होतो; हार्डवेअर कोणत्या देशात आहे यावर नाही. सर्व्हर फ्रँकफर्टला हलवल्यामुळे अनुपालन निर्माण होत नाही. तसेच तो EU बाहेर चालवल्यामुळे आपोआप नियमभंग होत नाही. सर्व्हरचे स्थान हा अनेक घटकांपैकी एक घटक आहे.

EU किंवा विस्तृत EEA (European Economic Area) मध्ये होस्टिंग केल्यामुळे आंतरराष्ट्रीय डेटा हस्तांतरणाचा प्रश्न मात्र दूर होतो. EEA बाहेर वैयक्तिक डेटा पाठवण्याबाबत GDPR मध्ये स्वतंत्र संपूर्ण प्रकरण आहे. त्यासाठी adequacy decision किंवा standard contractual clauses यांसारख्या कायदेशीर साधनाची आवश्यकता असते. फ्रँकफर्टमध्येच राहणारा डेटा हस्तांतरित केला जात नाही. त्यामुळे त्या मार्गासाठी हे प्रकरण लागू होत नाही. हा खरा सुलभतेचा लाभ आहे, आणि त्याची व्याप्ती एवढीच आहे.

उर्वरित सर्व जबाबदारी तुमचीच राहते. प्रत्येक उद्देशासाठी तुमच्याकडे कायदेशीर आधार असणे आवश्यक आहे. तुमच्या डेटाबेसमधील व्यक्तींसाठी प्रवेश आणि deletion rights प्रत्यक्षात कार्यरत असणे आवश्यक आहे. तुम्ही प्रत्यक्ष अंमलात आणता अशी retention limit असणे आवश्यक आहे. जोखमीला अनुरूप security measures लागू करणे आवश्यक आहे. वैयक्तिक डेटा breach झाल्याचे समजल्यानंतर 72 तासांच्या आत supervisory authority कडे अहवाल देणे आवश्यक आहे. तुमच्या hosting provider सोबत processor agreement देखील आवश्यक आहे. जर्मनीमध्ये त्याला Auftragsverarbeitungsvertrag किंवा AVV म्हणतात. हेही लक्षात ठेवा की EEA बाहेरील support staff ला सर्व्हरचा access असल्यास फ्रँकफर्टमधील सर्व्हरमध्येही डेटा हस्तांतरण होऊ शकते. त्यामुळे keys कोणाकडे आहेत हे तपासा.

जर्मनीमध्ये यावर आणखी एक राष्ट्रीय स्तर लागू होतो. संघीय BDSG (Bundesdatenschutzgesetz) राष्ट्रीय नियमांद्वारे या regulation ला पूरक ठरतो. Employee data हे लोकांना सर्वाधिक वेळा आश्चर्यचकित करणारे क्षेत्र आहे. हा विभाग सर्वसाधारण पार्श्वभूमी देतो; तो legal advice नाही. European Data Protection Board अधिकृत guidelines edpb.europa.eu येथे प्रकाशित करते. प्रत्यक्ष परिणाम असलेल्या कोणत्याही बाबतीत tutorial पेक्षा qualified adviser चा सल्ला घ्या.

सर्व्हरवरच मी काय बदलावे?

सिस्टम घड्याळ UTC (coordinated universal time) वर ठेवा आणि तुमच्या अॅप्लिकेशनमध्ये timestamps चे format ठरवा. Germany मध्ये daylight saving पाळले जाते. त्यामुळे स्थानिक वेळ वर्षातून दोनदा एका तासाने बदलते आणि October च्या शेवटी एक तास पुन्हा येतो. त्या रात्री स्थानिक वेळेत लिहिलेल्या logs मध्ये 02:30 च्या दोन entries असतात. वेगवेगळ्या प्रदेशांतील logs यांच्याशी correlation करणे मग अंदाजावर अवलंबून राहते. तरीही server वरील वेळ स्थानिक ठेवायची असल्यास ती स्पष्टपणे set करा आणि तपासा:

sudo timedatectl set-timezone Europe/Berlin
timedatectl

Output मध्ये summer मध्ये Time zone: Europe/Berlin (CEST, +0200) आणि winter मध्ये +0100 दिसले पाहिजे.

Default C locale अंतर्गत German text चुकीच्या क्रमाने sort होते, कारण C sorting raw bytes ची तुलना करते. Locale generate करा आणि फरक पाहा:

sudo locale-gen de_DE.UTF-8
sudo update-locale
printf 'Zebra\nÄpfel\nApfel\n' | LC_ALL=C sort
printf 'Zebra\nÄpfel\nApfel\n' | LC_ALL=de_DE.UTF-8 sort

पहिल्या sort मध्ये Äpfel हे Zebra नंतर येते, कारण UTF-8 मधील त्याचा पहिला byte कोणत्याही ASCII अक्षरापेक्षा मोठा आहे. दुसऱ्या sort मध्ये ते Apfel च्या शेजारी येते, जिथे German वाचकाला ते अपेक्षित असते. हा फरक दिसतो त्यापेक्षा अधिक महत्त्वाचा आहे. PostgreSQL आणि MySQL database तयार करताना collation निश्चित करतात. नंतर ते बदलण्यासाठी indexes पुन्हा तयार करावे लागतात. Data load करण्यापूर्वी निर्णय घ्या.

German package mirror वापरल्याने apt runs कमी होतात. Ubuntu 24.04 मध्ये sources deb822 format मध्ये /etc/apt/sources.list.d/ubuntu.sources येथे असतात. त्यामुळे दुसरी file add करण्याऐवजी URIs: line बदलून http://de.archive.ubuntu.com/ubuntu/ करा. दुसरी file add केल्यास Target Packages ... is configured multiple times मिळते. हा deb822 duplicate sources error आहे आणि तो resolve करेपर्यंत updates थांबतात.

AAAA record publish करा. काही German ISPs consumer connections साठी DS-Lite (dual-stack lite) setup देतात. यात customer कडे public IPv4 address अजिबात नसतो आणि त्याचा IPv4 traffic carrier च्या translation gateway मधून जातो. त्या gateway मुळे latency वाढते आणि peak hours मध्ये congestion होते. त्याउलट IPv6 traffic थेट बाहेर जातो. Record set केल्यानंतर दोन्ही paths तपासा:

dig AAAA your-server.example.com +short
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://your-server.example.com/

दुसऱ्या command मधील 200 याचा अर्थ IPv6 end to end कार्यरत आहे. Could not resolve host किंवा connection error दिसल्यास record किंवा listener उपलब्ध नाही. अशा वेळी तुमचे DS-Lite visitors slow path वापरतात.

चुकीची निवड ठरणारे Frankfurt

• तुमचे वापरकर्ते United States मध्ये आहेत. त्यांना त्याच प्रदेशातून सेवा द्या: देशाच्या मध्यवर्ती भागाजवळील Dallas मधील VPS आणि New York मधील VPS hosting हा east coast तसेच Atlantic पार करणाऱ्या traffic साठी अधिक लहान मार्ग ठरतो.
• तुमचे वापरकर्ते Latin America मध्ये आहेत. Frankfurt हे New York पेक्षा São Paulo पासून अधिक दूर आहे. त्यामुळे त्या प्रेक्षकांसाठी Brazil मधील VPS हे योग्य उत्तर आहे.
• तुमचा data EU बाहेरील एखाद्या विशिष्ट देशातच ठेवणे आवश्यक आहे. Canadian public sector मधील काम हे याचे सामान्य उदाहरण आहे. तेथे data residency संबंधी Canadian VPS hosting साठी प्रत्यक्षात काय महत्त्वाचे आहे हे स्पष्ट करते.
• तुम्ही game server चालवता. Players ना round-trip time मधील प्रत्येक millisecond जाणवतो. त्यामुळे इतर सर्व specification पेक्षा त्यांच्याजवळील location अधिक महत्त्वाची ठरते: game servers साठी VPS निवडणे याची पद्धत स्पष्ट करते.

अनेक देशांत विखुरलेल्या European audience साठी Frankfurt ही सुरक्षित single choice आहे. तुमचा विस्तार झाला तरी ती सुरक्षित राहते, कारण तुम्हाला पोहोचायची networks आधीपासूनच त्या exchange वर जोडलेल्या आहेत. स्थलांतर करण्यापूर्वी तुमचे users ज्या ठिकाणी आहेत तेथून measurement घ्या आणि नंतर पुन्हा घ्या. दोन्ही संचातील numbers जतन करा.

FAQ

संपूर्ण युरोपसाठी Frankfurt मधील एक VPS पुरेसा आहे का?

बहुतेक प्रकल्पांसाठी, होय. सरळ अंतरानुसार Stockholm पर्यंतचा किमान विलंब 12.0 ms आणि Madrid पर्यंतचा 14.2 ms आहे. प्रत्यक्ष network paths साधारणपणे या किमान मूल्याच्या 1.5 ते 2 पट असतात. त्यामुळे जवळजवळ संपूर्ण EU मधील ठिकाणे Frankfurt मधील एका सर्व्हरपासून कमी दहाच्या millisecond विलंबाच्या आत राहतात. एखाद्या विशिष्ट देशातून प्रत्यक्ष तक्रार मोजून आल्यास किंवा वेगापेक्षा failover आवश्यक असल्यास दुसरे location जोडा.

Frankfurt मध्ये hosting केल्याने माझा प्रकल्प GDPR-compliant होतो का?

नाही. GDPR कोणाचा personal data तुम्ही process करता आणि तुम्ही कुठे established आहात यावर लागू होतो; सर्व्हर कुठे आहे यावर नाही. EU मध्ये hosting केल्याने त्या hop साठी international transfer चा प्रश्न दूर होतो. ही एक वास्तविक सुलभता आहे आणि त्यातून मिळणारा पूर्ण लाभ एवढाच आहे. तरीही तुम्हाला lawful basis, data subject rights ची कार्यक्षम अंमलबजावणी, retention limit, security measures, 72 तासांच्या आत breach reporting आणि provider सोबत processor agreement आवश्यक आहे. Germany मध्ये याला AVV म्हणतात. ही सामान्य माहिती आहे, कायदेशीर सल्ला नाही.

Frankfurt आणि Berlin दरम्यान किती latency अपेक्षित आहे?

ही दोन शहरे 424 km अंतरावर आहेत. त्यामुळे round-trip time साठी 4.2 ms हा सैद्धांतिक किमान विलंब ठरतो. चांगल्या peering असलेल्या path वर सामान्यतः या किमान मूल्याच्या 1.5 ते 2 पट मोजमाप येते. Berlin मधील connection वरून ping -c 20 your-server.example.com वापरून हे तपासा आणि rtt min/avg/max/mdev line मधील avg value वाचा. हे range बरेच ओलांडणारा result साधारणपणे traffic Germany मधून बाहेर जाऊन पुन्हा परत आल्याचे दर्शवतो. Hop names मध्ये mtr -rwzc 50 हे तुम्हाला दाखवेल.

माझ्या Frankfurt सर्व्हरचा timezone Europe/Berlin ठेवावा का?

सामान्यतः नाही. System UTC वर ठेवा, जेणेकरून logs ची तुलना करता येईल आणि कोणताही timestamp संदिग्ध राहणार नाही. Germany मध्ये spring मध्ये CEST आणि autumn मध्ये पुन्हा CET लागू होते. Autumn मधील त्या रात्री एक local hour दोनदा येतो. त्यामुळे दोन वेगवेगळ्या events वर समान local timestamp लागू होऊ शकतो. तुमच्या application मध्ये, आवश्यक context उपलब्ध असताना, वेळा local zone मध्ये format करा. संपूर्ण box local time वर ठेवायचा असल्यास sudo timedatectl set-timezone Europe/Berlin चालवा आणि timedatectl वापरून पडताळा.

IPv4-only सर्व्हर German visitors साठी समस्या ठरेल का?

तो कार्य करेल, पण काही visitors साठी तो धीमा असेल. अनेक German ISPs consumer connections साठी public IPv4 address नसलेले DS-Lite setup देतात. त्यामुळे हे customers carrier च्या translation gateway द्वारे IPv4-only सर्व्हरपर्यंत पोहोचतात. यामुळे latency वाढते आणि व्यस्त वेळेत congestion होते. AAAA record प्रकाशित करून IPv6 वर listen केल्यास त्यांना direct path मिळतो. dig AAAA your-server.example.com +short आणि curl -6 request वापरून चाचणी करा. दोन्ही address families कडून HTTP 200 मिळणे अपेक्षित आहे.