VPS পারফরম্যান্স বেঞ্চমার্ক করার সঠিক নিয়ম

VPS বেঞ্চমার্ক করার অর্থ কী

একটি VPS বেঞ্চমার্ক করার সময় আপনি চারটি বিষয় পরিমাপ করেন: একটি একক CPU কোর কত দ্রুত কাজ করে, মেশিনে মেমোরি ব্যান্ডউইথ কতটা আছে, স্টোরেজ প্রতি সেকেন্ডে কতগুলো ছোট র‍্যান্ডম ডিস্ক অপারেশন সম্পন্ন করতে পারে এবং নেটওয়ার্ক লিঙ্ক কতটুকু থ্রুপুট প্রদান করে। yabs.sh একবার চালালে প্রায় দশ মিনিটের মধ্যে আপনি এই চারটি তথ্যই পেয়ে যাবেন। ফলাফল বিশ্লেষণ করাটা তুলনামূলক কঠিন, কারণ একটি VPS (ভার্চুয়াল প্রাইভেট সার্ভার) অন্যান্য ব্যবহারকারীর সাথে একই ফিজিক্যাল হার্ডওয়্যার শেয়ার করে। ফলে একই মেশিন 03:00 টায় এক ধরনের ফলাফল দিতে পারে এবং 20:00 টায় সম্পূর্ণ ভিন্ন ফলাফল দেখাতে পারে।

এখানে পরিকল্পনা হলো, দ্রুত একটি ধারণা পাওয়ার জন্য yabs.sh চালানো এবং এরপর এর অন্তর্গত টুলগুলো নিজে হাতে চালানো। আপনি যখন নিজে এগুলো চালাবেন, তখন একটি ফ্ল্যাগ পরিবর্তন করে সংখ্যার পরিবর্তন পর্যবেক্ষণ করতে পারবেন এবং সংখ্যাটি আসলে কী পরিমাপ করছে তা বুঝতে পারবেন। মেশিন সেটআপ করার পর এটি করুন, আগে নয়। নতুন VPS-এ প্রথম দশ মিনিট-এর ধাপগুলো আগে সম্পন্ন করতে হবে, কারণ যে মেশিনে তখনো প্রথম দফার আপডেট চলছে, তার বেঞ্চমার্ক ফলাফল খারাপ আসবে, যার সাথে হার্ডওয়্যারের কোনো সম্পর্ক নেই।

পরিমাপ করার আগে মেশিনটি পর্যবেক্ষণ করুন

প্রতিটি ভুল বেঞ্চমার্কের অর্ধেক কারণ হলো এমন একটি মেশিন যা সম্পর্কে লেখক অবগত ছিলেন না।

nproc
lscpu | grep -E 'Model name|Hypervisor|Thread'
free -h
df -hT /
uname -r
systemd-detect-virt

Hypervisor vendor: KVM মানে সম্পূর্ণ ভার্চুয়ালাইজেশন, তাই আপনি আপনার নিজস্ব কার্নেল চালান। systemd-detect-virt-এ lxc বা openvz প্রিন্ট হওয়ার মানে হলো কন্টেইনার ভার্চুয়ালাইজেশন: আপনি হোস্ট কার্নেল শেয়ার করছেন এবং আপনার CPU ও মেমরির সীমা ভার্চুয়াল হার্ডওয়্যারের পরিবর্তে cgroup (কন্ট্রোল গ্রুপ) সেটিংস দ্বারা নিয়ন্ত্রিত। একটি cgroup v2 সিস্টেমে আপনি সরাসরি CPU সীমা পড়তে পারবেন।

cat /sys/fs/cgroup/cpu.max

max 100000 মানে কোনো কোটা নেই। 200000 100000 মানে আপনি প্রতি 100000 মাইক্রোসেকেন্ড পিরিয়ডে 200000 মাইক্রোসেকেন্ড CPU ব্যবহার করতে পারবেন, যা দুটি কোরের কোটার সমান। যে প্ল্যানটি 4 vCPU হিসেবে বিজ্ঞাপন দেওয়া হয় কিন্তু যার কোটা দুটি কোরের, তা কখনোই চারটি কোরের মতো পারফরম্যান্স দেবে না এবং কোনো বেঞ্চমার্ক টুল আপনাকে এর কারণ জানিয়ে কোনো লাইন প্রিন্ট করবে না।

df -hT / অন্য একটি কারণে গুরুত্বপূর্ণ: Type কলামটি। যদি এটি overlay দেখায়, তবে আপনি একটি কন্টেইনারের ভেতরে আছেন এবং নিচের ডিস্ক টেস্টটিতে পরিবর্তন প্রয়োজন। এটি এখনই নোট করে রাখুন।

