रशियन डॉल कैशिंग के साथ तेज़ रेल्स ऐप्स अनलॉक करें

आज हम रशियन डॉल कैशिंग में गोता लगाएंगे, जो रेल्स के अंतर्निहित फ्रैगमेंट कैशिंग से आगे आपके कैशिंग को और बेहतर बनाने की एक रणनीति है।

फ्रैगमेंट कैशिंग

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

👋 और अगर आप केवल कैशिंग से परे प्रदर्शन के बारे में पढ़ना पसंद करते हैं, तो हमारी रूबी प्रदर्शन निगरानी चेकलिस्ट देखें।

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

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

रशियन डॉल कैशिंग उदाहरण

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

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

# app/views/products/index.html.erb
<h1>Products</h1>
<% @products.each do |product| %>
  <% cache product do %>
    <%= render product %>
  <% end %>
<% end %>

टिप: हम स्पष्टता के लिए पूरा ब्लॉक लिख रहे हैं, लेकिन आप <%= render partial: 'products/product', collection: @products, cached: true %> का उपयोग करके प्रत्येक उत्पाद को कैश ब्लॉक में रेंडर कर सकते हैं।

उत्पाद पार्शियल में, हम उत्पाद के प्रत्येक वेरिएंट के लिए एक पंक्ति रेंडर करते हैं।

# app/views/products/_product.html.erb
<article>
  <h1><%= product.title %></h1>
  <ul>
    <% product.variants.each do |variant| %>
      <%= render variant %>
    <% end %>
  </ul>
</article>

कैश अमान्यता

हालांकि रेल्स के फ्रैगमेंट कैशिंग में कैश कुंजियाँ कैश अमान्यता को आसान बनाती हैं, आप कभी भी कैश सत्यापन की चिंता से पूरी तरह मुक्त नहीं होते (कंप्यूटर विज्ञान में दो प्रसिद्ध कठिन चीजों में से एक)।

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

इसे ठीक करने का तरीका यह सुनिश्चित करना है कि जब भी उसके किसी वेरिएंट में कुछ बदलता है तो उत्पाद बदलता है। ऐसा करने के लिए, हम जब भी ऐसा होता है तो उत्पाद के updated_at एट्रिब्यूट को अपडेट करेंगे। चूंकि यह बहुत आम है, belongs_to (और एक्टिवमॉडल के अन्य संबंध मेथड) के लिए एक आर्गुमेंट है, जिसे :touch कहा जाता है, जो हमारे लिए स्वचालित रूप से पैरेंट ऑब्जेक्ट के updated_at को अपडेट कर देगा।

class Variant < ApplicationRecord
  belongs_to :product, touch: true
end

नेस्टेड फ्रैगमेंट

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

<article>
  <h1><%= product.title %></h1>
  <ul>
    <% product.variants.each do |variant| %>
      <% cache(variant) do %>
        <%= render variant %>
      <% end %>
    <% end %>
  </ul>
</article>

टिप: हम स्पष्टता के लिए पूरा ब्लॉक लिख रहे हैं, लेकिन आप <%= render partial: 'variants/variant', collection: product.variants, cached: true %> का उपयोग करके प्रत्येक वेरिएंट को कैश ब्लॉक में रेंडर कर सकते हैं।

एक कोल्ड कैश पर (आप rake tmp:cache:clear चलाकर कैश साफ़ कर सकते हैं), पहला अनुरोध प्रत्येक उत्पाद पार्शियल को रेंडर करेगा।

अब पेज का अनुरोध करने पर (विकास में कैशिंग चालू करना न भूलें rails dev:cache चलाकर), प्रत्येक उत्पाद पार्शियल को पार्शियल के रूप में कैश किया जाएगा, और दूसरा अनुरोध कैश्ड फ्रैगमेंट लौटाएगा।

Started GET "/products" for 127.0.0.1 at 2018-03-30 14:51:38 +0200
Processing by ProductsController#index as HTML
Rendering products/index.html.erb within layouts/application
Product Load (0.2ms) SELECT "products".* FROM "products"
Variant Load (0.9ms) SELECT "variants".* FROM "variants" WHERE "variants"."product_id" IN (27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51)
Rendered variants/_variant.html.erb (0.5ms)
Rendered variants/_variant.html.erb (0.1ms)
...
Rendered products/_product.html.erb (44.8ms) [cache miss]
...
Rendered products/index.html.erb within layouts/application (1378.6ms)
Completed 200 OK in 1414ms (Views: 1410.5ms | ActiveRecord: 1.1ms)
Started GET "/products" for 127.0.0.1 at 2018-03-30 14:51:41 +0200
Processing by ProductsController#index as HTML
Rendering products/index.html.erb within layouts/application
Product Load (0.3ms) SELECT "products".* FROM "products"
Variant Load (12.7ms) SELECT "variants".* FROM "variants" WHERE "variants"."product_id" IN (27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51)
Rendered products/index.html.erb within layouts/application (48.1ms)
Completed 200 OK in 76ms (Views: 59.0ms | ActiveRecord: 13.0ms)

वोइला: रशियन डॉल जादू

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

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

Started GET "/products" for 127.0.0.1 at 2018-03-30 14:52:04 +0200
Processing by ProductsController#index as HTML
Rendering products/index.html.erb within layouts/application
Product Load (0.3ms) SELECT "products".* FROM "products"
Variant Load (1.2ms) SELECT "variants".* FROM "variants" WHERE "variants"."product_id" IN (27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51)
Rendered variants/_variant.html.erb (0.5ms)
Rendered products/_product.html.erb (13.3ms) [cache miss]
Rendered products/index.html.erb within layouts/application (45.9ms)
Completed 200 OK in 78ms (Views: 73.5ms | ActiveRecord: 1.5ms)

अंतिम परिणाम

इस तरह कैश फ्रैगमेंट को नेस्ट करके, व्यू लगभग कभी भी पूरी तरह से रेंडर नहीं होता, जब तक कि कैश पूरी तरह से खाली न हो। यहां तक कि जब डेटा बदलता है, तो अधिकांश रेंडर्ड पेज सीधे कैश से सर्व किए जाते हैं।

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