🥇अपना सीडीएन बनाना और कॉन्फ़िगर करना

सामग्री वितरण नेटवर्क (सीडीएन) का उपयोग मुख्य रूप से स्थिर तत्वों की लोडिंग को तेज करने के लिए वेबसाइटों और अनुप्रयोगों में किया जाता है। ऐसा विभिन्न भौगोलिक क्षेत्रों में स्थित CDN सर्वरों पर फ़ाइलों की कैशिंग के कारण होता है। CDN के माध्यम से डेटा का अनुरोध करके, उपयोगकर्ता इसे निकटतम सर्वर से प्राप्त करता है।

सभी सामग्री वितरण नेटवर्क के संचालन और कार्यक्षमता का सिद्धांत लगभग समान है। किसी फ़ाइल को डाउनलोड करने का अनुरोध प्राप्त होने पर, सीडीएन सर्वर इसे मूल सर्वर से एक बार लेता है और उपयोगकर्ता को देता है, साथ ही इसे एक निर्दिष्ट अवधि के लिए कैशिंग करता है। बाद के सभी अनुरोधों का उत्तर कैश से दिया जाता है। सभी सीडीएन में फ़ाइलों को प्रीलोड करने, कैश साफ़ करने, समाप्ति तिथि निर्धारित करने और बहुत कुछ करने के विकल्प होते हैं।

ऐसा होता है कि, किसी कारण या किसी अन्य कारण से, आपको अपना स्वयं का सामग्री वितरण नेटवर्क व्यवस्थित करने की आवश्यकता होती है, और फिर - अगली बाइक को असेंबल करने के निर्देश हमारे लिए सहायक होते हैं।

स्रोत: पिकीसुपरस्टार द्वारा निर्मित इन्फोग्राफिक वेक्टर - www.freepik.com

जब आपको अपने स्वयं के CDN की आवश्यकता हो

उन मामलों पर विचार करें जहां अपना स्वयं का सीडीएन चलाना समझ में आता है:

जब पैसे बचाने की इच्छा हो, और सस्ते CDN जैसे उपयोग करने पर भी खर्च चलाने की इच्छा हो बनीसीडीएन प्रति माह कई सौ डॉलर की राशि
यदि हम एक स्थायी कैश या सर्वर और चैनल पड़ोसियों के बिना कैश प्राप्त करना चाहते हैं
सीडीएन सेवाओं के पास आपके आवश्यक क्षेत्र में उपस्थिति के बिंदु नहीं हैं
किसी विशेष सामग्री वितरण सेटिंग की आवश्यकता है
हम उत्पादन सर्वर को उपयोगकर्ताओं के करीब रखकर गतिशील सामग्री की डिलीवरी में तेजी लाना चाहते हैं
ऐसी चिंता है कि कोई तृतीय-पक्ष सीडीएन सेवा अवैध रूप से उपयोगकर्ता के व्यवहार (हैलो गैर-जीडीपीआर-अनुपालक सेवाओं) के बारे में जानकारी एकत्र या उपयोग कर सकती है या अन्य अवैध गतिविधियों में संलग्न हो सकती है

अधिकांश अन्य मामलों में, मौजूदा तैयार समाधानों का उपयोग करना अधिक उपयुक्त है।

आपको शुरुआत करने की क्या जरूरत है

यदि आपके पास अपनी स्वयं की स्वायत्त प्रणाली (एएस) है तो यह अद्भुत है। इसके साथ, आप एक ही आईपी को कई सर्वरों को असाइन कर सकते हैं इस निर्देश के अनुसार नेटवर्क स्तर पर, उपयोगकर्ताओं को निकटतम नेटवर्क पर निर्देशित करें। यह कहने लायक है कि /24 एड्रेस ब्लॉक के साथ भी, सामग्री वितरण नेटवर्क बनाना संभव है। कुछ सर्वर प्रदाता आपको उनके लिए उपलब्ध सभी क्षेत्रों में उपयोग के लिए एक घोषणा करने की अनुमति देते हैं।

यदि आप आईपी पते के ब्लॉक के खुश मालिक नहीं हैं, तो एक साधारण सीडीएन चलाने के लिए आपको इसकी आवश्यकता होगी:

डोमेन नाम या उपडोमेन
विभिन्न क्षेत्रों में कम से कम दो सर्वर। सर्वर या तो समर्पित या वर्चुअल हो सकता है
जियोडीएनएस उपकरण। इसके साथ, उपयोगकर्ता, डोमेन को संबोधित करने के बाद, निकटतम सर्वर पर निर्देशित किया जाएगा

एक डोमेन पंजीकृत करें और सर्वर ऑर्डर करें

डोमेन पंजीकरण के साथ, सब कुछ सरल है - हम किसी भी क्षेत्र में किसी भी रजिस्ट्रार के साथ पंजीकरण करते हैं। आप सीडीएन के लिए एक उपडोमेन का भी उपयोग कर सकते हैं, उदाहरण के लिए कुछ इस तरह cdn.domainname.com. दरअसल, हमारे उदाहरण में, हम बस यही करेंगे।

जहां तक सर्वर ऑर्डर करने की बात है, उन्हें उन क्षेत्रों और देशों में किराए पर लिया जाना चाहिए जहां आपके उपयोगकर्ता दर्शक स्थित हैं। यदि परियोजना अंतरमहाद्वीपीय है, तो ऐसे होस्टिंग प्रदाताओं को चुनना सुविधाजनक है जो एक ही बार में पूरी दुनिया में सर्वर प्रदान करते हैं। उदाहरण: OVH, लीज़वेब и 100TB - समर्पित सर्वर के लिए, Vultr и DigitalOcean - वर्चुअल क्लाउड* के लिए।

अपने निजी सीडीएन के लिए, हम विभिन्न महाद्वीपों पर 3 वर्चुअल सर्वर ऑर्डर करेंगे। पर Vultr के लिए सर्वर पर $5/माह हमें मिल जाएगा 25GB एसएसडी स्थान और यातायात का 1TB. इंस्टॉल करते समय, नवीनतम डेबियन का चयन करें। हमारे सर्वर:

फ़्रंकफ़र्ट, आईपी: 199.247.18.199

शिकागो, आईपी: 149.28.121.123

सिंगापुर, आईपी: 157.230.240.216

* Vultr और DigitalOcean भुगतान विधि जोड़ने के तुरंत बाद लेख में लिंक के माध्यम से पंजीकरण करने वाले उपयोगकर्ताओं को $100 क्रेडिट का वादा करते हैं। इससे लेखक को एक छोटी सी सराहना भी मिलती है, जो अब उसके लिए बहुत महत्वपूर्ण है। कृपया समझें.

जियोडीएनएस की स्थापना

किसी डोमेन या सीडीएन उपडोमेन तक पहुंचने पर उपयोगकर्ता को वांछित (निकटतम) सर्वर पर निर्देशित करने के लिए, हमें जियोडीएनएस फ़ंक्शन के साथ एक डीएनएस सर्वर की आवश्यकता होती है।

जियोडीएनएस का सिद्धांत और संचालन इस प्रकार है:

उस क्लाइंट का आईपी निर्दिष्ट करता है जिसने DNS अनुरोध भेजा है, या पुनरावर्ती DNS सर्वर का आईपी निर्दिष्ट करता है जिसका उपयोग क्लाइंट अनुरोध को संसाधित करते समय किया जाता है। ऐसे पुनरावर्ती सर्वर आमतौर पर प्रदाताओं के DNS-s होते हैं।
ग्राहक का आईपी उसके देश या क्षेत्र को पहचानता है। इसके लिए, जियोआईपी डेटाबेस का उपयोग किया जाता है, जिनमें से आज बहुत सारे हैं। अच्छे हैं मुफ्त विकल्प.
क्लाइंट के स्थान के आधार पर, उसे निकटतम CDN सर्वर का IP पता देता है।

जियोडीएनएस फ़ंक्शन वाला डीएनएस सर्वर हो सकता है अपने आप से इकट्ठा करो, लेकिन दुनिया भर में DNS सर्वरों के नेटवर्क के साथ तैयार समाधानों का उपयोग करना बेहतर है एनीकास्ट डिब्बे से:

क्लाउडडीएनएस से $9.95/माह, जियोडीएनएस टैरिफ, डिफ़ॉल्ट रूप से एक डीएनएस फेलओवर है
ज़िलोर से $25/माह, डीएनएस फ़ेलओवर सक्षम
अमेज़ॅन रूट 53 से $35/माह शुद्ध 50एम भू-अनुरोधों के लिए। DNS विफलता का बिल अलग से लिया जाता है
डीएनएस मेड ईज़ी से $125/माह, 10 DNS फ़ेलओवर हैं
CloudFlare, एंटरप्राइज़ योजनाओं में "जियो स्टीयरिंग" सुविधा उपलब्ध है