সব সময় স্টিল টাইম (steal time) পর্যবেক্ষণ করুন

স্টিল টাইম হলো আপনার ভার্চুয়াল CPU-এর সেই সময়ের অংশ, যখন এটি চলার জন্য প্রস্তুত ছিল কিন্তু হাইপারভাইজার সেই ফিজিক্যাল কোর অন্য কাউকে বরাদ্দ করেছিল। এটি সবচেয়ে কার্যকর একক সংকেত যা নির্দেশ করে যে, কোনো ফলাফল আপনার হার্ডওয়্যারের কারণে নয়, বরং আপনার প্রতিবেশীদের কারণে হচ্ছে।

vmstat 1 10

ডানদিকের st কলামটি দেখুন। একটি স্থিতিশীল 0 বা 1 স্বাভাবিক। 5-এর উপরে দীর্ঘস্থায়ী মান নির্দেশ করে যে হোস্টটি সেই মুহূর্তে অতিরিক্ত সাবস্ক্রাইবড (oversubscribed), তাই সেই উইন্ডোতে আপনার রেকর্ড করা প্রতিটি CPU সংখ্যা আপনার মেশিনের কোনো ত্রুটি ছাড়াই কম দেখাচ্ছে। top, CPU লাইনে %st-এর মতো একই সংখ্যা প্রদর্শন করে। বেঞ্চমার্ক করার সময় দ্বিতীয় একটি SSH সেশনে vmstat 1 চালু রাখুন এবং প্রতিটি ফলাফলের পাশে স্টিল ফিগারটি লিখে রাখুন।

yabs.sh দিয়ে শুরু করুন

yabs.sh (Yet Another Bench Script) হলো একটি শেল স্ক্রিপ্ট যা স্ট্যাটিক fio, iperf3 এবং Geekbench বাইনারি ডাউনলোড করে, সেগুলো রান করে এবং একটি সারসংক্ষেপ প্রদর্শন করে। এটি VPS বেঞ্চমার্ক আলোচনার সাধারণ ভাষা, তাই অন্য কারো সাথে ফলাফল তুলনা করার দ্রুততম উপায় হলো yabs আউটপুট।

প্রকল্পটির নিজস্ব ওয়ান-লাইন কমান্ডটি নিচে দেওয়া হলো।

curl -sL yabs.sh | bash

এটি URL-এ বর্তমানে যা আছে তা সরাসরি একটি শেলে পাইপ করে। এটি ডাউনলোড করুন, পড়ুন, তারপর রান করুন।

curl -sLo yabs.sh https://raw.githubusercontent.com/masonr/yet-another-bench-script/master/yabs.sh
less yabs.sh
bash yabs.sh

পাইপ করার সময় -s ---এর পরে অথবা লোকাল কপি রান করার সময় ফাইলের নামের ঠিক পরেই ফ্ল্যাগগুলো ব্যবহার করতে হয়। প্রয়োজনীয় ফ্ল্যাগগুলো হলো: -f ডিস্ক টেস্ট বাদ দেয়, -i নেটওয়ার্ক টেস্ট বাদ দেয়, -g Geekbench বাদ দেয়, -r iperf3 লোকেশনের সংখ্যা কমিয়ে দুইটিতে নিয়ে আসে, -j ফলাফল JSON ফরম্যাটে প্রিন্ট করে এবং -w results.json সেই JSON একটি ফাইলে লিখে রাখে।

bash yabs.sh -r -w yabs-run1.json

প্রথমবার রান করার আগে দুটি বিষয় জেনে রাখা প্রয়োজন। Geekbench আপনার ফলাফল আপলোড করে এবং একটি পাবলিক browser.geekbench.com URL প্রদান করে, তাই এই লিঙ্কের অধিকারী যে কেউ আপনার CPU মডেল এবং স্কোর দেখতে পারবে। -g এই টেস্টটি সম্পূর্ণভাবে বাদ দেয়। দ্বিতীয়ত, iperf3 ধাপটি বিভিন্ন অঞ্চলের সার্ভারে প্রকৃত ট্রাফিক পাঠায় এবং এটি আপনার মাসিক ব্যান্ডউইথ ব্যবহারের অন্তর্ভুক্ত হয়। 1 Gbit/s লিঙ্কে একটি পূর্ণ নেটওয়ার্ক ধাপ কয়েক গিগাবাইট ডেটা খরচ করতে পারে, তাই সীমিত ব্যান্ডউইথের ক্ষেত্রে -r এবং মিটারড লিঙ্কের ক্ষেত্রে -i ব্যবহার করুন।

yabs আউটপুটের প্রতিটি অংশের অর্থ

