Nginx कैश: सब कुछ नया - पुराना भूल गया

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

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

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

Nginx कैश क्या है और यह कैसे काम करता है?

Nginx कैश बैकएंड के लिए अनुरोधों की संख्या को काफी कम कर सकता है। यह एक निश्चित समय के लिए HTTP प्रतिक्रिया को सहेजने के द्वारा प्राप्त किया जाता है, और संसाधन को फिर से एक्सेस करते समय, बैकएंड के लिए अनुरोध के बिना कैश से इसे वापस करता है। कैशिंग, यहां तक ​​कि छोटी अवधि के लिए, सर्वर द्वारा संसाधित अनुरोधों की संख्या में उल्लेखनीय वृद्धि करेगा।

नगनेक्स के कॉन्फ़िगरेशन के साथ आगे बढ़ने से पहले, आपको यह सुनिश्चित करने की आवश्यकता है कि यह "ngx_http_proxy_module" मॉड्यूल के साथ बनाया गया है, क्योंकि हम इस मॉड्यूल का उपयोग करके इसे कॉन्फ़िगर करेंगे।

सुविधा के लिए, आप कॉन्फ़िगरेशन को एक अलग फ़ाइल में रख सकते हैं, उदाहरण के लिए, "/etc/nginx/conf.d/cache.conf"। आइए प्रॉक्सी_कैचे_पथ निर्देश को देखें, जो आपको कैश स्टोरेज सेटिंग्स को कॉन्फ़िगर करने की अनुमति देता है।

proxy_cache_path /var/lib/nginx/proxy_cache levels=1:2 keys_zone=proxy_cache:15m max_size=1G; 

"/ वार / लीब / nginx /xy_cache" सर्वर पर कैश संग्रहण पथ निर्दिष्ट करता है। यह इस निर्देशिका में है कि nginx बैकएंड से प्रतिक्रिया के साथ बहुत फ़ाइलों को बचाएगा। उसी समय, नग्नेक्स स्वतंत्र रूप से कैश के लिए एक निर्देशिका नहीं बनाएगा, आपको इस बात का ध्यान रखना होगा।

"स्तर = 1: 2" - निर्देशिका के स्तर को कैश के साथ सेट करता है। घोंसले का स्तर ":" के माध्यम से इंगित किया जाता है, इस मामले में 2 निर्देशिकाएं बनाई जाएंगी, कुल 3 घोंसले के स्तर अनुमेय हैं। प्रत्येक घोंसले के स्तर के लिए, 1 से 2 तक मान उपलब्ध हैं, यह दर्शाता है कि निर्देशिका नाम कैसे बनाया जाए।

महत्वपूर्ण बिंदु यह है कि निर्देशिका नाम यादृच्छिक रूप से नहीं चुना गया है, लेकिन फ़ाइल नाम के आधार पर बनाया गया है। फ़ाइल नाम, बदले में, कैश कुंजी से md5 फ़ंक्शन का परिणाम है; हम कैश कुंजी को थोड़ी देर बाद देखेंगे।

आइए व्यवहार में देखें कि कैश फ़ाइल का मार्ग कैसे बनाया जाता है:

 /var/lib/nginx/proxy_cache/2/49/07edcfe6974569ab4da6634ad4e5d492 

"Keys_zone =xy_cache: 15m" पैरामीटर साझा मेमोरी में ज़ोन का नाम सेट करता है, जहां सभी सक्रिय कुंजी और उन पर जानकारी संग्रहीत की जाती है। "के माध्यम से:" एमबी में आवंटित स्मृति के आकार को इंगित करता है। नगीनेक्स के अनुसार, 1 एमबी 8 हजार कुंजी स्टोर करने के लिए पर्याप्त है।

"Max_size = 1G" ऊपर के सभी पृष्ठों के लिए अधिकतम कैश आकार को परिभाषित करता है, जिसमें nginx कम आवश्यक डेटा को हटाने का ध्यान रखेगा।

कैश में डेटा के जीवनकाल को नियंत्रित करना भी संभव है, इसके लिए "प्रॉक्सी_कैच_पैथ" निर्देश के "निष्क्रिय" पैरामीटर को परिभाषित करने के लिए पर्याप्त है, जो डिफ़ॉल्ट रूप से 10 मिनट है। यदि "निष्क्रिय" पैरामीटर में निर्दिष्ट समय के दौरान कैश डेटा के लिए कोई कॉल नहीं थे, तो यह डेटा हटा दिया जाता है, भले ही कैश "खट्टा" न हो।

