रशियन डॉल कैशिंग के अलावा, रेल्स ऐप्स में प्रदर्शन को तेज करने के लिए और भी तकनीकें हैं। इस बार हम रेल्स के बिल्ट-इन सशर्त GET समर्थन को देखेंगे, जो आपको रेंडर्ड पेज को यूजर के ब्राउज़र कैश में स्टोर करने की अनुमति देता है।
👋 और यदि आप कैशिंग के बाहर प्रदर्शन के बारे में अधिक पढ़ना पसंद करते हैं, तो हमने रूबी (ऑन रेल्स) प्रदर्शन के बारे में बहुत कुछ लिखा है, हमारे रूबी प्रदर्शन निगरानी चेकलिस्ट को देखें।
Etag और Last-Modified हेडर्स
जब आपका ब्राउज़र आपके रेल्स ऐप में एक पेज के लिए HTTP GET अनुरोध निष्पादित करता है, तो राउटर इसे आपके कंट्रोलर एक्शन से जोड़ देगा। कंट्रोलर तब डेटाबेस से आवश्यक डेटा का अनुरोध करेगा और व्यू को रेंडर करेगा। एक HTTP रिस्पांस (बॉडी में व्यू से रेंडर्ड HTML के साथ 200 OK रिस्पांस कोड के रूप में) तब ब्राउज़र को वापस भेजा जाता है जिसे आपका ब्राउज़र पार्स और प्रदर्शित करता है।
जब संसाधन का फिर से अनुरोध किया जाता है, तो हम उसी पाइपलाइन से गुजरेंगे। कुछ स्थितियों में, यह अनावश्यक है क्योंकि पेज बीच में नहीं बदला। इसके लिए, HTTP अपने ETag और Last-Modified हेडर्स प्रदान करता है। इनका उपयोग करके, ब्राउज़र रिस्पांस बॉडी को स्टोर कर सकता है, और जब वे स्टेल हो जाते हैं तो उन्हें अमान्य करने के लिए हेडर्स का उपयोग कर सकता है।
Etags, या एंटिटी टैग्स, क्लाइंट-साइड कैश वैलिडेशन के लिए उपयोग किए जाते हैं, इसलिए आप उन्हें अपने HTTP रिस्पांस के लिए कैश कुंजी के रूप में सोच सकते हैं। उन्हें हर अनुरोध के लिए HTTP रिस्पांस हेडर में ब्राउज़र को वापस पास किया जाता है।
~ $ curl -I https://localhost:3000/products/1 HTTP/1.1 200 OK ... ETag: W/"9462d76cc55aeb6249fa990e39231c7c" Last-Modified: Wed, 25 Apr 2018 08:27:04 GMT ...
यदि रिस्पांस बाद में दोहराया जाता है, तो ब्राउज़र अपने कैश में मौजूदा रिस्पांस ढूंढता है और अंतिम अनुरोध से संग्रहीत Etag का उपयोग If-None-Match हेडर के रूप में करता है। यह हेडर हमारे रेल्स ऐप को बताएगा कि हमारे पास पहले से ही यह संस्करण कैश में है।
यदि रिक्वेस्ट से Etag वर्तमान से मेल खाता है, तो रेल्स रिस्पांस बॉडी के बिना 304 Not Modified रिस्पांस भेजेगा। यह ब्राउज़र को अपने लोकल कैश से उपयोग करने के लिए कहेगा।
~ $ curl -i -H 'If-None-Match: W/"9462d76cc55aeb6249fa990e39231c7c"' https://localhost:3000/products/1 HTTP/1.1 304 Not Modified ... ETag: W/"9462d76cc55aeb6249fa990e39231c7c" Last-Modified: Wed, 25 Apr 2018 08:27:04 GMT ...
रेल्स में सशर्त GET अनुरोध
यदि हम एक स्थानीय रेल्स एप्लिकेशन से एक पेज का अनुरोध करते हैं, तो हम देख सकते हैं कि रेल्स डिफ़ॉल्ट रूप से प्रत्येक अनुरोध के लिए एक Etag जोड़ता है। यदि हम कुछ बार एक ही पेज का अनुरोध करते हैं, तो हम देख सकते हैं कि Etag प्रत्येक अनुरोध के लिए बदलता है।
जबकि रेल्स डिफ़ॉल्ट रूप से प्रत्येक अनुरोध के लिए एक Etag जनरेट करता है, यह पूरे रिस्पांस बॉडी के डाइजेस्ट का उपयोग करके इसे जनरेट करता है। इसका मतलब है कि लेआउट में <%= csrf_meta_tags %> Etag को गड़बड़ कर देता है, क्योंकि csrf-token मेटा टैग प्रत्येक अनुरोध के लिए बदलता है। चूंकि यह प्रत्येक अनुरोध के लिए बॉडी को बदलता है, Etag अमान्य हो जाता है और लोकल कैश को स्टेल मार्क किया जाता है।
इसके अलावा, रेल्स डिफ़ॉल्ट रूप से कभी भी 304 Not Modified नहीं लौटाएगा, क्योंकि लोकल कैश को हमारे कंट्रोलर में कभी भी स्पष्ट रूप से फ्रेश के रूप में मार्क नहीं किया जाता है।
fresh_when और stale?
क्लाइंट-साइड सशर्त GET के लिए रिक्वेस्ट हेडर से Etags का उपयोग करने के लिए, हमें लोकल कैश में एक ऑब्जेक्ट को स्पष्ट रूप से "फ्रेश" के रूप में मार्क करने की आवश्यकता है। उदाहरण के लिए, एक पेज के लिए जो एक उत्पाद दिखाता है, हम कैश को तब तक फ्रेश रख सकते हैं जब तक उत्पाद और व्यू टेम्पलेट्स नहीं बदलते। इसे काम करने के लिए, हम दो चीजें करेंगे।
- हम स्पष्ट रूप से उन मानों को सेट करेंगे जो हमारे Etag को बनाएंगे, क्योंकि पूरे रिस्पांस बॉडी का उपयोग करने के लिए हमें यह जांचने के लिए पूरे बॉडी को रेंडर करना होगा कि कैश्ड रिस्पांस वैध है या नहीं, जो लोकल पेज कैशिंग से स्पीडअप को नकार देगा।
- हम रिक्वेस्ट हेडर से Etag की तुलना व्यू रेंडर करने से पहले हमारे द्वारा अनुमानित एक से करेंगे, और यदि वे मेल खाते हैं तो रेंडरिंग को छोड़ देंगे।
रेल्स हमारे लिए सब कुछ करने वाले हेल्पर्स के साथ आता है। हम fresh_when का उपयोग करके Etag और Last-Modified तारीख को उत्पाद पर स्पष्ट रूप से आधारित कर सकते हैं।
यदि आपके पास एक स्पष्ट respond_to ब्लॉक है, तो fresh_when के बजाय stale? का उपयोग करें।
अब, उत्पाद पेज में से एक का अनुरोध करने से रिस्पांस लोकल रूप से कैश होगा। उसी पेज के किसी भी बाद के अनुरोध में Etag शामिल होगा जो रेल्स को बताता है कि हमारे पास एक कैश्ड रिस्पांस है, जिसकी तुलना नए Etag से की जाती है। यदि वह मेल खाता है, तो रेल्स पेज रेंडरिंग को छोड़ देगा, और तुरंत 304 Not Modified लौटाएगा।
नोट: पेज रीफ्रेश करने से हमेशा पेज का अनकैश्ड वर्जन अनुरोध किया जाएगा। यह टेस्ट करने के लिए कि आपके सशर्त GET काम करते हैं, लिंक या बैक बटन का उपयोग करके नेविगेट करें बजाय रीफ्रेश के।
आपको यह लेख और AppSignal अकादमी श्रृंखला में पिछले लेख कैसे लगे? हमारे पास रेल्स में कैशिंग के बारे में कुछ और लेख लाइन में हैं, लेकिन कृपया हमें यह बताने में संकोच न करें कि आप आगे क्या लिखवाना चाहेंगे (कैशिंग-संबंधी या अन्यथा)!