ডিস্ক সেকশনটি 4k, 64k, 512k এবং 1m এই চারটি ব্লক সাইজে 50/50 রিড এবং রাইট মিক্স ব্যবহার করে fio চালায়। এটি প্রতিটির জন্য IOPS (প্রতি সেকেন্ডে ইনপুট/আউটপুট অপারেশন) এবং ব্যান্ডউইথ রিপোর্ট করে। ডাটাবেস, মেইল সার্ভার বা অনেক ছোট রাইট অপারেশন করে এমন যেকোনো কিছুর জন্য 4k সারিটি গুরুত্বপূর্ণ, কারণ বেশিরভাগ সার্ভার IO ছোট এবং বিক্ষিপ্ত হয়। 1m সারিটি ব্যাকআপ এবং ভিডিওর জন্য, যেখানে আপনি দীর্ঘ বাইট রান স্থানান্তর করেন।

নেটওয়ার্ক সেকশনটি প্যারালাল স্ট্রিম ব্যবহার করে বিভিন্ন অঞ্চলের পাবলিক সার্ভারের বিপরীতে উভয় দিকে iperf3 চালায়। এখানে কম সংখ্যাকে উত্তরের পরিবর্তে একটি প্রশ্ন হিসেবে বিবেচনা করুন, কারণ পাবলিক iperf3 সার্ভারগুলো শেয়ার করা থাকে এবং প্রায়শই স্যাচুরেটেড থাকে, তাই খারাপ ফলাফলের কারণ অপর প্রান্তের সার্ভারটিও হতে পারে।

Geekbench সেকশনটি একটি সিঙ্গেল কোর স্কোর এবং একটি মাল্টি কোর স্কোর প্রদান করে। সিঙ্গেল কোর স্কোর একটি রিকোয়েস্ট, একটি কম্পাইল বা একটি কুয়েরি কত দ্রুত সম্পন্ন হবে তার পূর্বাভাস দেয়। মাল্টি কোর স্কোর মূলত আপনার প্রকৃতপক্ষে কয়টি কোর আছে তা নির্দেশ করে।

Disk: নিজে fio চালান

fio (flexible IO tester) হলো yabs ডিস্ক সেকশনের মূল টুল, এবং সরাসরি এটি ব্যবহার করলেই ফ্ল্যাগগুলোর প্রকৃত অর্থ বোঝা যায়।

sudo apt update && sudo apt install -y fio sysbench iperf3

আপনার প্রয়োজনীয় ফাইলসিস্টেমে কিউ ডেপথ 32-এ একটি 4k র‍্যান্ডম রিড টেস্ট:

fio --name=randread4k --filename=./fio-testfile --size=2G --bs=4k \
  --rw=randread --ioengine=libaio --iodepth=32 --direct=1 \
  --runtime=60 --time_based --group_reporting

আউটপুট থেকে যে সামারি লাইনটি পড়তে হবে তা দেখতে এরকম।

read: IOPS=184k, BW=719MiB/s (754MB/s)(42.1GiB/60001msec)

এর নিচে fio একটি clat percentiles ব্লক প্রিন্ট করে। 99.00তম পার্সেন্টাইল হলো সেই সংখ্যা যা উল্লেখ করার মতো, কারণ এটি নির্দেশ করে প্রতি একশটি রিকোয়েস্টের মধ্যে সবচেয়ে ধীরগতির রিকোয়েস্টটি কতক্ষণ অপেক্ষা করেছে। গড় ল্যাটেন্সি (average latency) সেই স্টলগুলোকে আড়াল করে যা একজন ব্যবহারকারী সরাসরি অনুভব করেন।

• --direct=1 ফাইলটিকে O_DIRECT দিয়ে ওপেন করে, ফলে রিড অপারেশনগুলো কার্নেল পেজ ক্যাশ এড়িয়ে চলে। এটি ছাড়া, 8G র‍্যামের মেশিনে 2G ফাইলের ওপর দ্বিতীয়বার চালানো টেস্টটি মেমোরি থেকে সার্ভ হবে এবং fio মিলিয়ন সংখ্যক IOPS রিপোর্ট করবে। সেই সংখ্যাটি বাস্তব, তবে তা মেমোরির পারফরম্যান্স।
• --ioengine=libaio অ্যাসিনক্রোনাস রিকোয়েস্ট সাবমিট করে, যা --iodepth=32-কে একসাথে 32টি রিকোয়েস্ট প্রসেস করতে দেয়। psync-এর মতো সিনক্রোনাস ইঞ্জিনের ক্ষেত্রে, iodepth 1-এর বেশি হলে কোনো কাজ হয় না, তাই আপনি প্রতিবার একটি করে রিকোয়েস্ট পরিমাপ করেন।
• --time_based --runtime=60 নির্দিষ্ট কাজের পরিমাণের পরিবর্তে 60 সেকেন্ডের জন্য চলে, ফলে একটি দ্রুতগতির ডিস্ক এবং একটি ধীরগতির ডিস্ক একই সময় পায় এবং তুলনাটি নিরপেক্ষ থাকে।
• --size=2G টেস্ট ফাইলের আকার নির্ধারণ করে। এটিকে পাথের যেকোনো ক্যাশের চেয়ে বড় রাখুন এবং আগে নিশ্চিত হয়ে নিন যে আপনার কাছে পর্যাপ্ত ফ্রি স্পেস আছে।