यह कैसा कैश है? यह वास्तव में सर्वर पर एक नियमित फ़ाइल है, जिसकी सामग्री लिखी गई है:

• कैश कुंजी;
• कैश हेडर;
• बैकएंड से सामग्री की प्रतिक्रिया।

यदि हेडर और बैकएंड से प्रतिक्रिया के साथ सब कुछ स्पष्ट है, तो "कैश कुंजी" के लिए कई प्रश्न हैं। यह कैसे बनाया जाता है और इसे कैसे प्रबंधित किया जा सकता है?

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

उदाहरण के लिए:

 proxy_cache_key $request_method$host$orig_uri:$cookie_some_cookie:$arg_some_arg; 

कुकी पैरामीटर के बीच ":" प्रतीक और प्राप्त पैरामीटर का उपयोग कैश कुंजियों के बीच टकराव को रोकने के लिए किया जाता है, आप अपनी पसंद का कोई अन्य प्रतीक चुन सकते हैं। डिफ़ॉल्ट रूप से, nginx कुंजी बनाने के लिए निम्नलिखित लाइन का उपयोग करता है:

 proxy_cache_key $scheme$proxy_host$request_uri; 

निम्नलिखित निर्देशों पर ध्यान दिया जाना चाहिए जो आपको अपने कैशिंग को अधिक लचीले ढंग से प्रबंधित करने में मदद करेंगे:

xy_cache_valid - प्रतिक्रिया कैशिंग समय निर्दिष्ट करता है। प्रतिक्रिया की विशिष्ट स्थिति को इंगित करना संभव है, उदाहरण के लिए 200, 302, 404, आदि, या "किसी भी" निर्माण का उपयोग करके एक बार में सब कुछ निर्दिष्ट करने के लिए। यदि केवल कैशिंग समय निर्दिष्ट है, तो nginx केवल 200, 301 और 302 स्थितियों को कैश करने के लिए डिफ़ॉल्ट होगा।

एक उदाहरण:

 proxy_cache_valid 15m; proxy_cache_valid 404 15s; 

इस उदाहरण में, हमने कैश जीवनकाल को 200, 301, 302 के लिए 15 मिनट के लिए निर्धारित किया है (nginx उन्हें डिफ़ॉल्ट रूप से उपयोग करता है, क्योंकि हमने एक विशिष्ट स्थिति निर्दिष्ट नहीं की थी)। अगली पंक्ति ने कैशिंग का समय 15 सेकंड तक निर्धारित किया, केवल 404 की स्थिति के साथ प्रतिक्रियाओं के लिए।

xy_cache_lock - यह निर्देश कैश के एक सेट के तुरंत बाद बैकएंड पर कई पास से बचने में मदद करेगा, बस "ऑन" स्थिति में मान सेट करें। अन्य सभी अनुरोध कैश में प्रतिक्रिया के लिए प्रतीक्षा करेंगे, या पृष्ठ पर अनुरोध को अवरुद्ध करने के लिए एक समयसीमा। तदनुसार, सभी टाइमआउट कॉन्फ़िगर किए जा सकते हैं।

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

प्रॉक्सी_कैशे_लॉक_टाइम - लॉक का इंतजार करने का समय निर्धारित करता है, जिसके बाद बैकएंड पर अनुरोध भेजा जाएगा, लेकिन प्रतिक्रिया को कैश नहीं किया जाएगा। डिफ़ॉल्ट 5 सेकंड है।

xy_cache_use_stale - एक अन्य उपयोगी निर्देश जो आपको अप्रचलित कैश का उपयोग करने के लिए संभव होने पर कॉन्फ़िगर करने की अनुमति देता है।

एक उदाहरण:

 proxy_cache_use_stale error timeout updating; 

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

xy_cache_bypass - उन शर्तों को निर्दिष्ट करता है जिनके तहत nginx कैश से प्रतिक्रिया नहीं लेगा, लेकिन बैकएंड के अनुरोध को तुरंत रीडायरेक्ट करेगा। यदि कम से कम एक पैरामीटर खाली नहीं है और "0" के बराबर नहीं है। एक उदाहरण:

 proxy_cache_bypass $cookie_nocache $arg_nocache; 

