रेल्स व्यूज़ को तेज़ करें: चरम प्रदर्शन के लिए सिद्ध तकनीकें

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

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

खैर, शुक्र है, कुछ सरल और प्रभावी प्रदर्शन और अनुकूलन तकनीकें हैं जिनका उपयोग आप कोड लिखना शुरू करते ही कर सकते हैं।

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

पूरे पोस्ट में, हम एक बुनियादी रेल्स ऐप से चिपके रहेंगे, उस पर सुधार करेंगे और परिणामों की तुलना करेंगे।

बुनियादी रेल्स ऐप में निम्नलिखित मॉडल हैं:

• Person (के कई addresses हैं)

  • name:string
  • votes_count:integer

• Profile (Person से संबंधित है)

  • address:string

यहाँ हमारा Person मॉडल कैसा दिखता है:

# == Schema Information
# Table name: people
# id :integer not null, primary key
# name :string
# votes_count :integer
# created_at :datetime not null
# updated_at :datetime not null

class Person < ApplicationRecord
  # Relationships
  has_many :profiles
  # Validations
  validates_presence_of :name
  validates_uniqueness_of :name
  def vote!
    update votes_count: votes_count + 1
  end
end

यहाँ हमारे Profile मॉडल का कोड है:

# == Schema Information
# Table name: profiles
# id :integer not null, primary key
# address :text
# person_id :integer
# created_at :datetime not null
# updated_at :datetime not null

class Profile < ApplicationRecord
  # Relationships
  belongs_to :person
  # Validations
  validates_presence_of :address
end

Faker जेम का उपयोग करके 1000 लोगों को पॉप्युलेट करने के लिए एक सीड फ़ाइल भी है।

अब हम ApplicationController में "home" नामक एक एक्शन बनाने जा रहे हैं।

def home
  @people = Person.all
end

हमारे home.html.erb का कोड इस प्रकार है:

<ul>
  <% @people.each do |person| %>
    <li id="<%= person.id %>"><%= render person %></li>
  <% end %>
</ul>

आइए एक ड्राई रन करें और इस बेंचमार्क के खिलाफ अपने पेज के प्रदर्शन को मापें।

उस पेज को लोड होने में 1066.7ms का भारी समय लगा। अच्छा नहीं! यही हम कम करने का लक्ष्य रखेंगे।

डेटाबेस क्वेरीज़

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

इस प्रदर्शन के उद्देश्य के लिए, मैं MySQL डेटाबेस का उपयोग करने जा रहा हूँ।

आइए देखें कि वह प्रारंभिक 1066ms लोड कैसे टूटता है।

414.7 'controllers/application_controller#home' निष्पादित करने के लिए

... (0.1ms) SELECT "profiles"."address" FROM "profiles" WHERE "profiles"."person_id" = ? [["person_id", 996]]
Rendered people/_person.html.erb (1.5ms)
(0.2ms) SELECT "profiles"."address" FROM "profiles" WHERE "profiles"."person_id" = ? [["person_id", 997]]
Rendered people/_person.html.erb (2.3ms)
(0.1ms) SELECT "profiles"."address" FROM "profiles" WHERE "profiles"."person_id" = ? [["person_id", 998]]
Rendered people/_person.html.erb (2.1ms)
(0.2ms) SELECT "profiles"."address" FROM "profiles" WHERE "profiles"."person_id" = ? [["person_id", 999]]
Rendered people/_person.html.erb (2.3ms)
(0.2ms) SELECT "profiles"."address" FROM "profiles" WHERE "profiles"."person_id" = ? [["person_id", 1000]]
Rendered people/_person.html.erb (2.0ms)
Rendered application/home.html.erb within layouts/application (890.5ms)
Completed 200 OK in 1066ms (Views: 890.5ms | ActiveRecord: 175.4ms)

"application/home.html.erb" और "people/_person.html.erb" पार्शियल्स को रेंडर करने के लिए 519.2 और 132.8।

क्या आपने कुछ अजीब देखा?

हमने कंट्रोलर में एक डेटाबेस कॉल की, लेकिन हर पार्शियल अपनी खुद की डेटाबेस कॉल भी करता है! N+1 क्वेरी समस्या का परिचय।

1. N+1 क्वेरीज़