র‍্যান্ডম রাইট টেস্টের জন্য --rw=randwrite ফ্ল্যাগসহ একই কমান্ড ব্যবহার করুন। এটি আলাদাভাবে চালান এবং তারপর ফাইলটি ডিলিট করে দিন।

fio --name=randwrite4k --filename=./fio-testfile --size=2G --bs=4k \
  --rw=randwrite --ioengine=libaio --iodepth=32 --direct=1 \
  --runtime=60 --time_based --group_reporting
rm -f ./fio-testfile

বাস্তব ট্রাফিকের কাছাকাছি মিশ্রণের জন্য --rw=randrw --rwmixread=70 ব্যবহার করুন। আপনি কোন ধরনের স্টোরেজ ব্যবহার করছেন তা যেকোনো ফ্ল্যাগের চেয়ে বেশি ফলাফল পরিবর্তন করে, এবং এই পার্থক্যটি VPS-এ NVMe এবং SATA SSD স্টোরেজের মধ্যে পার্থক্য সেকশনে আলোচনা করা হয়েছে।

যখন fio Unknown error -1 এর কারণে বন্ধ হয়ে যায়

সব ফাইলসিস্টেমে Direct IO উপলব্ধ থাকে না। overlay, যা ডিফল্টভাবে Docker একটি কন্টেইনারকে প্রদান করে, এবং বেশ কিছু নেটওয়ার্ক ফাইলসিস্টেম O_DIRECT সমর্থন করে না। ফলে libaio এমন একটি রিকোয়েস্ট পাঠায় যা কার্নেল সম্পন্ন করতে পারে না এবং fio কাজ বন্ধ করে দেয়:

fio: io_u error on file ./fio-testfile: Unknown error -1: read offset=0, buflen=4096
fio: pid=1234, err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1

প্রথমে df -hT . চালান। যদি Type কলামে overlay লেখা থাকে, তবে --filename কে কোনো বাস্তব স্টোরেজের পাথে নির্দেশ করুন, যেমন একটি bind mounted ভলিউম, অথবা কন্টেইনারের পরিবর্তে সরাসরি হোস্টে fio চালান। যদি বাস্তব স্টোরেজ ব্যবহার করা সম্ভব না হয়, তবে একটি বাফারড সিনক্রোনাস রান অন্তত এটি প্রমাণ করবে যে কমান্ডটি সঠিক।

fio --name=randread4k-buffered --filename=./fio-testfile --size=256M --bs=4k \
  --rw=randread --ioengine=psync --direct=0 --numjobs=1 \
  --runtime=15 --time_based --group_reporting
rm -f ./fio-testfile

এই রানটি কী ধরনের তা সম্পর্কে স্বচ্ছ থাকুন। প্রথমবার চালানোর পর 256M ফাইলটি পেজ ক্যাশে জমা থাকে, তাই IOPS এর মান আপনার RAM এর পারফরম্যান্স নির্দেশ করে। এটি শুধুমাত্র fio ইনস্টল করা আছে কিনা এবং ফ্ল্যাগগুলো সঠিকভাবে কাজ করছে কিনা তা নিশ্চিত করতে ব্যবহার করুন। এটিকে কখনোই ডিস্কের ফলাফল হিসেবে উল্লেখ করবেন না।

কেন dd ডিস্ক বেঞ্চমার্ক হিসেবে উপযুক্ত নয়

dd অনেক VPS থ্রেডে দেখা যায় এবং এটি একটি নির্দিষ্ট প্রশ্নের উত্তর দেয়।

dd if=/dev/zero of=./ddtest bs=1M count=1024 oflag=direct conv=fdatasync
rm -f ./ddtest

