এই আর্টিকেলে, আমরা তিনটি সবচেয়ে জনপ্রিয় রুবি টেমপ্লেটিং ইঞ্জিনের পারফরম্যান্স টেস্ট ও বিশ্লেষণ করব: ERB (ডিফল্ট), HAML, এবং SLIM।
বেঞ্চমার্কিং হলো বিজনেস প্রসেস এবং পারফরম্যান্স মেট্রিক্সকে ইন্ডাস্ট্রি বেস্ট প্র্যাক্টিস এবং অন্য কোম্পানির বেস্ট প্র্যাক্টিসের সাথে তুলনা করার প্রক্রিয়া। একই সময়ে, লোড টেস্টিং হলো একটি সিস্টেমে ডিমांड সৃষ্টি করে এর রেসপন্স মাপার প্রক্রিয়া।
আমাদের লক্ষ্য হলো রুবির Benchmark মডিউল এক্সপ্লোর করা, যেটি রুবি কোড এক্সিকিউট করার সময় মাপার এবং রিপোর্ট করার মেথড দেয়। আমরা কিছু ইনলাইন টেমপ্লেট তৈরি করব, তাদের টেস্টের বিরুদ্ধে রান করব, এবং তিনটি ভিন্ন ইঞ্জিনের মেট্রিক্স এক্সট্রাক্ট করব।
তারপর, আমরা লোড টেস্টিং-এ ডুব দিব কিছু রিয়েল-ওয়ার্ল্ড টেমপ্লেট ভিউ তৈরি করে, সেগুলো সার্ভারে লাইভ করিয়ে, এবং hey টুল দিয়ে লোড টেস্ট পারফর্ম করব। এটি একটি স্পেসিফিক ওয়েব অ্যাপ্লিকেশনে লোড পাঠাতে এবং প্রতিটি এন্ডপয়েন্ট এবং তদনुसারে প্রতিটি টেমপ্লেট ইঞ্জিন কীভাবে পারফর্ম করছে সেটি সম্পর্কে विस्तারিত ডেটা দেয়।
সেটআপ
প্রথম কাজ হলো নিশ্চিত করা যে আপনার সিস্টেমে রুবি ইনস্টলড আছে। আমরা লিখতে এই আর্টিকেল 쓰는 시점에서 সবচেয়ে রিসেন্ট ভার্সন ২.৭.০ ব্যবহার করছি। Rails জেমও ইনস্টল করতে হবে।
রুবি এবং Rails জেম—প্রোজেক্ট শুরু করার জন্য এটাও প্রায় যথেষ্ট। এই টিউটোরিয়ালে Visual Studio Code আইডিই হিসেবে ব্যবহার করা হয়েছে, কিন্তু আপনি অন্য যেকোনো পছন্দ করুন।
এখন, আমাদের Rails প্রজেক্টের জন্য একটি ফোল্ডার বেছে নিন এবং নিচের কমান্ড চালান:
rails new haml-slim-erb
এটি সকল প্রয়োজনীয় ডিপেন্ডেন্সি ডাউনলোড করে আমাদের স্ক্যাফোল্ডেড Rails প্রজেক্ট তৈরি করবে। জোন্নো এক্সপ্লোর করুন।
কোডে যাওয়ার আগে, আমাদের Gemfile-এ SLIM এবং HAML ডিপেন্ডেন্সি যোগ করতে হবে:
group :development, :test do
# Call 'byebug' anywhere in the code to stop execution and get a debugger console
gem 'byebug', platform: :mri
gem 'haml'
gem 'slim'
end
প্রজেক্টের সাথে ডিফল্টভাবে একটি বাগ আছে যা SQLite ভার্সন সংক্রান্ত। Gemfile-এ সেটি খুঁজে বের করে নিচের মত করে পরিবর্তন করুন:
gem 'sqlite3', '~> 1.3.0'
এখন, ডিপেন্ডেন্সি ডাউনলোড করার জন্য bundle install কমান্ড চালান।
Benchmark মডিউল এক্সপ্লোর
আর্টিকেলের এই অংশে, আমরা সরাসরি 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
}
লক্ষ্য করুন প্রথম লাইনে Benchmark মডিউল ইম্পোর্ট করা হয়েছে। তারপর, ০ থেকে ৫০ পর্যন্ত র্যান্ডম সংখ্যার একটি অ্যারে জেনারেট করা হয়েছে ১০,০০০ সাইজের। এই বড় সংখ্যাগুলো কেবল প্রসেসিং-এ সময় নিতে।
measure মেথড খুব উপকারী কারণ এটি আপনার রুবি কোডের যেকোনো জায়গায় রাখা যায় প্রসেসিং-এ কত সময় লাগছে সেটি মাপতে। এই সময় রিটার্ন হয় এবং puts দিয়ে প্রিন্ট হয়।
ভিতরে, আমরা ২০k বার একই র্যান্ডম-জেনারেটেড অ্যারেকে এক্সিকিউট করছি একটি ভ্যালু অন্যটি দিয়ে গুণ করার জন্য।
এই স্পেসিফিক টেস্ট ফাইল রান করতে নিচের কমান্ড দিন:
rake test TEST=test/benchmark/example_1_test.rb
ফলাফল এমন দেখতে পারে:
0.702647 0.012353 0.715000 ( 0.721910)
এই রিপোর্টে যথাক্রমে ইউজার CPU টাইম, সিস্টেম CPU টাইম, ইউজার এবং সিস্টেম CPU টাইমের যোগফল, এবং এলapsed রিয়েল-টাইম প্রিন্ট হয়। টাইমের ইউনিট সেকেন্ড।
আমরা Benchmark-এর অন্যান্য মেথডগুলো পরে প্র্যাক্টিসে ব্যবহার করব।
ইনলাইন টেমপ্লেট টেস্টিং
রুবির Benchmark মডিউল কীভাবে কাজ করে সেটি কিছুটা বুঝলে, আমরা তিনটি টেমপ্লেটের ওপর কিছু টেস্ট এক্সিকিউট করব।
এজন্য, আমরা একটি একক টেমপ্লেট তৈরি করব, এটিকে তিনটি ইঞ্জিনের সিনট্যাক্সে অনুবাদ করব, এবং نهایتত Benchmark মেথডের অধীনে রান করব।
দ্বিতীয় টেস্ট ফাইলে নিচের কন্টেন্ট যোগ করুন:
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
<%= notes.title %>
<%= notes.description %>
<% notes.randomList.each do |note| %>
<%= note %>
<% end %>
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 মেথড ব্যবহার করছি, যা প্রথম মেথড চেয়ে কিছু বেশি করে। কখনো কখনো বেঞ্চমার্ক রেজাল্ট বাহ্যিক ফ্যাক্টর যেমন গার্বেজ কালেকশন, মেমরি লিক ইত্যাদির কারণে skew হতে পারে। এই মেথড টেস্ট দুবার রান করে এই ইফেক্ট মিনিমাইজ করার চেষ্টা করে: প্রথমবার রিয়ার্সাল হিসেবে রানটাইম এনভায়রনমেন্ট স্ট্যাবল করতে এবং দ্বিতীয়বার রিয়েল টেস্ট জন্য। এতে সম্পর্কে আরো জানতে এখানে ক্লিক করুন।
অবশেষে, bmbm-এর প্রতিটি ইনার কোড লাইন ২০০০ বার লুপ এক্সিকিউট করে প্রতিটি টেমপ্লেট তৈরির সময়। ফোকাস টেমপ্লেট অ্যাসাইন এবং রেন্ডারিং-এ।
এই টেস্ট ফাইল এক্সিকিউট করার পর রেজাল্ট:
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)
লক্ষ্য করুন এখন কোনটি সেরা এবং কোনটি সবচেয়ে খারাপ। এটি শুধু দেখানোর জন্য যে কোনো পারফেক্ট ইঞ্জিনের ক্ষেত্রে সিল्वर বুলেট নেই।
আপনাকে টেস্ট এবং বিশ্লেষণ করতে হবে আপনার কোডিং স্টাইলের জন্য কোন ফিচারগুলো ভালো পারফর্ম করে। এছাড়া, Ruby Profiler-এর মত অন্যান্য অক্সিলিয়ারি টুলসও আছে যেগুলো ব্যবহার করে আপনি আরও ভালোভাবে বুঝতে পারেন কীভাবে এবং কেন কোডটি এইভাবে behave করছে।
লোড টেস্টিং: একটি রিয়েল-ওয়ার্ল্ড সিনেরিও
আমাদের বাস্তবতার কাছে কিছু করीব যাই। আমরা একটি রিয়েল টেমপ্লেট বেঞ্চমার্ক করব যেটি কিছু নোট লিস্ট করে (প্রতিটি টেমপ্লেট ইঞ্জিনের জন্য একটি করে)।
যেহেতু benchmark মডিউল Rails কোডের ভিতরে কাজ করে, আমরা টেমপ্লেট ইঞ্জিনের অভ্যন্তরীণ প্রসেস সংক্রান্ত কিছু গুরুত্বপূর্ণ মেজারমেন্ট হারাই ফেলি।
এই টাইপের বেঞ্চমার্ক টেস্ট আমাদের দেখতে দেয় প্রতিটি ইঞ্জিন সমগ্ররূপে কীভাবে পারফর্ম করে, রিকোয়েস্ট আসার শুরু থেকে, বিজনেস লজিক প্রসেসিং পর্যন্ত, রেসপন্স ডেটা ভিউএ পৌঁছানোর পর্যন্ত। এই শেষটা, বিশেষ করে, একাধিক স্টেপ ধারণ করে, যেমন পারসিং এবং রেন্ডারিং প্রসেস যা লোড টেস্ট মাপতে পারে, কিন্তু benchmark মাপতে পারে না।
প্রথমে, প্রতিটি উদাহরণের জন্য Rails কন্ট্রোলার তৈরি করি:
rails g controller notes_erb index
rails g controller notes_haml index
rails g controller notes_slim index
এই কমান্ডটি আপনার পরিচিত কিছু সাধারণ Rails ফাইল অটো-জেনারেট করবে।
এরপর, তৈরি হওয়া 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
অনুগ্রহ করে এলিপসিস (...) কে আরও নোট এলিমেন্ট스로 পরিবর্তন করুন। প্লাস, অন্য কন্ট্রোলারগুলোর লজিকও রেপ্লিকেট করুন।
ERB ভিউ তৈরি
এখন, আমাদের উদাহরণের ভিউগুলো তৈরি করার番. এর জন্য, views/notes_erb ফোল্ডারে যান এবং দুইটি ফাইল তৈরি করুন: note.html.erb এবং task.html.erb। এগুলো আমাদের একটি উদাহরণ বানাতে সাহায্য করবে যেটি ভিউ, পারশিয়াল, এবং লেআউট ধারণ করে।
এভাবে, আমরা নিশ্চিত করি আমাদের উদাহরণ Rails ইঞ্জিনগুলো সবচেয়ে বেশি এক্সপ্লোর করেছে। views/notes_haml এবং views/notes_slim-এর জন্য সমতুল্য ফাইলগুলো তৈরি করতে ভুলবেন না।
index.html.erb কোড দিয়ে শুরু করি:
List of Notes
Title
Description
Tasks
<%= render partial: 'notes_erb/note', collection: @notes %>
এখানে কিছু খাস নেই। লক্ষ্য করুন, আমরা একটি পারশিয়াল ইম্পোর্ট করছি, _note.html.erb ফাইলটি, এবং একটি collection প্যারামিটার পাস করছি: আমাদের পূর্বে তৈরি @notes।
নোটের কন্টেন্টটি:
<%= note.title %>
<%= note.description %>
<%= render partial: 'notes_erb/task', collection: note.tasks %>
এখানেও আরেকটি পারশিয়াল, এইবার tasks অ্যারে এক্সেস করছে।
_task.html.erb-এর কন্টেন্ট:
<%= task.title %>
HAML-এর ভিউ
আপনি লক্ষ্য করবেন একটি ইঞ্জিন থেকে অন্যর সিনট্যাক্স খুব সিমিলার। পার্থক্য শুধু প্রতিটির verbosity-তে। 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/ এ স্টার্ট হবে।
ভিউটি এরকম দেখাবে:
প্রতিটি টেমপ্লেট ইঞ্জিন উদাহরণ তার নিজস্ব URL-এ উপলব্ধ থাকবে যা config/routes.rb ফাইলে অটো-জেনারেট হয়েছে।
এই উদাহরণগুলো বেঞ্চমার্ক টেস্ট করার জন্য, আমরা 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
আপনি দেখতে পাচ্ছেন, সব ইঞ্জিন এক্সিকিউশন টাইমের দৃষ্টিতে খুব কাছাকাছি। ডিফল্ট রিকোয়েস্ট সংখ্যা ২০০, কিন্তু আপনি -n অপশন দিয়ে এটা পরিবর্তন করতে পারেন।
এখন ১২০০ রিকোয়েস্টে একই টেস্টগুলো দেখি:
$ 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 টুল অন্যান্য ইনফোও প্রিন্ট করে, যেমন রেসপন্স টাইম হিস্টোগ্রাম:
এটি দেখায় প্রতিটি রিকোয়েস্ট কত গড় সময় নিল সম্পূর্ণ হওয়ায় সन्नিকটভাবে। আমাদের উদাহরণে, স্পষ্ট যে অধিকাংশ রিকোয়েস্ট (১০৪৮) ১.৮৯৩ সেকেন্ডে সম্পন্ন হয়েছে। এই জন্য স্ট্রেস টেস্ট একই সাথে করা দরকার।
লেটেন্সি ডিস্ট্রিবিউশন, DNS ডায়ালআপ এবং লুকআপ, রিকোয়েস্ট রাইটিং, ওয়েটিং এবং রিডিং টাইম, এরর ইত্যাদি সম্পর্কে আরও ইনফো আছে।
ডক্স চেক করুন আরও কাস্টম অপশন/রেজাল্টের জন্য।
সারসংক্ষেপ
এই উদাহরণের সোর্স কোড এখানে পাবেন।
এই ধরনের টেস্ট আপনার প্রজেক্টের প্রয়োজনের জন্য কোন টেমপ্লেট ইঞ্জিন বেশি উপযুক্ত সেটি নির্ধারণ করতে খুব সাহায্য করে। যেমন আমরা দেখেছি, খুব খারাপ ইমপ্লিমেন্টেশন কোডের কারণে কিছু ছোট কোড স্নিপেট আপনার এক্সিকিউশনের সামগ্রিক পারফরম্যান্সে আকস্মিক পরিবর্তন আনতে পারে।
একটি আরো আকর্ষণীয় বিষয় হলো ERB, ডিফল্ট Rails ইঞ্জিন হিসেবে, তার কাজে খুব ভালো। অন্য ইঞ্জিনগুলো আমাদের কিছু টেস্টে ফাস্টার হলেও, ERB সবসময় পর্যাপ্ত কাছে থাকে তার মান প্রুভ করার জন্য।
শেষে, আমি সুপারিশ করব আপনি টেস্টের সাথে কিছু অন্যান্য গুরুত্বপূর্ণ ফ্যাক্টর বিবেচনা করুন হোমওয়ার্ক হিসেবে, যার মধ্যে ক্যাশিং, প্রক্সি, ডাটাবেস ব্যবহার, এবং অন্যান্য স্টোরিং মেকানিজম, সেইসাথে কিউ এবং যেকোনো অ্যাসিঙ্ক্রোনাস নেচারের টুল। এই আইটেমগুলো সবসময় আপনার ভিউগুলো কীভাবে behave করে বা সেগুলো রেন্ডার করার জন্য কত প্রসেসিং টাইম লাগে সেটিতে গুরুত্বপূর্ণ ভূমিকা পালন করে। শুভকামনা!
