इस लेख में, हम तीन सबसे लोकप्रिय रूबी टेम्पलेटिंग इंजनों के प्रदर्शन का परीक्षण और विश्लेषण करेंगे: ERB (डिफ़ॉल्ट), HAML, और SLIM।
बेंचमार्किंग व्यावसायिक प्रक्रियाओं और प्रदर्शन मेट्रिक्स की तुलना अन्य कंपनियों के उद्योग सर्वोत्तम और सर्वोत्तम प्रथाओं से करने का अभ्यास है। इस बीच, लोड परीक्षण एक प्रणाली पर मांग डालने और उसकी प्रतिक्रिया को मापने की प्रक्रिया है।
हमारा लक्ष्य रूबी बेंचमार्क मॉड्यूल का थोड़ा पता लगाना है, जो रूबी कोड को निष्पादित करने के लिए उपयोग किए गए समय को मापने और रिपोर्ट करने के तरीके प्रदान करता है। हम कुछ इंलाइन टेम्पलेट्स बनाएंगे, उन्हें परीक्षणों के विरुद्ध चलाएंगे, और तीन अलग-अलग इंजनों पर मेट्रिक्स निकालेंगे।
उसके बाद, हम कुछ वास्तविक-विश्व टेम्पलेट व्यूज़ बनाकर, उन्हें सर्वर पर लाइव डालकर, और फिर hey टूल के माध्यम से कुछ लोड परीक्षण करके लोड परीक्षण में गोता लगाएंगे। यह हमें एक विशिष्ट वेब एप्लिकेशन पर लोड भेजने और प्रत्येक एंडपॉइंट और इसलिए प्रत्येक टेम्पलेट इंजन के प्रदर्शन से संबंधित पूरी तरह से डेटा प्राप्त करने के लिए कुछ बेहतरीन सुविधाएँ प्रदान करता है।
सेटअप
पहली चीज़, निश्चित रूप से, यह सुनिश्चित करना है कि आपके पास पहले से ही रूबी इंस्टॉल है। हम लेखन के समय के अनुसार सबसे हाल के संस्करण, 2.7.0 का उपयोग कर रहे हैं। रेल्स जेम इंस्टॉल करना भी सुनिश्चित करें।
रूबी और रेल्स जेम बहुत अधिक वही हैं जो हमें शुरू करने के लिए चाहिए। इस ट्यूटोरियल के लिए, विजुअल स्टूडियो कोड कोडिंग के लिए IDE है, लेकिन यदि आप पसंद करते हैं तो दूसरा चुनने के लिए स्वतंत्र महसूस करें।
अब, हमारे रेल्स प्रोजेक्ट के लिए एक फोल्डर चुनें और निम्न कमांड चलाएं:
rails new haml-slim-erb
यह सभी आवश्यक निर्भरताओं को डाउनलोड करेगा और हमारे स्कैफोल्डेड रेल्स प्रोजेक्ट को बनाएगा। आगे बढ़ें और इसका पता लगाएं।
कोड पर आगे बढ़ने से पहले, हमें अपने Gemfile में SLIM और HAML निर्भरताओं को जोड़ने की आवश्यकता है:
group :development, :test do
# कोड में कहीं भी 'byebug' कॉल करें ताकि निष्पादन रुके और डिबगर कंसोल मिले
gem 'byebug', platform: :mri
gem 'haml'
gem 'slim'
end
प्रोजेक्ट के साथ डिफ़ॉल्ट रूप से एक बग भी आता है जो SQLite संस्करण से संबंधित है। इसे Gemfile में ढूंढें और इसे निम्न में बदलें:
gem 'sqlite3', '~> 1.3.0'
अब, निर्भरताओं को डाउनलोड करने के लिए bundle install कमांड चलाएं।
बेंचमार्क मॉड्यूल की खोज
इस लेख के इस भाग के लिए, हम सीधे test फोल्डर के साथ काम करेंगे। इसे खोलें, और आपको कुछ खाली फोल्डर दिखाई देंगे। आइए benchmark नामक एक नया बनाएं और तीन अन्य फाइलें: example_1_test.rb, example_2_test.rb, और example_3_test.rb.।
रूबी को यह आवश्यक है कि वे test से समाप्त हों ताकि उन्हें टेस्ट फाइल माना जाए।
अब, पहली फाइल में निम्नलिखित सामग्री जोड़ें:
require 'benchmark'
number = (0..50).to_a.sort{ rand() - 0.5 }[0..10000]
puts Benchmark.measure {
20_000.times do
number[rand()] * (0..50).to_a.sort{ rand() - 0.5 }[0..10000][rand()]
end
}
ध्यान दें कि पहली लाइन आवश्यक बेंचमार्क मॉड्यूल को आयात करती है। फिर, हम 0 से 50 तक की यादृच्छिक संख्याओं की एक सरणी उत्पन्न करते हैं जिसका आकार 10,000 है। ये बड़ी संख्याएं केवल प्रसंस्करण में कुछ समय लेने के लिए हैं।
measure मेथड बहुत उपयोगी है क्योंकि इसे आपके रूबी कोड में कहीं भी रखा जा सकता है ताकि यह मापा जा सके कि प्रसंस्करण में कितना समय लग रहा है। यह समय puts द्वारा लौटाया और प्रिंट किया जाता है।
अंदर, हम 20k बार एक ही यादृच्छिक-जनरेटेड सरणी के निष्पादन को लूप कर रहे हैं ताकि प्रत्येक के एक मान को गुणा किया जा सके।
इस विशिष्ट टेस्ट फाइल को चलाने के लिए, निम्न कमांड जारी करें:
rake test TEST=test/benchmark/example_1_test.rb
परिणाम ऐसा दिख सकता है:
0.702647 0.012353 0.715000 ( 0.721910)
यह रिपोर्ट क्रमशः उपयोगकर्ता CPU समय, सिस्टम CPU समय, उपयोगकर्ता और सिस्टम CPU समय का योग, और बीता हुआ वास्तविक समय प्रिंट करती है। समय की इकाई सेकंड है।
हम आगे अभ्यास में बेंचमार्क के अन्य तरीकों का उपयोग करेंगे।
इंलाइन टेम्पलेट्स परीक्षण
अब जब आप समझ गए हैं कि रूबी का बेंचमार्क मॉड्यूल कैसे काम करता है, तो हम तीन टेम्पलेट्स पर कुछ परीक्षणों के निष्पादन में गोता लगाएंगे।
इसके लिए, हम एक टेम्पलेट बनाएंगे, इसे तीन इंजन सिंटैक्स में अनुवाद करेंगे, और अंत में, इसे बेंचमार्क मेथड के तहत चलाएंगे।
दूसरी टेस्ट फाइल में निम्नलिखित जोड़ें:
require 'erb'
require 'haml'
require 'slim'
require 'benchmark'
require 'ostruct'
notes = OpenStruct.new(
title: 'Write an essay',
description: 'My essay is about...',
randomList: (0..50).to_a.sort{ rand() - 0.5 }[0..10000]
)
erb_example = <<-ERB_EXAMPLE
<span><%= notes.title %></span>
<span><%= notes.description %></span>
<table>
<tr>
<% notes.randomList.each do |note| %>
<td><%= note %></td>
<% end %>
</tr>
</table>
ERB_EXAMPLE
slim_example = <<-SLIM_EXAMPLE
span= notes.title
span= notes.description
table
tr
- notes.randomList.each do |note|
td= note
SLIM_EXAMPLE
haml_example = <<-HAML_EXAMPLE
%span= notes.title
%span= notes.description
%table
%tr
- notes.randomList.each do |note|
%td= note
HAML_EXAMPLE
context = OpenStruct.new(notes: notes)
__result = ''
Benchmark.bmbm(20) do |bcmk|
bcmk.report("erb_test") {
(1..2000).each {
ERB.new(erb_example, 0, '-', '__result').result binding
}
}
bcmk.report("slim_test") {
(1..2000).each{
__result = Slim::Template.new { slim_example }.render(context)
}
}
bcmk.report("haml_test") {
(1..2000).each {
__result = Haml::Engine.new(haml_example).render(binding)
}
}
end
पहले, आवश्यक मॉड्यूल आयात करें। टेम्पलेट इंजन्स के अलावा, हम ostruct मॉड्यूल भी आयात कर रहे हैं। एक OpenStruct मेटाप्रोग्रामिंग से एक डेटा संरचना है, जो Hash के समान है, जो मनमाने गुणों को उनके साथ आने वाले मूल्यों के साथ परिभाषित करने की अनुमति देता है।
यह उपयोगी है क्योंकि हमें मानों को संग्रहीत करने के लिए एक पूरी क्लास संरचना बनाने की आवश्यकता नहीं है। हम इसे इंलाइन परिभाषित कर सकते हैं।
हमारा स्ट्रक्ट मूल रूप से एक Note ऑब्जेक्ट है जिसमें एक शीर्षक, विवरण, और यादृच्छिक संख्याओं की एक सूची है, जो प्रसंस्करण समय बढ़ाती है।
हम इस बात पर ध्यान केंद्रित नहीं करेंगे कि प्रत्येक टेम्पलेट इंजन कैसे काम करता है; आप इसके लिए उनके आधिकारिक डॉक्स देख सकते हैं। हालांकि, उनका सिंटैक्स आत्मसात करने में काफी आसान है।
जादू कोड के अंत में रखा गया है। अब, हम bmbm मेथड का उपयोग कर रहे हैं, जो पहले वाले से थोड़ा अधिक करता है। कभी-कभी, बेंचमार्क परिणाम बाहरी कारकों के कारण तिरछे हो सकते हैं, जैसे गारबेज कलेक्शन, मेमोरी लीक, आदि। यह मेथड इस प्रभाव को कम करने का प्रयास करता है परीक्षणों को दो बार चलाकर: पहली बार रिहर्सल के रूप में रनटाइम वातावरण को स्थिर करने के लिए और दूसरी बार असली के लिए। आप इस पर यहां और पढ़ सकते हैं।
अंत में, bmbm की प्रत्येक आंतरिक कोड लाइन प्रत्येक टेम्पलेट के निर्माण के दौरान 2000 बार एक लूप निष्पादित करती है। फोकस टेम्पलेट को असाइन करने और इसे रेंडर करने पर है।
इस टेस्ट फाइल को निष्पादित करने के बाद, यहाँ परिणाम है:
Rehearsal --------------------------------------------------------
erb_test 0.311534 0.002963 0.314497 ( 0.314655)
slim_test 2.544711 0.004520 2.549231 ( 2.550307)
haml_test 1.449813 0.003169 1.452982 ( 1.454118)
----------------------------------------------- total: 4.316710sec
user system total real
erb_test 0.298730 0.000679 0.299409 ( 0.299631)
slim_test 2.550665 0.004148 2.554813 ( 2.556023)
haml_test 1.432653 0.001984 1.434637 ( 1.435417)
दो परिणाम ब्लॉक्स आपके लिए रिहर्सल से वास्तविक को आत्मसात करने के लिए अलग किए गए हैं।
परिदृश्य को थोड़ा बदलना
पिछले टेस्ट परिणामों के लिए, आप मान सकते हैं कि ERB सबसे अच्छा विकल्प है, जबकि SLIM सबसे खराब है। फिर से, यह स्थिति पर निर्भर करता है।
उस टेस्ट में, हर बार जब हम लूप करते हैं, हमें एक नया टेम्पलेट इंजन ऑब्जेक्ट इंस्टेंटिएट करना पड़ता है। यह एक इष्टतम प्रवाह नहीं है।
आइए इसे थोड़ा बदलें और इस इंस्टेंटिएशन को बाहर ले जाएं, जैसा कि निम्न कोड स्निपेट में दिखाया गया है:
erb_engine = ERB.new(erb_example, 0, '-', '__result')
slim_engine = Slim::Template.new { slim_example }
haml_engine = Haml::Engine.new(haml_example)
Benchmark.bmbm(10) do |bcmk|
bcmk.report("erb_test") {
(1..2000).each { erb_engine.result binding }
}
bcmk.report("slim_test") {
(1..2000).each{ __result = slim_engine.render(context) }
}
bcmk.report("haml_test") {
(1..2000).each { __result = haml_engine.render(binding) }
}
end
कोड पहले जैसा ही करता है। अब, टेस्ट फिर से चलाएं, और आप ऐसा कुछ देखेंगे:
Rehearsal ----------------------------------------------
erb_test 0.127599 0.002407 0.130006 ( 0.130137)
slim_test 0.046972 0.000841 0.047813 ( 0.047858)
haml_test 0.208308 0.002239 0.210547 ( 0.210769)
-------------------------------------- total: 0.388366sec
user system total real
erb_test 0.118002 0.000556 0.118558 ( 0.118618)
slim_test 0.040129 0.000090 0.040219 ( 0.040320)
haml_test 0.205331 0.001163 0.206494 ( 0.206680)
ध्यान दें कि अब कौन सा सबसे अच्छा और सबसे खराब है। यह सिर्फ यह दिखाने के लिए है कि एक आदर्श इंजन के मामले में कोई सिल्वर बुलेट नहीं है।
आपको परीक्षण और विश्लेषण करना होगा कि कौन सी सुविधाएं आपकी कोडिंग शैली के लिए बेहतर प्रदर्शन करती हैं। साथ ही, अन्य सहायक उपकरण हैं, जैसे रूबी प्रोफाइलर, जिनका उपयोग आप यह बेहतर समझने के लिए कर सकते हैं कि कोड इस तरह कैसे व्यवहार करता है।
लोड परीक्षण एक वास्तविक-विश्व परिदृश्य
आइए कुछ ऐसा करें जो हमारी वास्तविकता के करीब हो। हम एक वास्तविक टेम्पलेट को बेंचमार्क करने जा रहे हैं जो कुछ नोट्स सूचीबद्ध करता है (तीन, प्रत्येक टेम्पलेट इंजन के लिए एक)।
चूंकि benchmark मॉड्यूल रेल्स कोड में होता है, हम टेम्पलेट इंजन आंतरिक प्रक्रियाओं से संबंधित कुछ महत्वपूर्ण माप खो देते हैं।
इस प्रकार का बेंचमार्क टेस्ट हमें यह देखने की अनुमति देता है कि प्रत्येक इंजन पूरी तरह से कैसे प्रदर्शन करता है, एक अनुरोध के आगमन से लेकर व्यावसायिक तर्क प्रसंस्करण तक, जब तक प्रतिक्रिया डेटा व्यूज़ तक नहीं पहुंच जाता। यह अंतिम वाला, विशेष रूप से, कई चरणों में होगा, जैसे पार्सिंग और रेंडरिंग प्रक्रियाएं जिन्हें लोड टेस्ट माप सकता है, और benchmark नहीं कर सकता।
पहले, आइए प्रत्येक उदाहरण के लिए रेल्स कंट्रोलर बनाएं:
rails g controller notes_erb index
rails g controller notes_haml index
rails g controller notes_slim index
यह कमांड ऑटो-जेनरेट करेगा बहुत सारी सामान्य रेल्स फाइलें जिनसे आप परिचित हो सकते हैं।
अब, बने notes_erb_controller.rb फाइल को खोलें और इसकी सामग्री को बदलें:
class NotesErbController < ApplicationController
def index
@notes = JSON.parse(Constants::NOTES, object_class: OpenStruct)
end
end
यहाँ वह जगह है जहां हम टेम्पलेट्स को डेटा खिलाते हैं। ध्यान दें कि हमारे पास प्रत्येक इंजन के लिए एक कंट्रोलर क्लास है।
मूल रूप से, हम एक इंलाइन कॉन्स्टेंट से कुछ JSON ले रहे हैं। प्रतिक्रिया को एक नए OpenStruct ऑब्जेक्ट में पार्स किया जाएगा और इंजनों को वापस कर दिया जाएगा।
NOTES कॉन्स्टेंट को constants.rb नामक एक नई फाइल में रखा जाना चाहिए। आगे बढ़ें और इसे बनाएं, और फिर निम्नलिखित सामग्री जोड़ें:
class Constants
NOTES = '[
{
"title": "Walk the dog",
"description": "Bla bla",
"tasks": [
{ "title": "Task #1" },
{ "title": "Task #2" },
{ "title": "Task #3" }
]
},
...
{
"title": "Walk the dog",
"description": "Bla bla",
"tasks": [
{ "title": "Task #1" },
{ "title": "Task #2" },
{ "title": "Task #3" }
]
}
]'
end
कृपया, ellipsis को अधिक नोट तत्वों के लिए बदलना सुनिश्चित करें। साथ ही, अन्य कंट्रोलर्स में से प्रत्येक में तर्क को दोहराना न भूलें।
ERB व्यूज़ बनाना
अब, हमारे उदाहरण के व्यूज़ बनाने का समय है। ऐसा करने के लिए, views/notes_erb फोल्डर पर जाएं और दो अन्य फाइलें बनाएं: note.html.erb और task.html.erb। वे हमें एक उदाहरण बनाने में मदद करेंगे जिसमें व्यूज़, पार्शियल्स, और लेआउट्स हों।
इस तरह, हम गारंटी देते हैं कि हमारा उदाहरण रेल्स इंजन्स का सबसे अधिक पता लगाता है। views/notes_haml और views/notes_slim दोनों के लिए समकक्ष फाइलें बनाना सुनिश्चित करें।
आइए index.html.erb कोड से शुरू करें:
<style>
h2 { text-align: center; }
table, td, th { border: 1px solid #ddd; text-align: left; }
table { border-collapse: collapse; width: 80%; margin: auto; }
th, td { padding: 15px; }
</style>
<h2>List of Notes</h2>
<table>
<thead>
<tr>
<th>Title</th>
<th>Description</th>
<th>Tasks</th>
</tr>
</thead>
<tbody>
<%= render partial: 'notes_erb/note', collection: @notes %>
</tbody>
</table>
यहां कुछ खास नहीं है। ध्यान दें कि हम एक पार्शियल, _note.html.erb फाइल आयात कर रहे हैं, और एक collection पैरामीटर पास कर रहे हैं: हमारा @notes जो पहले कंट्रोलर में बनाया गया था।
यहाँ नोट की सामग्री है, वैसे:
<tr>
<td>
<span><%= note.title %></span>
</td>
<td>
<span><%= note.description %></span>
</td>
<td>
<ul>
<%= render partial: 'notes_erb/task', collection: note.tasks %>
</ul>
</td>
</tr>
यहाँ एक और पार्शियल है, इस बार tasks सरणी तक पहुँच रहा है।
_task.html.erb के लिए सामग्री निम्नलिखित है:
<li><%= task.title %></li>
HAML के व्यूज़
आप देखेंगे कि एक इंजन से दूसरे में सिंटैक्स बहुत समान है। जो बदलता है वह प्रत्येक की वर्बोसिटी है। उदाहरण के लिए, SLIM उनमें से सबसे साफ है।
तीन फाइलों के कोड पर एक नज़र डालें:
# Content of index.html.haml
:css
h2 { text-align: center; }
table, td, th { border: 1px solid #ddd; text-align: left; }
table { border-collapse: collapse; width: 80%; margin: auto; }
th, td { padding: 15px; }
%h2 List of Notes
%table
%thead
%tr
%th Title
%th Description
%th Tasks
%tbody
= render partial: 'notes_haml/note', collection: @notes
# Content of _note.html.haml
%tr
%td
%span= note.title
%td
%span= note.description
%td
%ul
= render partial: 'notes_haml/task', collection: note.tasks
# Content of _task.html.haml
%li= task.title
बहुत समान, है ना?
SLIM के व्यूज़
अंत में, हमारे पास SLIM के व्यूज़ हैं। यहाँ अन्य दो से सबसे बड़ा अंतर है। पूरी संरचना स्पष्ट हो जाती है:
# index.html.slim
css:
h2 { text-align: center; }
table, td, th { border: 1px solid #ddd; text-align: left; }
table { border-collapse: collapse; width: 80%; margin: auto; }
th, td { padding: 15px; }
h2 List of Notes
table
thead
tr
th Title
th Description
th Tasks
tbody
= render partial: 'notes_haml/note', collection: @notes
# _note.html.slim
tr
td
span= note.title
td
span= note.description
td
ul
= render partial: 'notes_haml/task', collection: note.tasks
# _task.html.slim
li= task.title
आपको प्रत्येक संबंधित इंजन सिंटैक्स में लेआउट्स का अनुवाद भी करना होगा। views/layouts फोल्डर के तहत दो नई फाइलें बनाई जानी हैं: application.html.haml और application.html.slim।
मैं उस काम को आपके लिए होमवर्क के रूप में छोड़ दूंगा। हालांकि, यदि आपको यह कठिन लगता है, तो आप लेख के अंत में उपलब्ध GitHub प्रोजेक्ट लिंक में मेरा संस्करण देख सकते हैं।
टेस्ट चलाना
अंत में, हम उदाहरण का परीक्षण कर सकते हैं। पहले, rails s कमांड चलाकर एप्लिकेशन शुरू करें। यह https://localhost:3000/ पते पर शुरू होगा।
यहाँ व्यू कैसा दिखेगा:
प्रत्येक टेम्पलेट इंजन उदाहरण config/routes.rb फाइल में ऑटो-जेनरेटेड अपने संबंधित URL पर उपलब्ध होगा।
इन उदाहरणों को बेंचमार्क टेस्ट करने के लिए, हम hey बेंचमार्क टूल का उपयोग करेंगे। यह बहुत सरल है और बेंचमार्क विश्लेषण के लिए कुछ उपयोगी जानकारी प्रदान करता है। ये कमांड हैं:
$ hey https://localhost:3000/notes_erb/index
Summary:
Total: 9.3978 secs
Slowest: 9.1718 secs
Fastest: 0.0361 secs
Average: 1.2714 secs
Requests/sec: 21.2816
$ hey https://localhost:3000/notes_haml/index
Summary:
Total: 10.8661 secs
Slowest: 10.2354 secs
Fastest: 0.1871 secs
Average: 1.4735 secs
Requests/sec: 18.4058
$ hey https://localhost:3000/notes_slim/index
Summary:
Total: 11.3384 secs
Slowest: 10.7570 secs
Fastest: 0.0437 secs
Average: 1.5406 secs
Requests/sec: 17.6392
जैसा कि आप देख सकते हैं, सभी इंजन निष्पादन समय के मामले में बहुत करीब हैं। चलाने के लिए डिफ़ॉल्ट अनुरोधों की संख्या 200 है, लेकिन आप -n विकल्प के माध्यम से इस मान को बदल सकते हैं।
आइए 1200 अनुरोधों के साथ किए गए उन्हीं परीक्षणों पर एक नज़र डालें:
$ hey -n 1200 https://localhost:3000/notes_erb/index
Summary:
Total: 52.2586 secs
Slowest: 19.2837 secs
Fastest: 0.0389 secs
Average: 0.6960 secs
Requests/sec: 22.9627
$ hey -n 1200 https://localhost:3000/notes_haml/index
Summary:
Total: 61.7637 secs
Slowest: 18.5290 secs
Fastest: 0.0442 secs
Average: 0.8557 secs
Requests/sec: 19.4289
$ hey -n 1200 https://localhost:3000/notes_slim/index
Summary:
Total: 63.1625 secs
Slowest: 19.9744 secs
Fastest: 0.0874 secs
Average: 0.7959 secs
Requests/sec: 18.9986
जब आप समवर्ती अनुरोधों की संख्या बढ़ाते हैं, तो आप कुल और औसत प्रसंस्करण समय में अंतर बढ़ते हुए देखेंगे। जाहिर है, हजारों समानांतर अनुरोधों वाला यह परिदृश्य बहुत विशिष्ट है और बहुत आम नहीं है। हालांकि, लोड परीक्षण यही है, एंडपॉइंट्स को उनकी सीमा तक ले जाना।
hey टूल अन्य जानकारी भी प्रिंट करता है, जैसे प्रतिक्रिया समय हिस्टोग्राम:
यह अनुमानित शब्दों में प्रत्येक अनुरोध को पूरा करने में लगे औसत समय को दर्शाता है। हमारे उदाहरण में, यह स्पष्ट है कि अधिकांश अनुरोध (1048) 1.893 सेकंड में पूरे हुए। यही कारण है कि एक ही समय में स्ट्रेस टेस्ट करना वांछनीय है।
विलंबता वितरण, DNS डायलअप और लुकअप, अनुरोध लेखन, प्रतीक्षा और पढ़ने के समय, त्रुटियों आदि के बारे में भी अधिक जानकारी है।
अधिक कस्टम विकल्पों/परिणामों के लिए डॉक्स देखें।
सारांश
आप इस उदाहरण के लिए सोर्स कोड यहां पा सकते हैं।
इस तरह का टेस्ट यह परिभाषित करने के लिए बहुत अच्छा है कि कौन सा टेम्पलेट इंजन आपकी प्रोजेक्ट आवश्यकताओं के लिए अधिक उपयुक्त हो सकता है। जैसा कि हमने देखा है, खराब कार्यान्वित कोड से सावधान रहें क्योंकि कुछ छोटे कोड स्निपेट्स आपके निष्पादन के समग्र प्रदर्शन को अचानक बदल सकते हैं।
एक और दिलचस्प बिंदु यह है कि ERB, डिफ़ॉल्ट रेल्स इंजन के रूप में, अपने काम में बहुत अच्छा है। अन्य इंजन्स हमारे कुछ परीक्षणों में तेज़ होने के बावजूद, ERB हमेशा अपना मूल्य साबित करने के लिए पर्याप्त करीब होता है।
अंत में, मैं सिफारिश करूंगा कि आप टेस्ट में कुछ अन्य महत्वपूर्ण कारकों पर विचार करें, जिसमें कैशिंग, प्रॉक्सी, डेटाबेस का उपयोग, और अन्य स्टोरिंग मैकेनिज्म, साथ ही क्यूज और एसिंक्रोनस प्रकृति का कोई ऐसा टूल शामिल है। ये आइटम हमेशा आपके व्यूज़ के व्यवहार या उन्हें रेंडर करने में लगने वाले प्रसंस्करण समय में महत्वपूर्ण भूमिका निभाते हैं। शुभकामनाएं!