এটি একটি থ্রেড এবং একটি রিকোয়েস্ট ইন-ফ্লাইট ব্যবহার করে সিকোয়েন্সিয়াল রাইট থ্রুপুট পরিমাপ করে। এটি একটি সাধারণ কার্যকারিতা যাচাইয়ের জন্য যুক্তিসঙ্গত। এটি র‍্যান্ডম IO সম্পর্কে কোনো তথ্য দেয় না এবং একসাথে 32টি রিকোয়েস্ট আসলে কী ঘটে তা জানায় না। oflag=direct বাদ দিলে এটি মূলত পরিমাপ করে যে আপনার কার্নেল কত দ্রুত মেমরিতে রাইট গ্রহণ করছে, আর এই কারণেই ফোরাম পোস্টে উল্লিখিত dd সংখ্যাগুলো প্রায়শই অবাস্তব হয়।

CPU: sysbench cpu

sysbench cpu --cpu-max-prime=20000 --threads=1 run
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run

আপনার যে সংখ্যাটি মনে রাখা প্রয়োজন তা হলো events per second। প্রথমে সিঙ্গেল থ্রেডেড মোডে রান করুন। এই সংখ্যাটি নির্ধারণ করে যে একটি PHP রিকোয়েস্ট বা একটি কম্পাইল জব কত দ্রুত সম্পন্ন হবে, এবং একই মূল্যের বিভিন্ন হোস্টের মধ্যে এটিই সবচেয়ে বেশি পরিবর্তিত হয়। এরপর প্রতিটি থ্রেড ব্যবহার করে রান করুন, যা থেকে বোঝা যাবে আপনার vCPU-গুলো আলাদা কোর নাকি একটি কোরের অংশবিশেষ।

এই পরীক্ষাটি ঠিক কী পরিমাপ করে তা পরিষ্কার থাকা প্রয়োজন: sysbench cpu বারবার 64-বিট ইন্টিজার অ্যারিথমেটিক ব্যবহার করে মৌলিক সংখ্যা খুঁজে বের করে। এটি মেমোরি ব্যান্ডউইথ, ভেক্টর ইউনিট বা ক্যাশকে এমন কোনো উপায়ে চাপ দেয় না যা বাস্তব কোনো ওয়ার্কলোডের সাথে সাদৃশ্যপূর্ণ। তাই দুটি হোস্টের র‍্যাঙ্কিং করার জন্য এটি ভালো হলেও, আপনার অ্যাপ্লিকেশন কীভাবে চলবে তা অনুমান করার জন্য এটি খুব একটা কার্যকর নয়।

Ubuntu 24.04-এ sysbench 1.0.20 ভার্সনটি থাকে, যেখানে টেস্টের নামটি প্রথমে আসে। কোনো পুরনো পোস্ট থেকে --test=cpu সহ কমান্ড কপি করলে আপনি WARNING: the --test option is deprecated এরর পাবেন। sysbench 0.4 এবং sysbench 1.0 এর স্কোরগুলো একে অপরের সাথে তুলনীয় নয়, তাই এমন কোনো প্রকাশিত স্কোরের সাথে নিজের ফলাফল তুলনা করবেন না যেখানে ভার্সনের নাম উল্লেখ নেই।

মেমরি: sysbench মেমরি

sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=write --threads=1 run
sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=read --threads=1 run

ফলাফল MiB/sec এককে পাওয়া যায় এবং প্রতিটি মেশিনে রিড (read) রাইট (write)-এর চেয়ে দ্রুত সম্পন্ন হয়। --memory-block-size-কে 1M-এ রাখুন এবং আপনি যে হোস্টগুলোর তুলনা করছেন, সেগুলোর প্রতিটিতে এটি একই রাখুন। 1K-এ সংখ্যাটি কমে যায়, কারণ আপনাকে প্রতি অপারেশনের ওভারহেড হাজার গুণ বেশি বহন করতে হয়। ফলে আপনি মেমরি ব্যান্ডউইথের পরিবর্তে লুপের খরচ পরিমাপ করতে শুরু করেন। প্রকাশিত মেমরি স্কোরের ক্ষেত্রে এটি সবচেয়ে বেশি ভুলভাবে ব্যবহৃত ফ্ল্যাগ।

Network: iperf3

থ্রুপুট পরীক্ষা করার নির্ভরযোগ্য উপায় হলো আপনার নিয়ন্ত্রণে থাকা অন্য একটি মেশিনের বিপরীতে এটি চালানো, কারণ এতে আপনি উভয় প্রান্তের অবস্থা সম্পর্কে নিশ্চিত থাকতে পারেন।

দূরবর্তী প্রান্তে:

iperf3 -s

এটি TCP 5201 পোর্টে লিসেন করে। শুধুমাত্র যে ঠিকানা থেকে আপনি পরীক্ষা করছেন তার জন্য পোর্টটি ওপেন করুন এবং কাজ শেষ হলে তা বন্ধ করে দিন। VPS-এ মৌলিক ufw ফায়ারওয়াল রুলস অংশে এর সিনট্যাক্স আলোচনা করা হয়েছে।