जियोडीएनएस ऑर्डर करते समय, आपको टैरिफ में शामिल अनुरोधों की संख्या पर ध्यान देना चाहिए और ध्यान रखना चाहिए कि डोमेन के लिए अनुरोधों की वास्तविक संख्या अपेक्षाओं से कई गुना अधिक हो सकती है। लाखों मकड़ियाँ, स्कैनर, स्पैमर और अन्य बुरी आत्माएँ अथक परिश्रम करती हैं।

लगभग सभी DNS सेवाओं में CDN बनाने के लिए एक अनिवार्य सेवा शामिल होती है - DNS फ़ेलओवर। इसकी मदद से, आप अपने सर्वर के संचालन की निगरानी स्थापित कर सकते हैं और, जीवन के संकेतों की अनुपस्थिति में, DNS प्रतिक्रियाओं में स्वचालित रूप से एक गैर-कार्यशील सर्वर के पते को बैकअप के साथ बदल सकते हैं।

अपना CDN बनाने के लिए, हम इसका उपयोग करेंगे बादलों, जियोडीएनएस टैरिफ।

आइए आपके डोमेन को निर्दिष्ट करते हुए, आपके व्यक्तिगत खाते में एक नया DNS ज़ोन जोड़ें। यदि हम किसी उपडोमेन पर CDN बना रहे हैं, और मुख्य डोमेन पहले से ही उपयोग में है, तो ज़ोन जोड़ने के तुरंत बाद, मौजूदा कार्यशील DNS रिकॉर्ड जोड़ना न भूलें। अगला कदम सीडीएन डोमेन/उपडोमेन के लिए कई ए-रिकॉर्ड बनाना है, जिनमें से प्रत्येक हमारे द्वारा निर्दिष्ट क्षेत्र पर लागू किया जाएगा। आप महाद्वीपों या देशों को क्षेत्रों के रूप में निर्दिष्ट कर सकते हैं, उप-क्षेत्र संयुक्त राज्य अमेरिका और कनाडा के लिए उपलब्ध हैं।

हमारे मामले में, सीडीएन को एक उपडोमेन पर उठाया जाएगा cdn.sayt.in. एक ज़ोन जोड़कर sait.in, उपडोमेन के लिए पहला ए-रिकॉर्ड बनाएं और पूरे उत्तरी अमेरिका को शिकागो में सर्वर पर इंगित करें:

आइए अन्य क्षेत्रों के लिए कार्रवाई दोहराएं, डिफ़ॉल्ट क्षेत्रों के लिए एक प्रविष्टि बनाना याद रखें। यहाँ अंत में क्या होता है:

स्क्रीनशॉट में अंतिम डिफ़ॉल्ट प्रविष्टि का अर्थ है कि सभी अनिर्दिष्ट क्षेत्र (और ये यूरोप, अफ्रीका, उपग्रह इंटरनेट उपयोगकर्ता, आदि हैं) फ्रैंकफर्ट में सर्वर पर भेजे जाएंगे।

यह मूल DNS सेटअप को पूरा करता है। डोमेन रजिस्ट्रार की वेबसाइट पर जाना और मौजूदा डोमेन एनएस को क्लॉउडीएनएस द्वारा जारी किए गए डोमेन एनएस से बदलना बाकी है। और जब एनएस अपडेट किया जाएगा, हम सर्वर तैयार करेंगे।

एसएसएल प्रमाणपत्रों की स्थापना

हमारा सीडीएन HTTPS पर काम करेगा, इसलिए यदि आपके पास पहले से ही किसी डोमेन या उपडोमेन के लिए एसएसएल प्रमाणपत्र हैं, तो उन्हें सभी सर्वरों पर अपलोड करें, उदाहरण के लिए, निर्देशिका में /etc/ssl/yourdomain/

यदि कोई प्रमाणपत्र नहीं है, तो आप लेट्स एनक्रिप्ट से निःशुल्क प्रमाणपत्र प्राप्त कर सकते हैं। इसके लिए बिल्कुल सही एसीएमई शैलस्क्रिप्ट. क्लाइंट सुविधाजनक और सेट अप करने में आसान है, और सबसे महत्वपूर्ण बात यह है कि यह आपको ClouDNS API के माध्यम से DNS द्वारा एक डोमेन/उपडोमेन को मान्य करने की अनुमति देता है।