यह एक बहुत लोकप्रिय और सरल अनुकूलन तकनीक है—लेकिन यह पहली बार उल्लेख के योग्य है क्योंकि यह गलती इतनी प्रचलित है।

आइए देखें कि "people/_person.html.erb" क्या करता है:

<ul>
  <li> Name: <%= person.name %> </li>
  <li> Addresses: <ul>
    <% person.profiles.each do |profile| %>
      <li><%= profile.address %></li>
    <% end %>
    </ul>
  </li>
</ul>
<%= button_to "Vote #{person.votes_count}", vote_person_path(person) %>

मूल रूप से, यह उस व्यक्ति के प्रोफाइल के लिए डेटाबेस को क्वेरी करता है और प्रत्येक को रेंडर करता है। इसलिए यह N क्वेरी करता है (जहां N लोगों की संख्या है) और 1 क्वेरी जो हमने कंट्रोलर में की—इस प्रकार, N+1।

इसे अनुकूलित करने के लिए, MySQL डेटाबेस जॉइन और रेल्स एक्टिवरिकॉर्ड includes फ़ंक्शंस का उपयोग करें।

आइए कंट्रोलर को निम्नलिखित से मेल खाने के लिए बदलें:

def home
  @people = Person.all.includes(:profiles)
end

सभी लोगों को 1 MySQL क्वेरी द्वारा लोड किया जाता है, और उनकी सभी संबंधित क्वेरीज़ दूसरी में लोड की जाती हैं। N+1 को केवल 2 क्वेरीज़ में लाना।

आइए देखें कि यह प्रदर्शन कैसे बढ़ाता है!

पेज लोड होने में केवल 936ms लगे। आप नीचे देख सकते हैं कि "application_controller#home" एक्शन 2 MySQL क्वेरीज़ करता है।

Rendered people/_person.html.erb (0.3ms)
Rendered people/_person.html.erb (0.2ms)
Rendered people/_person.html.erb (0.3ms)
Rendered people/_person.html.erb (0.3ms)
Rendered people/_person.html.erb (0.3ms)
Rendered people/_person.html.erb (0.3ms)
Rendered people/_person.html.erb (0.3ms)
Rendered people/_person.html.erb (0.2ms)
Rendered application/home.html.erb within layouts/application (936.0ms)
Completed 200 OK in 936ms (Views: 927.1ms | ActiveRecord: 9.3ms)

2. केवल वही लोड करें जिसका आप उपयोग करेंगे

यहाँ होमपेज कैसा दिखता है।

आप देख सकते हैं कि हमें केवल एड्रेस की आवश्यकता है, और कुछ नहीं। लेकिन "_person.html.erb" पार्शियल में हम प्रोफाइल ऑब्जेक्ट लोड करते हैं। आइए देखें कि हम वह परिवर्तन कैसे कर सकते हैं।

<li> Addresses: <ul>
  <% person.profiles.pluck(:address).each do |address| %>
    <li><%= address %></li>
  <% end %>
  </ul>
</li>

N+1 क्वेरीज़ पर अधिक गहराई से देखने के लिए, ActiveRecord प्रदर्शन पढ़ें: N+1 क्वेरीज़ एंटीपैटर्न।

प्रो टिप: आप इसके लिए एक स्कोप बना सकते हैं और इसे "models/profile.rb" फ़ाइल में जोड़ सकते हैं। आपकी व्यू फ़ाइलों में रॉ डेटाबेस क्वेरीज़ बहुत उपयोगी नहीं हैं।

3. सभी डेटाबेस कॉल्स को कंट्रोलर में ले जाएं

मान लीजिए, इस काल्पनिक एप्लिकेशन के भविष्य में, आप होम पेज पर कुल यूजर्स की संख्या प्रदर्शित करना चाहेंगे।

सरल! आइए व्यू में एक कॉल करें जो इस तरह दिखता है:

# of People: <%= @people.count %>

ठीक है, यह काफी सरल है।

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

Progress: <%= index / @people.count %>

दुर्भाग्य से, आपका सहकर्मी नहीं जानता कि आपने पहले ही यह क्वेरी बना ली है और वे इसे व्यूज़ में बार-बार बनाते हैं।

यदि आपका कंट्रोलर इस तरह दिखता:

def home
  @people = Person.all.includes(:profiles)
  @people_count = @people.count
end

तो पहले से गणना किए गए वेरिएबल्स का पुन: उपयोग करना आसान होता।

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