পরীক্ষাধীন VPS থেকে:

iperf3 -c 203.0.113.10 -t 30
iperf3 -c 203.0.113.10 -t 30 -R
iperf3 -c 203.0.113.10 -t 30 -P 8

প্রথম কমান্ডটি পরীক্ষাধীন মেশিন থেকে আপলোড পরিমাপ করে। -R কমান্ডটি দিক পরিবর্তন করে, যা ডাউনলোড পরিমাপ করে। -P 8 কমান্ডটি আটটি সমান্তরাল স্ট্রিম ওপেন করে।

সিঙ্গেল স্ট্রিম এবং প্যারালাল ভার্সন উভয়ই রান করুন, কারণ তারা ভিন্ন ভিন্ন প্রশ্নের উত্তর দেয়। একটি TCP কানেকশন তার উইন্ডো যতটুকু অনুমতি দেয় তার বেশি আন-অ্যাকনলেজড ডেটা ধরে রাখতে পারে না, তাই এর সর্বোচ্চ সীমা মোটামুটি উইন্ডো সাইজকে রাউন্ড ট্রিপ টাইম দিয়ে ভাগ করলে যা পাওয়া যায় তার সমান। 80 ms ল্যাটেন্সি এবং 4 MB উইন্ডো সাইজের ক্ষেত্রে এই সীমা প্রায় 400 Mbit/s, সংযোগটি যতই দ্রুত হোক না কেন। সিঙ্গেল স্ট্রিমের সংখ্যাটি আপনাকে জানাবে একটি ডাউনলোড থেকে আপনি কী গতি পাবেন। প্যারালাল স্ট্রিমের সংখ্যাটি আপনাকে সংযোগের মোট সক্ষমতা জানাবে।

এই পরীক্ষাটি করার সময় আপনার ব্যান্ডউইথ ব্যবহারের দিকে নজর রাখুন। 1 Gbit/s গতিতে 30 সেকেন্ডে প্রায় 3.75 GB ডেটা আদান-প্রদান হয় এবং আপনাকে এটি প্রতিটি দিকে কয়েকবার রান করতে হবে।

রেফারেন্স ফিগার এবং আপনারগুলো যেভাবে পড়বেন

[
  {
    "device": "Local NVMe",
    "iops_4k_read": "180,000"
  },
  {
    "device": "Local SATA SSD",
    "iops_4k_read": "90,000"
  },
  {
    "device": "Network block",
    "iops_4k_read": "12,000"
  },
  {
    "device": "Spinning disk",
    "iops_4k_read": "180"
  }
]

প্রকাশিত ফলাফলে একটি লোকাল NVMe ভলিউম সাধারণত 180,000 4k র‍্যান্ডম রিড IOPS-এর কাছাকাছি থাকে। একটি লোকাল SATA SSD প্রায় 90,000-এর কাছাকাছি থাকে। নেটওয়ার্ক অ্যাটাচড ব্লক স্টোরেজ, যেখানে প্রতিটি রিকোয়েস্ট ডিস্কে পৌঁছানোর আগে নেটওয়ার্ক অতিক্রম করে, সেটি 12,000-এর কাছাকাছি থাকে এবং একটি স্পিনিং ডিস্ক মোটামুটি 180 ম্যানেজ করতে পারে, কারণ এটি প্রতিটি র‍্যান্ডম রিকোয়েস্টের জন্য একটি ফিজিক্যাল হেড মুভ করে।

এগুলো প্রতিটি স্টোরেজ ক্লাসের জন্য সাধারণ প্রকাশিত ফিগার, কোনো একটি হোস্ট থেকে নেওয়া পরিমাপ নয়। এগুলোকে শুধুমাত্র একটি উদ্দেশ্যে ব্যবহার করুন: আপনার নিজের ফলাফল সঠিক মাত্রার ক্রমে আছে কি না তা যাচাই করা। যদি NVMe হিসেবে বিক্রি হওয়া কোনো প্ল্যান 4k IOPS-এর লো থাউজেন্ড রেঞ্জে বেঞ্চমার্ক দেয়, তবে প্রথমে নিশ্চিত করুন যে --direct=1 চালু ছিল কি না। যদি তা চালু থাকে, তবে হয় স্টোরেজটি প্রোডাক্ট পেজে বর্ণিত বিবরণের মতো নয়, অথবা আপনি খুব ব্যস্ত কোনো প্রতিবেশীর সাথে এটি শেয়ার করছেন।