xy_no_cache - वह स्थिति सेट करता है जिसके तहत nginx बैकएंड से कैश पर प्रतिक्रिया को नहीं बचाएगा। ऑपरेशन का सिद्धांत प्रॉक्सी_केच_बिपास निर्देश के समान है।

पेज कैशिंग के साथ संभावित समस्याएं

जैसा कि ऊपर उल्लेख किया गया है, एक HTTP प्रतिक्रिया को कैशिंग के साथ-साथ, nginx बैकएंड से प्राप्त हेडर बचाता है। यदि आपकी साइट एक सत्र का उपयोग करती है, तो सत्र कुकी भी कैश की जाएगी। सभी उपयोगकर्ता जो उस पृष्ठ पर जाते हैं, जिसे आप कैश के लिए भाग्यशाली थे, सत्र में आपके व्यक्तिगत डेटा को संग्रहीत करेगा।

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

कुकी संरक्षण प्रबंधन

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

एक उदाहरण:

 proxy_ignore_headers "Set-Cookie"; 

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

आपको सत्र के जीवनकाल को भी ध्यान में रखना चाहिए, इसे php.ini कॉन्फ़िगरेशन के " session.gc_maxlifetime " पैरामीटर में देखा जा सकता है। कल्पना करें कि उपयोगकर्ता ने साइट पर लॉग इन किया और समाचार फ़ीड देखना शुरू कर दिया, सभी डेटा पहले से ही नगनेक्स कैश में है। कुछ समय बाद, उपयोगकर्ता ने नोटिस किया कि उसका प्राधिकरण गायब हो गया है और उसे फिर से प्राधिकरण प्रक्रिया से गुजरना होगा, हालांकि इस समय वह सभी साइट पर था, समाचार देख रहा था। ऐसा इसलिए हुआ क्योंकि इसके सभी अनुरोधों पर nginx ने बैकएंड पर अनुरोध भेजे बिना कैश से परिणाम लौटा दिया। इसलिए, बैकएंड ने निर्णय लिया कि उपयोगकर्ता निष्क्रिय था और " session.gc_maxlifetime " में निर्दिष्ट समय के बाद सत्र फ़ाइल को हटा दिया गया।

ऐसा होने से रोकने के लिए, हम बैकएंड अनुरोधों का अनुकरण कर सकते हैं। उदाहरण के लिए, अजाक्स के माध्यम से एक अनुरोध भेजें जो बैकएंड को पारित करने की गारंटी होगी। बैकएंड के लिए नगनेक्स कैश को पास करने के लिए, बस एक POST अनुरोध भेजें, आप "प्रॉक्सी_कैशे_बिपास" निर्देश से भी नियम का उपयोग कर सकते हैं, या बस इस पृष्ठ के लिए कैश को अक्षम कर सकते हैं। अनुरोध में कुछ वापस देने की आवश्यकता नहीं है, यह सत्र शुरू करने वाली एकल पंक्ति के साथ एक फ़ाइल हो सकती है। इस तरह के अनुरोध का उद्देश्य उपयोगकर्ता को साइट पर रहने के दौरान सत्र के जीवनकाल का विस्तार करना है, और nginx ईमानदारी से अपने सभी अनुरोधों को कैश्ड डेटा देता है।

कैश फ्लश प्रबंधन