4. जहाँ भी संभव हो पेजिनेट करें!

सिर्फ वही लोड करने की तरह जिसकी आपको आवश्यकता है, यह केवल वही दिखाने में भी मदद करता है जिसकी आपको आवश्यकता है! पेजिनेशन के साथ, व्यूज़ जानकारी के एक हिस्से को रेंडर करते हैं और बाकी को मांग पर लोड करने के लिए रखते हैं। यह बहुत सारे मिलीसेकंड बचाता है! will_paginate और kaminari जेम्स इसे आपके लिए मिनटों में करते हैं।

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

HTML रीलोड से बचना

एक पारंपरिक रेल्स ऐप में, HTML व्यू रेंडरिंग में बहुत समय लगता है। सौभाग्य से, इसे कम करने के उपाय हैं।

1. टर्बोलिंक्स

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

यह हर लिंक को AJAX अनुरोध में बदल देता है और JS के माध्यम से पेज के पूरे बॉडी को बदल देता है। यह प्रदर्शन को बहुत सुधारता है क्योंकि इसे CSS, JS और इमेज को रीलोड नहीं करना पड़ता।

हालांकि, कस्टम JS लिखते समय आपको "टर्बोलिंक्स सेफ JS" लिखने के लिए अतिरिक्त सावधानी बरतनी होगी। इसके बारे में यहाँ और पढ़ें।

2. AJAX अनुरोधों का उपयोग करें

टर्बोलिंक्स की तरह, आप अपने कुछ लिंक और बटन को AJAX अनुरोधों में भी बदल सकते हैं। अंतर यह है कि आप नियंत्रित कर सकते हैं कि कौन सा HTML बदला जाता है बजाय टर्बोलिंक्स की तरह पूरे बॉडी को बदलने के।

आइए AJAX को एक्शन में देखें!

सैंपल ऐप में, प्रत्येक यूजर के लिए एक "Vote" बटन है। आइए मापें कि उस एक्शन को करने में कितना समय लगता है।

Started POST "/people/1/vote" for 127.0.0.1 at 2020-01-21 14:50:49 +0530
Processing by PeopleController#vote as HTML
Person Load (0.3ms) SELECT "people".* FROM "people" WHERE "people"."id" = ? LIMIT ? [["id", 1], ["LIMIT", 1]]
(0.1ms) begin transaction
Person Exists (4.5ms) SELECT 1 AS one FROM "people" WHERE "people"."name" = ? AND ("people"."id" != ?) LIMIT ? [["name", "Deon Waelchi"], ["id", 1], ["LIMIT", 1]]
SQL (1.0ms) UPDATE "people" SET "votes_count" = ?, "updated_at" = ? WHERE "people"."id" = ? [["votes_count", 1], ["updated_at", "2020-01-21 09:20:49.941928"], ["id", 1]]
Redirected to https://localhost:3000/
Completed 302 Found in 24ms (ActiveRecord: 7.5ms)
Started GET "/" for 127.0.0.1 at 2020-01-21 14:50:49 +0530
Processing by ApplicationController#home as HTML
Rendering application/home.html.erb within layouts/application
Rendered people/_person.html.erb (2.4ms)
(0.3ms) SELECT "profiles"."address" FROM "profiles" WHERE "profiles"."person_id" = ? [["person_id", 30]]
Rendered people/_person.html.erb (2.2ms)
...
Rendered application/home.html.erb within layouts/application (159.8ms)
Completed 200 OK in 190ms (Views: 179.0ms | ActiveRecord: 6.8ms)

पेज रीलोड करने जितना ही समय लगा, साथ ही वास्तविक वोटिंग भाग के लिए थोड़ा अतिरिक्त।

आइए इसे AJAX अनुरोध बनाएं। अब, हमारा "people/_person.html.erb" इस तरह दिखता है:

<%= button_to "Vote #{person.votes_count}", vote_person_path(person), remote: true %>

हमारा कंट्रोलर एक्शन JS प्रतिक्रिया लौटाता है, जो इस तरह दिखता है:

$("#<%= @person.id %>").html("<%= j render(partial: 'person', locals: {person: @person}) %>");