কেন একটি রান বেঞ্চমার্ক হিসেবে যথেষ্ট নয়

একটি একক ফলাফল হলো একটি শেয়ারড মেশিনে এক মিনিটের একটি স্ন্যাপশট। একে কেবল একটি নমুনা হিসেবে গণ্য করুন।

• প্রতিটি টেস্ট অন্তত পাঁচবার চালান, যা বিভিন্ন সময়ে এবং অন্তত দুটি ভিন্ন দিনে ছড়িয়ে থাকবে। মিডিয়ান এবং স্প্রেড সংরক্ষণ করুন। স্প্রেড ছাড়া প্রকাশিত ফলাফল কেবল একটি মার্কেটিং সংখ্যা।
• প্রতিটি রানের পাশে steal time রেকর্ড করুন। যেসব রানে st বেশি ছিল, সেগুলো বাদ দিন অথবা অন্তত তা উল্লেখ করুন।
• ডিস্ক টেস্ট দুটি ভিন্ন মেয়াদে চালান। অনেক প্ল্যানে একটি নির্দিষ্ট burst IOPS বরাদ্দ থাকে যা সময়ের সাথে রিফিল হয়, তাই 60 সেকেন্ডের fio রান কেবল burst পরিমাপ করে, যেখানে --runtime=600 সর্বনিম্ন সক্ষমতা পরিমাপ করে। খারাপ সময়ে আপনি এই সর্বনিম্ন সক্ষমতাই পাবেন।
• অন্য কোনো প্রসেস চলছে কি না তা নিশ্চিত করুন। CPU টেস্টের মাঝখানে unattended-upgrades যদি কোনো apt ট্রানজ্যাকশন শুরু করে, তবে তা আপনার ফলাফলে বড় প্রভাব ফেলবে এবং প্রতিটি রানের আগে ps -e -o comm= | grep -E 'apt|dpkg' চালানো এক সেকেন্ড সময় নেয়।
• একবারে একটি মাত্র ভেরিয়েবল পরিবর্তন করুন। ভিন্ন টুলের ভার্সন, ব্লক সাইজ বা থ্রেড কাউন্ট এমন সব সংখ্যা তৈরি করে যা তুলনাযোগ্য নয়, তা দেখতে যতই একই রকম মনে হোক না কেন।

যখন আপনি দুটি প্রোভাইডারের তুলনা করবেন, তখন তাদের একই দিনের একই সময়ে চালান। অন্যথায়, আপনি মূলত দিনের সময়ের পরিমাপ করছেন।

আপনার নিজস্ব কাজের চাপের বেঞ্চমার্ক সবার শেষে করুন

সিন্থেটিক টুলগুলো মেশিনের র‍্যাঙ্কিং করে। শুধুমাত্র আপনার নিজস্ব কাজের চাপই আপনাকে বলবে যে একটি মেশিন আপনার জন্য যথেষ্ট কি না। আপনি বাস্তবে যা করেন তার সময় পরিমাপ করুন।

time tar -czf /tmp/bench.tgz /usr/share
rm -f /tmp/bench.tgz

এটি কয়েকশ মেগাবাইট ডেটা কম্প্রেস করে, তাই এটি CPU এবং ডিস্ক উভয়কেই একসাথে ব্যবহার করে এবং যেকোনো একটির পরিবর্তনে ফলাফল পরিবর্তিত হয়। Removing leading / from member names ওয়ার্নিংটি স্বাভাবিক। এর চেয়েও ভালো হয় যদি আপনি আপনার নিজস্ব বিল্ড, আপনার সবচেয়ে ধীরগতির কুয়েরি বা আপনার পেজ রেন্ডার হওয়ার সময় পরিমাপ করেন। একটি বিল্ড যদি একটি হোস্টে 4 মিনিট এবং অন্যটিতে 7 মিনিট সময় নেয়, তবে Geekbench যা-ই বলুক না কেন, বিষয়টি সেখানেই নিষ্পত্তি হয়ে যায়। এই পরিমাপটিই আপনাকে বলে দেবে কখন আর বেশি শক্তিশালী মেশিনের পেছনে খরচ করা অর্থহীন, যা একটি VPS-এর মাসিক প্রকৃত খরচ সম্পর্কে পড়ার আগে বা কাজের চাপ একটি ডেডিকেটেড সার্ভারে স্থানান্তর করার আগে জেনে রাখা জরুরি।

FAQ

প্রতিবার চালানোর সময় আমি কেন ভিন্ন ভিন্ন বেঞ্চমার্ক ফলাফল পাই?