पहले आपको आवश्यकताओं को निर्धारित करने की आवश्यकता है, हम किस लक्ष्य को प्राप्त करने की कोशिश कर रहे हैं। मान लीजिए कि हमारी साइट में लोकप्रिय खेल स्पर्धाओं के पाठ प्रसारण के साथ एक खंड है। जब पृष्ठ को लोड करना कैश से दिया जाता है, तो सभी नए संदेश सॉकेट पर आते हैं। उपयोगकर्ता को पहले बूट पर वर्तमान समय में वर्तमान संदेश देखने के लिए, बजाय 15 मिनट पहले, हमें किसी भी समय nginx कैश को स्वतंत्र रूप से साफ़ करने में सक्षम होने की आवश्यकता है। उसी समय, नगणक्स अनुप्रयोग के समान मशीन पर स्थित नहीं हो सकता है। इसके अलावा, एक रीसेट के लिए आवश्यकताओं में से एक एक बार में कई पृष्ठों में कैश को हटाने की क्षमता होगी।

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

 proxy_cache_path /data/nginx/cache keys_zone=cache_zone:10m; map $request_method $purge_method { PURGE 1; default 0; } server { ... location / { proxy_pass http://backend; proxy_cache cache_zone; proxy_cache_key $uri; proxy_cache_purge $purge_method; } } 

एक उदाहरण आधिकारिक nginx वेबसाइट से लिया गया है।

$ Purge_method वैरिएबल कैश फ्लश करने के लिए जिम्मेदार है, जो प्रॉक्सी_cache_purge निर्देश के लिए एक शर्त है और डिफ़ॉल्ट रूप से 0 पर सेट है। इसका मतलब है कि नगनेक्स "सामान्य" मोड में काम करता है (यह बैकएंड से प्रतिक्रियाओं को बचाता है)। लेकिन अगर आप अनुरोध विधि को "PURGE" में बदलते हैं, तो प्रतिक्रिया को सहेजने के साथ बैकएंड के लिए अनुरोध को अनुमानित करने के बजाय, कैश प्रविष्टि को उसी कैशिंग कुंजी का उपयोग करके हटा दिया जाएगा। कैश कुंजी के अंत में "*" निर्दिष्ट करके एक विलोपन मुखौटा निर्दिष्ट करना भी संभव है। इस प्रकार, हमें डिस्क पर कैश के स्थान और कुंजी गठन के सिद्धांत को जानने की आवश्यकता नहीं है, नग्नेक्स इन जिम्मेदारियों को लेता है। लेकिन इस दृष्टिकोण के नुकसान भी हैं।

• एक व्यावसायिक सदस्यता के भाग के रूप में छद्म_शेष_पुरुष निर्देश उपलब्ध है।
• केवल कैश पॉइंटवाइज़ को हटाना संभव है, या फॉर्म {कैश की}} * * के मास्क का उपयोग करके।

चूंकि कैश्ड पृष्ठों के पते पूरी तरह से अलग हो सकते हैं, सामान्य भागों के बिना, मुखौटा "*" के साथ दृष्टिकोण और निर्देश "प्रॉक्सी_कैशे_पुरेज" हमारे लिए उपयुक्त नहीं है। यह एक छोटे से सिद्धांत को याद करने और अपने पसंदीदा विचारधारा की खोज करने के लिए बनी हुई है।

हम जानते हैं कि nginx कैश सर्वर पर एक नियमित फ़ाइल है। हमने "प्रॉक्सी_कैश_पाथ" निर्देश में कैश फ़ाइलों को संग्रहीत करने के लिए स्वतंत्र रूप से निर्देशिका निर्दिष्ट की है, हमने "स्तर" का उपयोग करके इस निर्देशिका से फ़ाइल के लिए पथ बनाने के तर्क को भी निर्दिष्ट किया है। केवल एक चीज जो हमें याद आ रही है वह है कैशिंग कुंजी का सही गठन। लेकिन हम इसे "प्रॉक्सी_चे_की" निर्देश में भी देख सकते हैं। अब हमें बस इतना करना है:

• पृष्ठ पर पूर्ण पथ बनाएं, जैसा कि प्रॉक्सी_केचे_की निर्देश में निर्दिष्ट है;
• परिणामी स्ट्रिंग को md5 में एन्कोड करें;
• "स्तर" पैरामीटर से नियम का उपयोग करके नेस्टेड निर्देशिका बनाएं।
• और अब हमारे पास सर्वर पर कैश फ़ाइल के लिए पहले से ही पूरा रास्ता है। अब हमारे लिए यही सब कुछ इस फ़ाइल को हटाना है। परिचयात्मक भाग से, हम जानते हैं कि nginx एप्लिकेशन मशीन पर स्थित नहीं हो सकता है, इसलिए आपको एक ही बार में कई पते हटाने के लिए संभव बनाने की आवश्यकता है। फिर, हम एल्गोरिथ्म का वर्णन करते हैं:
• कैश फ़ाइलों के लिए उत्पन्न पथ हम फ़ाइल को लिखेंगे;
• आइए एक सरल बैश स्क्रिप्ट लिखें जिसे हमने एप्लिकेशन के साथ मशीन पर रखा है। उसका कार्य ssh के माध्यम से उस सर्वर से जुड़ना होगा जहां हमारे पास nginx कैशिंग है और चरण 1 से उत्पन्न फ़ाइल में निर्दिष्ट सभी कैश फ़ाइलों को हटा दें;

हम सिद्धांत से अभ्यास के लिए उत्तीर्ण होते हैं, हम अपने काम के एल्गोरिथ्म को दर्शाते हुए एक छोटा सा उदाहरण लिखेंगे।

चरण 1. कैश के लिए पथ के साथ एक फ़ाइल बनाना।

 $urls = [ 'httpGETdomain.ru/news/111/1:2', 'httpGETdomain.ru/news/112/3:4', ]; function to_nginx_cache_path(url) { $nginxHash = md5($url); $firstDir = substr($nginxHash, -1, 1); $secondDir = substr($nginxHash, -3, 2); return "/var/lib/nginx/proxy_cache/$firstDir/$secondDir/$nginxHash"; } //        tmp $filePath = tempnam('tmp', 'nginx_cache_'); //      $fileStream = fopen($filePath, 'a'); foreach ($urls as $url) { //      $cachePath = to_nginx_cache_path($url); //       fwrite($fileStream, $cachePath . PHP_EOL); } //     fclose($fileStream); //  bash       exec("/usr/local/bin/cache_remover $filePath"); 

कृपया ध्यान दें कि चर $ urls में कैश्ड पृष्ठों का url शामिल है, पहले से ही nginx config में निर्दिष्ट छद्म_cache_key प्रारूप में है। यूआरएल पृष्ठ पर प्रदर्शित संस्थाओं के लिए एक टैग के रूप में कार्य करता है। उदाहरण के लिए, आप डेटाबेस में एक नियमित तालिका बना सकते हैं, जहां प्रत्येक इकाई को एक विशिष्ट पृष्ठ पर मैप किया जाएगा, जिस पर वह प्रदर्शित होता है। फिर, किसी भी डेटा को बदलते समय, हम टेबल पर एक चयन कर सकते हैं और उन सभी पृष्ठों का कैश हटा सकते हैं जिनकी हमें आवश्यकता है।

चरण 2. कैश सर्वर से कनेक्ट करें और कैश फ़ाइलों को हटा दें।

 #      ,      FILE_LIST=`cat $1 | tr "\n" " "` #   ssh  SSH=`which ssh` USER="root" #         nginx HOST="10.10.1.0" #   KEY="/var/keys/id_rsa" # SSH ,          $SSH -i ${KEY} ${USER}@${HOST} "rm -f ${FILE_LIST}" #       rm -rf rm -f $1 #   

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

कस्टम ब्लॉक कैशिंग

आइए संक्षेप में बताएं कि हम क्या करने में कामयाब रहे:

• बैकएंड पर लोड कम किया;
• कैशिंग प्रबंधन करना सीखें
• किसी भी समय कैश फ्लश करना सीखा।

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

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

एसएसआई क्या है और यह कैसे काम करता है

SSI (सर्वर-साइड शामिल, सर्वर-साइड इंक्लूज़न) एक HTML पृष्ठ में एम्बेडेड कमांड का एक सेट है जो सर्वर को बताता है कि क्या करना है।

यहां ऐसे आदेशों (निर्देशों) की एक सूची दी गई है:

• अगर / एलिफ / और / एंडिफ़ - ब्रांचिंग ऑपरेटर;
• प्रतिध्वनि - चर के मूल्यों को प्रदर्शित करता है;
• शामिल हैं - आपको दस्तावेज़ में किसी अन्य फ़ाइल की सामग्री सम्मिलित करने की अनुमति देता है।
बस आखिरी निर्देश पर चर्चा होगी। शामिल निर्देश में दो पैरामीटर हैं:
• फ़ाइल - सर्वर पर फ़ाइल के लिए पथ निर्दिष्ट करता है। वर्तमान निर्देशिका के बारे में;
• वर्चुअल - सर्वर पर दस्तावेज़ को वर्चुअल पथ बताता है।

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

 <!--#include virtual="/user/personal_news/"--> 

Sgin आवेषण शुरू करने के लिए nginx के लिए, आपको निम्नानुसार स्थान को संशोधित करने की आवश्यकता है:

 location / { ssi on; ... } 

अब स्थान "/" द्वारा संसाधित सभी अनुरोध ssi आवेषण करने में सक्षम होंगे।

इस पूरी योजना से हमारा अनुरोध कैसे होगा?

• क्लाइंट पेज का अनुरोध करता है;
• नगनेक्स बैकएंड के लिए अनुरोध करता है;
• बैकएंड ssi आवेषण के साथ पृष्ठ देता है;
• परिणाम कैश में संग्रहीत किया जाता है;
• Nginx "पूछताछ" लापता ब्लॉकों;
• परिणामी पृष्ठ ग्राहक को भेजा जाता है।

जैसा कि आप चरणों से देख सकते हैं, ssi निर्माण nginx कैश में मिल जाएगा, जो व्यक्तिगत ब्लॉकों को कैश नहीं करने की अनुमति देगा, और सभी आवेषण के साथ तैयार HTML पृष्ठ क्लाइंट को भेजा जाएगा। यहाँ हमारे लोडिंग काम करता है, nginx स्वतंत्र रूप से लापता पृष्ठ ब्लॉकों का अनुरोध करता है। लेकिन किसी भी अन्य समाधान की तरह, इस दृष्टिकोण के अपने पेशेवरों और विपक्ष हैं। कल्पना करें कि पृष्ठ पर कई ब्लॉक हैं जिन्हें उपयोगकर्ता के आधार पर अलग-अलग प्रदर्शित किया जाना चाहिए, फिर प्रत्येक ऐसे ब्लॉक को ssi इन्सर्ट के साथ बदल दिया जाएगा। नियगेंक्स, जैसा कि अपेक्षित था, बैकएंड से प्रत्येक ऐसे ब्लॉक का अनुरोध करेगा, अर्थात, उपयोगकर्ता का एक अनुरोध तुरंत बैकएंड के लिए कई अनुरोधों को उत्पन्न करेगा, जो मैं बिल्कुल नहीं चाहूंगा।

Ssi के माध्यम से लगातार बैकएंड अनुरोधों से छुटकारा पाना

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

 server { location /page { set $memcached_key "$uri"; memcached_pass 127.0.0.1:11211; error_page 404 502 504 = @fallback; } location @fallback { proxy_pass http://backend; } } 

चर $ मेम्चेचे_की में हमने वह कुंजी निर्दिष्ट की जिसके द्वारा नग्नेक्स मेमेचे से डेटा प्राप्त करने का प्रयास करेगा। मेमकेच सर्वर से कनेक्ट करने के लिए पैरामीटर मेम्केच्ड_पास डायरेक्टिव में सेट किए गए हैं। कनेक्शन को कई तरीकों से निर्दिष्ट किया जा सकता है:

• डोमेन नाम;

 memcached_pass cache.domain.ru; 

• आईपी पता और बंदरगाह;

 memcached_pass localhost:11211; 

• यूनिक्स सॉकेट;

 memcached_pass unix:/tmp/memcached.socket; 

• अपस्ट्रीम डायरेक्टिव।

 upstream cachestream { hash $request_uri consistent; server 10.10.1.1:11211; server 10.10.1.2:11211; } location / { ... memcached_pass cachestream; ... } 

यदि nginx कैश सर्वर से प्रतिक्रिया प्राप्त करने में कामयाब रहा, तो यह क्लाइंट को देता है। यदि कैश में कोई डेटा नहीं है, तो अनुरोध "@fallback" के माध्यम से बैकएंड पर भेजा जाएगा। Nginx के तहत मेमकेच्ड मॉड्यूल का यह छोटा सा सेटअप हमें ssi आवेषण से बैकएंड के लिए पासिंग अनुरोधों की संख्या को कम करने में मदद करेगा।

हमें उम्मीद है कि यह लेख उपयोगी था और हम सर्वर पर लोड को अनुकूलित करने के तरीकों में से एक को दिखाने में सक्षम थे, नगनेक्स कैशिंग स्थापित करने के मूल सिद्धांतों पर विचार करें और इसका उपयोग करते समय आने वाली समस्याओं को बंद करें।