जैसा कि आप देख सकते हैं, हम केवल वही कंटेंट बदल रहे हैं जिसकी हमें आवश्यकता है। हम एक HTML आईडी प्रदान करते हैं ताकि एक div पर हुक कर सकें और उसे बदल सकें। बेशक, हम इसे केवल बटन कंटेंट को बदलकर और अनुकूलित कर सकते हैं, लेकिन इस पोस्ट के उद्देश्य के लिए, आइए पूरे पार्शियल को बदलें।

परिणाम?

Started POST "/people/1/vote" for 127.0.0.1 at 2020-01-21 14:52:56 +0530
Processing by PeopleController#vote as JS
Person Load (0.2ms) SELECT "people".* FROM "people" WHERE "people"."id" = ? LIMIT ? [["id", 1], ["LIMIT", 1]]
(0.1ms) begin transaction
Person Exists (0.3ms) SELECT 1 AS one FROM "people" WHERE "people"."name" = ? AND ("people"."id" != ?) LIMIT ? [["name", "Deon Waelchi"], ["id", 1], ["LIMIT", 1]]
SQL (0.4ms) UPDATE "people" SET "votes_count" = ?, "updated_at" = ? WHERE "people"."id" = ? [["votes_count", 2], ["updated_at", "2020-01-21 09:22:56.532281"], ["id", 1]]
(1.6ms) commit transaction
Rendering people/vote.js.erb (0.2ms)
SELECT "profiles"."address" FROM "profiles" WHERE "profiles"."person_id" = ? [["person_id", 1]]
Rendered people/_person.html.erb (3.2ms)
Rendered people/vote.js.erb (6.3ms)
Completed 200 OK in 31ms (Views: 14.6ms | ActiveRecord: 2.9ms)

30ms! बस इतना ही! यह कितना शानदार है?

प्रो टिप: यदि आप HTML आईडी और क्लास के झंझट में नहीं पड़ना चाहते हैं ताकि यह पता लगा सकें कि कब/क्या बदलना है, तो render_async जेम का उपयोग करने पर विचार करें। यह बॉक्स से बाहर बहुत सारा भारी काम करता है।

3. वेबसॉकेट्स का उपयोग करें

HTML रीलोड की एक बड़ी बात यह है कि यह आपको हर बार सर्वर से ताजा कंटेंट देता है। AJAX अनुरोध के साथ, आप केवल छोटे स्निपेट के लिए नवीनतम कंटेंट देखते हैं।

वेबसॉकेट्स एक बेहतरीन तकनीक है जो आपके सर्वर को क्लाइंट को अपडेट पुश करने देती है, बजाय इसके कि क्लाइंट नई जानकारी का अनुरोध करे।

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

• अपने यूजर्स को पूरे पेज को रीलोड करने के लिए कहें
• एक रीलोड बटन प्रदान करें जो केवल स्कोर को रीफ्रेश करता है
• हर सेकंड बैकएंड को पोल करने के लिए जावास्क्रिप्ट का उपयोग करें
  • यह सर्वर को पिंग करता रहेगा तब भी जब डेटा में कोई बदलाव न हो
  • प्रत्येक क्लाइंट हर सेकंड कॉल करेगा - आसानी से सर्वर को अभिभूत कर देगा
• वेबसॉकेट्स का उपयोग करें!

वेबसॉकेट्स के साथ, सर्वर के पास नियंत्रण होता है कि सभी क्लाइंट्स (या यहां तक कि एक सबसेट) को डेटा कब पुश करना है। चूंकि सर्वर जानता है कि डेटा कब बदलता है, यह केवल तब डेटा पुश कर सकता है जब कोई बदलाव हो!

रेल्स 5 ने ActionCable जारी किया, जो आपको सभी चीजों वेबसॉकेट्स को प्रबंधित करने देता है। यह क्लाइंट के लिए सर्वर की सदस्यता लेने के लिए एक JS फ्रेमवर्क और सर्वर के लिए परिवर्तनों को प्रकाशित करने के लिए एक बैकएंड फ्रेमवर्क प्रदान करता है। एक्शन केबल के साथ, आप अपनी पसंद की किसी भी वेबसॉकेट सेवा चुनने की क्षमता रखते हैं। यह Faye हो सकता है, एक सेल्फ-मैनेज्ड वेब सॉकेट सेवा, या Pusher एक सब्सक्रिप्शन सेवा।

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

