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

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

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

👋 और यदि आप इस लेख को पसंद करते हैं, तो हमने रूबी (ऑन रेल्स) के प्रदर्शन के बारे में और भी बहुत कुछ लिखा है, हमारी रूबी प्रदर्शन निगरानी चेकलिस्ट देखें।

स्थानीय रूप से कैशिंग का परीक्षण करना

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

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

$ rails dev:cache
Development mode is now being cached.

कैशिंग को वापस बंद करने के लिए आप वही आदेश चला सकते हैं।

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

मान लें कि हमारे पास एक ऐसा पृष्ठ है जो एक ही पृष्ठ पर एक स्टोर में सभी उत्पादों को दिखाता है। ऐसा करने के लिए, हमारे पास एक इंडेक्स व्यू है जो उत्पादों को दिखाता है।

# app/views/products/index.html.erb
<table>
  <thead>
    <tr>
      <th>Title</th>
      <th>Description</th>
      <th>Image url</th>
      <th>Price</th>
      <th colspan="3"></th>
    </tr>
  </thead>
 
  <tbody>
    <% @products.each do |product| %>
      <%= render product %>
    <% end %>
  </tbody>
</table>

प्रत्येक उत्पाद के लिए, _product.html.erb आंशिक रेंडर किया गया है, जो उत्पाद के विवरण के साथ एक तालिका पंक्ति प्रदर्शित करने का ध्यान रखता है।

# app/views/products/_product.html.erb
<tr>
  <td><%= product.title %></td>
  <td><%= product.description %></td>
  <td><%= product.image_url %></td>
  <td><%= product.price %></td>
  <td><%= link_to 'Show', product %></td>
  <td><%= link_to 'Edit', edit_product_path(product) %></td>
  <td><%= link_to 'Destroy', product, method: :delete, data: { confirm: 'Are you sure?' } %></td>
</tr>

डेटाबेस में 25 उत्पादों के साथ, विकास मोड में, स्थानीय रूप से पृष्ठ का अनुरोध करने में लगभग 300 मिलीसेकंड लगते हैं। लगभग सारा समय आंशिक रूप से प्रस्तुत करने में व्यतीत होता है।

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

Started GET "/products" for ::1 at 2018-03-13 12:16:08 +0100
Processing by ProductsController#index as HTML
  Rendering products/index.html.erb within layouts/application
  Product Load (0.4ms)  SELECT "products".* FROM "products"
  Rendered products/_product.html.erb (1.4ms)
  Rendered products/_product.html.erb (0.4ms)
  Rendered products/_product.html.erb (0.4ms)
  Rendered products/_product.html.erb (0.3ms)
  Rendered products/_product.html.erb (0.5ms)
  Rendered products/_product.html.erb (2.0ms)
  Rendered products/_product.html.erb (0.9ms)
  Rendered products/_product.html.erb (0.4ms)
  Rendered products/_product.html.erb (0.5ms)
  Rendered products/_product.html.erb (0.5ms)
  Rendered products/_product.html.erb (0.6ms)
  Rendered products/_product.html.erb (0.6ms)
  Rendered products/_product.html.erb (0.6ms)
  Rendered products/_product.html.erb (0.6ms)
  Rendered products/_product.html.erb (0.7ms)
  Rendered products/_product.html.erb (0.6ms)
  Rendered products/_product.html.erb (0.7ms)
  Rendered products/_product.html.erb (0.6ms)
  Rendered products/_product.html.erb (0.5ms)
  Rendered products/_product.html.erb (0.7ms)
  Rendered products/_product.html.erb (0.6ms)
  Rendered products/_product.html.erb (0.9ms)
  Rendered products/_product.html.erb (0.6ms)
  Rendered products/_product.html.erb (0.5ms)
  Rendered products/_product.html.erb (0.6ms)
  Rendered products/index.html.erb within layouts/application (257.5ms)
Completed 200 OK in 295ms(Views: 290.4ms | ActiveRecord: 0.4ms)

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

किसी टुकड़े को कैश करने के लिए, आप उसे cache . का उपयोग करके एक ब्लॉक में लपेटते हैं सहायक।

<table>
  # ...
  <tbody>
    <% @products.each do |product| %>
      <% cache(product) do %>
        <%= render product %>
      <% end %>
    <% end %>
  </tbody>
</table>

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

Started GET "/products" for ::1 at 2018-03-13 12:17:29 +0100
Processing by ProductsController#index as HTML
  Rendering products/index.html.erb within layouts/application
  Product Load (0.4ms)  SELECT "products".* FROM "products"
  Rendered products/index.html.erb within layouts/application (21.2ms)
Completed 200 OK in 55ms (Views: 50.8ms | ActiveRecord: 0.4ms)

इसने काम कर दिया! दूसरा अनुरोध पहले वाले की तुलना में पांच गुना अधिक तेज था। ध्यान दें कि लॉग आंशिक का कोई प्रतिपादन नहीं दिखाते, क्योंकि वे सीधे कैश से लोड होते हैं।

कैश खत्म हो रहा है

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

आंतरिक रूप से, उत्पाद ऑब्जेक्ट में एक #cache_key होता है विधि, जिसका उपयोग कैश्ड टुकड़े के लिए एक कुंजी बनाने के लिए किया जाता है। पूरे टुकड़े की कुंजी इस तरह दिख सकती है:

views/products/42-20180302103130041320/75dda06d36880e8b0ae6cac0a44fb56d

कैश कुंजी में कुछ भाग होते हैं:

• "दृश्य/उत्पाद" संचय है वर्ग ।
• 42 उत्पाद की आईडी है
• 20180302103130041320 उत्पाद की अद्यतन_तारीख है
• 75dda06d36880e8b0ae6cac0a44fb56d टेम्पलेट ट्री का डाइजेस्ट है

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

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

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

बेशक, हम ऐपसिग्नल अकादमी के बाद के एपिसोड में इनके बारे में जानेंगे। कोई खास बात जिसके बारे में आप जानना चाहेंगे? कृपया हमें @AppSignal पर बताने में संकोच न करें। बेशक, हमें यह जानना अच्छा लगेगा कि आपको यह लेख कैसा लगा, या यदि आपके पास कोई अन्य विषय है जिसके बारे में आप अधिक जानना चाहते हैं।