हम acme.sh को केवल एक सर्वर - यूरोपीय 199.247.18.199 पर स्थापित करेंगे, जिससे प्रमाणपत्र अन्य सभी पर कॉपी किए जाएंगे। स्थापित करने के लिए, चलाएँ:

root@cdn:~# wget -O - https://get.acme.sh | bash; source ~/.bashrc

स्क्रिप्ट की स्थापना के दौरान, हमारी भागीदारी के बिना प्रमाणपत्रों के आगे नवीनीकरण के लिए एक CRON जॉब बनाई जाएगी।

प्रमाणपत्र जारी करते समय, डोमेन को एपीआई का उपयोग करके डीएनएस का उपयोग करके जांचा जाएगा, इसलिए पुनर्विक्रेता एपीआई मेनू में क्लॉउडीएनएस व्यक्तिगत खाते में, आपको एक नया उपयोगकर्ता एपीआई बनाना होगा और इसके लिए एक पासवर्ड सेट करना होगा। पासवर्ड के साथ परिणामी ऑथ-आईडी फ़ाइल में लिखी जाएगी ~/.acme.sh/dnsapi/dns_cloudns.sh (फ़ाइल के साथ भ्रमित न हों dns_clouddns.sh). यहां वे पंक्तियाँ हैं जिन पर टिप्पणी न करने और संपादित करने की आवश्यकता है:

CLOUDNS_AUTH_ID=<auth-id>
CLOUDNS_AUTH_PASSWORD="<пароль>"

अब हम इसके लिए SSL प्रमाणपत्र का अनुरोध करेंगे cdn.sayt.in

root@cdn:~# acme.sh --issue --dns dns_cloudns -d cdn.sayt.in --reloadcmd "service nginx reload"

भविष्य के लिए विकल्पों में, हमने भविष्य में प्रमाणपत्र वैधता अवधि के प्रत्येक नवीनीकरण के बाद वेब सर्वर कॉन्फ़िगरेशन को स्वचालित रूप से पुनः लोड करने के लिए एक कमांड निर्दिष्ट किया है।

प्रमाणपत्र प्राप्त करने की पूरी प्रक्रिया में 2 मिनट तक का समय लग सकता है, इसे बाधित न करें। यदि कोई डोमेन सत्यापन त्रुटि होती है, तो कमांड को फिर से चलाने का प्रयास करें। अंत में हम देखेंगे कि प्रमाणपत्र कहाँ अपलोड किए गए हैं:

इन पथों को याद रखें, प्रमाणपत्र को अन्य सर्वरों के साथ-साथ वेब सर्वर सेटिंग्स में कॉपी करते समय उन्हें निर्दिष्ट करने की आवश्यकता होगी। हम Nginx कॉन्फ़िगरेशन को पुनः लोड करने की त्रुटि पर ध्यान नहीं देते हैं - प्रमाणपत्र अपडेट करते समय यह पूरी तरह से कॉन्फ़िगर सर्वर पर नहीं होगा।

एसएसएल के लिए हमारे पास जो कुछ बचा है वह फाइलों के पथ को बनाए रखते हुए प्राप्त प्रमाणपत्र को दो अन्य सर्वरों पर कॉपी करना है। आइए उनमें से प्रत्येक पर समान निर्देशिकाएँ बनाएँ और एक प्रतिलिपि बनाएँ:

root@cdn:~# mkdir -p /root/.acme.sh/cdn.sayt.in/
root@cdn:~# scp -r [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/

प्रमाणपत्रों को नियमित रूप से अपडेट करने के लिए, कमांड के साथ दोनों सर्वरों पर दैनिक CRON जॉब बनाएं:

scp -r [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload

इस स्थिति में, दूरस्थ स्रोत सर्वर तक पहुंच कॉन्फ़िगर की जानी चाहिए कुंजी द्वारा, अर्थात। बिना पासवर्ड डाले. इसे करना न भूलें.

Nginx को स्थापित और कॉन्फ़िगर करना

स्थिर सामग्री परोसने के लिए, हम कैशिंग प्रॉक्सी सर्वर के रूप में कॉन्फ़िगर किए गए Nginx का उपयोग करेंगे। पैकेज सूचियों को अद्यतन करें और इसे तीनों सर्वरों पर स्थापित करें:

root@cdn:~# apt update
root@cdn:~# apt install nginx

डिफ़ॉल्ट के बजाय, हम नीचे दिए गए स्पॉइलर से कॉन्फ़िगरेशन का उपयोग करते हैं:
nginx.conf

user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {
    worker_connections 4096;
    multi_accept on;
}

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    types_hash_max_size 2048;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    access_log off;
    error_log /var/log/nginx/error.log;

    gzip on;
    gzip_disable "msie6";
    gzip_comp_level 6;
    gzip_proxied any;
    gzip_vary on;
    gzip_types text/plain application/javascript text/javascript text/css application/json application/xml text/xml application/rss+xml;
    gunzip on;            

    proxy_temp_path    /var/cache/tmp;
    proxy_cache_path   /var/cache/cdn levels=1:2 keys_zone=cdn:64m max_size=20g inactive=7d;
    proxy_cache_bypass $http_x_update;

server {
  listen 443 ssl;
  server_name cdn.sayt.in;

  ssl_certificate /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.cer;
  ssl_certificate_key /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.key;

  location / {
    proxy_cache cdn;
    proxy_cache_key $uri$is_args$args;
    proxy_cache_valid 90d;
    proxy_pass https://sayt.in;
    }
  }
}

कॉन्फिग में संपादित करें:

अधिकतम आकार - कैश का आकार, उपलब्ध डिस्क स्थान से अधिक नहीं
निष्क्रिय - कैश्ड डेटा का भंडारण समय जिसे किसी ने एक्सेस नहीं किया
ssl_certificate и ssl_certificate_key - एसएसएल प्रमाणपत्र और मुख्य फ़ाइलों के लिए पथ
प्रॉक्सी_कैश_मान्य - कैश्ड डेटा का भंडारण समय
प्रॉक्सी_पास - मूल सर्वर का पता जिससे सीडीएन कैशिंग के लिए फाइलों का अनुरोध करेगा। हमारे उदाहरण में, यह sait.in

जैसा कि आप देख सकते हैं, सब कुछ सरल है। निर्देशों की समानता के कारण ही कैशिंग समय निर्धारित करने में कठिनाई उत्पन्न हो सकती है निष्क्रिय и प्रॉक्सी_कैश_मान्य. आइए अपने उदाहरण से उनका विश्लेषण करें। यहां बताया गया है कि कब क्या होता है निष्क्रिय=7 दिन и प्रॉक्सी_कैश_वैध 90डी:

यदि अनुरोध 7 दिनों के भीतर दोहराया नहीं जाता है, तो इस अवधि के बाद डेटा कैश से हटा दिया जाएगा
यदि अनुरोध हर 7 दिनों में कम से कम एक बार दोहराया जाता है, तो कैश में डेटा 90 दिनों के बाद अप्रचलित माना जाएगा और Nginx इसे मूल सर्वर से लेकर अगले अनुरोध के साथ अपडेट कर देगा।

संपादित करना समाप्त हुआ nginx.conf, कॉन्फ़िगरेशन पुनः लोड करें:

root@cdn:~# service nginx reload

हमारा CDN तैयार है. $15/महीना के लिए. हमें तीन महाद्वीपों पर उपस्थिति के बिंदु और 3 टीबी ट्रैफ़िक प्राप्त हुआ: प्रत्येक स्थान पर 1 टीबी।

सीडीएन के कार्य की जाँच करना

आइए विभिन्न भौगोलिक स्थानों से हमारे सीडीएन के पिंग को देखें। इसके लिए कोई भी पिंग सेवा काम करेगी.

प्रक्षेपण बिंदु
मेज़बान
IP
औसत समय, एमएस

जर्मनी बर्लिन
cdn.sayt.in
199.247.18.199
9.6

नीदरलैंड, एम्सटर्डम
cdn.sayt.in
199.247.18.199
10.1

फ़्रांस पेरिस
cdn.sayt.in
199.247.18.199
16.3

ग्रेट ब्रिटेन, लंदन
cdn.sayt.in
199.247.18.199
14.9

कनाडा, टोरंटो
cdn.sayt.in
149.28.121.123
16.2

यूएसए, सैन फ्रांसिस्को
cdn.sayt.in
149.28.121.123
52.7