ठीक है, वापस वेबसॉकेट्स पर। एक बार जब आप ActionCable सेटअप कर लेते हैं, तो आपका व्यू सर्वर से JSON इनपुट सुनने में सक्षम होगा। एक बार जब यह इसे प्राप्त करता है, तो आपके द्वारा लिखे गए हुक एक्शन संबंधित HTML कंटेंट को बदल देंगे।

रेल्स डॉक्स और Pusher के पास वेबसॉकेट्स के साथ निर्माण करने के तरीके पर बेहतरीन ट्यूटोरियल हैं। वे अवश्य पढ़े जाने चाहिए!

कैशिंग

अधिकांश लोड समय व्यूज़ रेंडर करने में खर्च होता है। इसमें सभी CSS, JS और इमेज लोड करना, ERB फ़ाइलों से HTML रेंडर करना और बहुत कुछ शामिल है।

लोड समय के एक हिस्से को कम करने का एक तरीका अपने एप्लिकेशन के उन हिस्सों की पहचान करना है जिन्हें आप जानते हैं कि कुछ समय के लिए या किसी घटना तक स्थिर रहेंगे।

हमारे उदाहरण में, यह स्पष्ट है कि जब तक कोई वोट नहीं करता, होम पेज अनिवार्य रूप से सभी के लिए समान दिखेगा (वर्तमान में यूजर्स के लिए अपने पते संपादित करने का कोई विकल्प नहीं है)। आइए "home.html.erb" पूरे पेज को कैश करने का प्रयास करें जब तक कोई घटना (वोट) न हो।

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

1. व्यूज़ कैश करना

कैशिंग के बिना 2000 रिकॉर्ड के लिए लोड समय 3500ms है!

आइए "home.html.erb" में सब कुछ कैश करें। यह सरल है,

<% cache do %>
  <ul>
    <% @people.each do |person| %>
      <li id="<%= person.id %>"><%= render person %></li>
    <% end %>
  </ul>
<% end %>

अगला, Dalli जेम इंस्टॉल करें और "development.rb" में कैश स्टोर को बदलें:

config.cache_store = :dalli_store

फिर, यदि आप Mac या Linux पर हैं, तो बस Memcached सेवा को इस तरह शुरू करें:

memcached -vv

अब रीलोड करें!!

इसमें लगभग 537ms लगे! यह गति में 7x सुधार है!

आप यह भी देखेंगे कि बहुत कम MySQL क्वेरीज़ हैं क्योंकि पूरा HTML Memcached में संग्रहीत था और वहीं से फिर से पढ़ा गया, बिना कभी आपके डेटाबेस को पिंग किए।

यदि आप अपने एप्लिकेशन लॉग पर जाते हैं, तो आप यह भी देखेंगे कि यह पूरा पेज कैश से पढ़ा गया था।

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

2. डेटाबेस क्वेरीज़ कैश करना

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

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

गणना को बार-बार दोहराने के बजाय, आप इसे कैश कर सकते हैं!

def team_size
  Rails.cache.fetch(:team_size, expires_in: 8.hour) do
    analytics_client = AnalyticsClient.query!(self)
    analytics_client.team_size
  end
end

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

3. डेटाबेस इंडेक्स

आप इंडेक्स का उपयोग करके क्वेरीज़ को भी तेज़ कर सकते हैं। एक व्यक्ति के सभी पते लाने के लिए एक साधारण क्वेरी,

person.addresses

यह क्वेरी Address टेबल से सभी पते लौटाने के लिए कहती है जहां person_id कॉलम person.id है। इंडेक्स के बिना, डेटाबेस को प्रत्येक पंक्ति का व्यक्तिगत रूप से निरीक्षण करना पड़ता है यह जांचने के लिए कि क्या यह person.id से मेल खाता है। हालांकि, इंडेक्स के साथ, डेटाबेस के पास उन पतों की सूची होती है जो एक निश्चित person.id से मेल खाते हैं।

डेटाबेस इंडेक्स के बारे में अधिक जानने के लिए यहाँ एक बेहतरीन संसाधन है!

सारांश

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

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

हालांकि, सावधान रहें—अनुकूलन एक फिसलन भरा ढलान है। आप खुद को मेरी तरह आदी पा सकते हैं!

P.S. प्रोडक्शन में अपने रेल्स ऐप के प्रदर्शन की निगरानी के लिए, AppSignal के APM को देखें - रूबी डेव्स द्वारा रूबी डेव्स के लिए बनाया गया। 🚀