একটি VPS তার ফিজিক্যাল CPU, স্টোরেজ এবং নেটওয়ার্ক অন্যান্য ব্যবহারকারীর সাথে শেয়ার করে, তাই আপনার ফলাফল নির্ভর করে সেই মুহূর্তে তারা কী করছে তার ওপর। পরীক্ষার সময় vmstat 1 চালান এবং st কলামটি দেখুন: যদি দীর্ঘস্থায়ী স্টিল টাইম 5-এর উপরে থাকে, তবে বুঝতে হবে হোস্টটি ব্যস্ত ছিল এবং আপনার CPU স্কোর কম হওয়ার কারণ আপনার মেশিনের বাইরে। এর সমাধান হলো টিউনিংয়ের পরিবর্তে সঠিক পদ্ধতি অনুসরণ করা। প্রতিটি পরীক্ষা ভিন্ন ভিন্ন সময়ে পাঁচ বা তার বেশিবার চালান এবং তারপর মিডিয়ান মান ও তার বিস্তৃতি রিপোর্ট করুন।

fio কেন মিলিয়ন IOPS রিপোর্ট করে?

প্রায় সবসময়ই এর কারণ হলো --direct=1 অনুপস্থিত থাকা। এটি ছাড়া fio কার্নেল পেজ ক্যাশের মাধ্যমে রিড করে, তাই প্রথমবার চালানোর পর একটি 2G টেস্ট ফাইল RAM থেকে পরিবেশন করা হয় এবং আপনি আসলে মেমোরি ব্যান্ডউইথ পরিমাপ করেন। --direct=1 যোগ করুন এবং টেস্ট ফাইলটিকে পথের যেকোনো ক্যাশের চেয়ে বড় রাখুন। যদি --direct=1 ব্যর্থ হয় এবং err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1 দেখায়, তবে df -hT . চালান: একটি Type যার overlay আছে তা O_DIRECT সমর্থন করে না, তাই টেস্টটিকে সরাসরি রিয়েল স্টোরেজের দিকে নির্দেশ করুন।

শুধুমাত্র yabs.sh কি যথেষ্ট?

প্রাথমিক পর্যবেক্ষণের জন্য, হ্যাঁ। এটি চারটি ব্লক সাইজে fio, উভয় দিকে iperf3 এবং Geekbench চালায় এবং একটি সারাংশ প্রিন্ট করে যা অন্যরা পড়তে পারে। যখন আপনি জানতে চান কেন একটি সংখ্যা এমন, তখন এটি যথেষ্ট নয়, কারণ আপনি প্রতি টেস্টে এর ফ্ল্যাগগুলো পরিবর্তন করতে পারেন না। একবার yabs-এর ফলাফল ভুল মনে হলে, সরাসরি fio বা sysbench দিয়ে তা পুনরায় পরীক্ষা করুন এবং প্রতিবার একটি করে ফ্ল্যাগ পরিবর্তন করুন।

কোন একটি সংখ্যা আমার অ্যাপ্লিকেশনের পারফরম্যান্স কেমন হবে তা নির্দেশ করে?

অধিকাংশ ওয়েব এবং ডাটাবেস ওয়ার্কলোডের জন্য, সিঙ্গেল কোর CPU স্পিড এবং 4k র‍্যান্ডম রিড ল্যাটেন্সি, এই ক্রমানুসারে। থ্রুপুট ফিগারগুলো দেখতে আকর্ষণীয় হলেও খুব কম ক্ষেত্রেই তা কোনো কিছু নির্ধারণ করে, কারণ সাধারণ রিকোয়েস্টগুলো ছোট হয়। গড় মানের পরিবর্তে fio clat percentiles ব্লকের 99তম পার্সেন্টাইল (99th percentile) উল্লেখ করুন, কারণ প্রতি একশটি রিকোয়েস্টের মধ্যে যে একটি ধীরগতির হয়, ব্যবহারকারী সেটিই লক্ষ্য করেন।

বেঞ্চমার্ক করার আগে কি আমার কিছু ইনস্টল করতে হবে?

fio, sysbench এবং iperf3 সবই Ubuntu এবং Debian আর্কাইভে আছে: sudo apt install -y fio sysbench iperf3। yabs.sh-এর জন্য শুধুমাত্র curl প্রয়োজন, কারণ এটি অনুপস্থিত যেকোনো কিছুর জন্য স্ট্যাটিক বাইনারি ডাউনলোড করে নেয়। কাজ শেষ হলে প্রতিটি টেস্ট ফাইল মুছে ফেলুন, কারণ 20G ডিস্কে ফেলে রাখা 2G fio ফাইল কয়েক সপ্তাহ পর কারো জন্য ডিস্ক ফুল হওয়ার অ্যালার্ট হয়ে দাঁড়াতে পারে।