यूएसए, डलास
cdn.sayt.in
149.28.121.123
23.1

यूएसए, शिकागो
cdn.sayt.in
149.28.121.123
2.6

यूएसए, न्यूयॉर्क
cdn.sayt.in
149.28.121.123
19.8

सिंगापुर
cdn.sayt.in
157.230.240.216
1.7

जापान टोक्यो
cdn.sayt.in
157.230.240.216
74.8

ऑस्ट्रेलिया, सिडनी
cdn.sayt.in
157.230.240.216
95.9

नतीजे अच्छे हैं. अब हम मुख्य साइट के मूल में एक परीक्षण छवि रखेंगे test.jpg और सीडीएन के माध्यम से इसकी डाउनलोड गति जांचें। यह कहा जाता है - किया. सामग्री शीघ्र वितरित की जाती है.

यदि हम सीडीएन बिंदु पर कैश साफ़ करना चाहते हैं तो आइए एक छोटी सी स्क्रिप्ट लिखें।
पर्ज.श

#!/bin/bash
if [ -z "$1" ]
then
    echo "Purging all cache"
    rm -rf /var/cache/cdn/*
else
    echo "Purging $1"
    FILE=`echo -n "$1" | md5sum | awk '{print $1}'`
    FULLPATH=/var/cache/cdn/${FILE:31:1}/${FILE:29:2}/${FILE}
    rm -f "${FULLPATH}"
fi

संपूर्ण कैश को हटाने के लिए, बस इसे चलाएं, एक अलग फ़ाइल को इस तरह साफ़ किया जा सकता है:

root@cdn:~# ./purge.sh /test.jpg

निष्कर्ष के बजाय

अंत में, मैं उस रेक पर तुरंत कदम रखने के लिए कुछ उपयोगी सुझाव देना चाहता हूं जिससे उस समय मेरे सिर में चोट लगी थी:

सीडीएन की दोष सहनशीलता को बढ़ाने के लिए, डीएनएस फेलओवर को कॉन्फ़िगर करने की अनुशंसा की जाती है, जो सर्वर ब्रेकडाउन की स्थिति में ए रिकॉर्ड को तुरंत बदलने में मदद करता है। यह डोमेन के नियंत्रण कक्ष DNS रिकॉर्ड में किया जाता है।
इसमें कोई संदेह नहीं कि व्यापक भौगोलिक कवरेज वाली साइटों को बड़ी संख्या में सीडीएन की आवश्यकता होती है, लेकिन आइए कट्टर न बनें। यदि आप 6-7 स्थानों पर सर्वर रखते हैं: यूरोप, उत्तरी अमेरिका (पूर्व), उत्तरी अमेरिका (पश्चिम), सिंगापुर, ऑस्ट्रेलिया, हांगकांग या जापान: तो सबसे अधिक संभावना है कि उपयोगकर्ता को भुगतान किए गए सीडीएन की तुलना में कोई महत्वपूर्ण अंतर नज़र नहीं आएगा।
कभी-कभी होस्टर्स सीडीएन उद्देश्यों के लिए किराए के सर्वर के उपयोग की अनुमति नहीं देते हैं। इसलिए, यदि आप अचानक एक सामग्री वितरण नेटवर्क को एक सेवा के रूप में तैनात करने का निर्णय लेते हैं, तो किसी विशेष होस्टिंग प्रदाता के नियमों को पहले से पढ़ना न भूलें
अन्वेषण पानी के नीचे संचार मानचित्रयह दर्शाने के लिए कि महाद्वीप कैसे जुड़े हुए हैं और सामग्री वितरण नेटवर्क बनाते समय इसे ध्यान में रखें
जाँचने का प्रयास करें विभिन्न स्थानों से पिंग आपके सर्वर पर. इस तरह आप सीडीएन बिंदुओं के निकटतम क्षेत्रों को देख सकते हैं और जियोडीएनएस को अधिक सही ढंग से कॉन्फ़िगर कर सकते हैं
कार्यों के आधार पर, विशिष्ट कैशिंग आवश्यकताओं और सर्वर पर लोड को ध्यान में रखते हुए Nginx को फाइन-ट्यून करना उपयोगी होगा। Nginx कैश के बारे में लेखों ने इसमें मेरी बहुत मदद की - यहां और भारी भार के तहत काम का त्वरण: यहां и यहां

स्रोत: www.habr.com