VPS benchmark সঠিকভাবে করার নিয়ম ও ফল বোঝা

VPS benchmark করার অর্থ

VPS benchmark করতে চারটি বিষয় মাপা হয়: একটি CPU core কত দ্রুত চলে, মেশিনটির memory bandwidth কত, storage প্রতি সেকেন্ডে কতগুলো ছোট random disk operation পরিবেশন করতে পারে, এবং network link কত throughput সরবরাহ করে। yabs.sh-এর একটি run প্রায় দশ মিনিটে এই চারটি বিষয়ই জানায়। ফলাফল বোঝাই কঠিন অংশ, কারণ VPS অন্য tenant-দের সঙ্গে physical hardware ভাগ করে ব্যবহার করে। তাই একই মেশিন 03:00-এ একটি সংখ্যা এবং 20:00-এ সম্পূর্ণ ভিন্ন সংখ্যা দেখাতে পারে।

এখানে প্রথমে দ্রুত ধারণা পাওয়ার জন্য yabs.sh চালানো হবে। এরপর এর ভেতরে ব্যবহৃত tool-গুলো হাতে চালানো হবে। নিজে চালালে একটি flag পরিবর্তন করে সংখ্যাটি কীভাবে বদলায় তা দেখা যায়। এতে সংখ্যাটি আসলে কী মাপছে তা বোঝা যায়। মেশিন setup করার পরে এটি করুন, তার আগে নয়। নতুন VPS-এ প্রথম দশ মিনিট-এর ধাপগুলো আগে সম্পন্ন করতে হবে। কারণ একটি মেশিনে প্রথম দফার update এখনও চললে hardware-এর সঙ্গে সম্পর্কহীন কারণে benchmark ফলাফল খারাপ হতে পারে।

পরিমাপ করার আগে মেশিনটি বুঝে নিন

প্রতিটি খারাপ benchmark-এর পেছনে এমন একটি মেশিন থাকে, যেটি লেখক বুঝে নেননি।

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

Hypervisor vendor: KVM বলতে full virtualisation বোঝায়। তাই আপনি নিজের kernel চালান। systemd-detect-virt-এ lxc বা openvz প্রিন্ট হলে তা container virtualisation বোঝায়। এখানে আপনি host kernel ভাগ করে ব্যবহার করেন, এবং CPU ও memory সীমা virtual hardware নয়, বরং cgroup (control group) সেটিংস দ্বারা নির্ধারিত হয়। cgroup v2 সিস্টেমে CPU limit সরাসরি পড়া যায়।

cat /sys/fs/cgroup/cpu.max

max 100000 বলতে কোনো quota নেই। 200000 100000 বলতে প্রতি 100000 microsecond period-এ 200000 microsecond CPU ব্যবহার করা যায়। এটি দুইটি core-এর সমপরিমাণ quota। 4 vCPU হিসেবে বিজ্ঞাপিত কোনো plan-এ দুই core-এর quota থাকলে সেটি কখনোই চার core-এর মতো score পাবে না। কোনো benchmark tool-ই এর কারণ ব্যাখ্যা করে এমন line প্রিন্ট করে না।

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

Steal time পুরো সময় পর্যবেক্ষণ করুন

Steal time হলো আপনার virtual CPU চালানোর জন্য প্রস্তুত থাকা সময়ের সেই অংশ, যখন hypervisor physical core অন্য কোনো কাজের জন্য বরাদ্দ করেছে। কোনো ফলাফল hardware-এর কারণে নয়, বরং একই host-এর অন্য virtual machine-এর প্রভাবে হয়েছে কি না বোঝার জন্য এটি সবচেয়ে কার্যকর একক সংকেত।

vmstat 1 10

ডান পাশে থাকা st column পড়ুন। ধারাবাহিকভাবে 0 বা 1 থাকা স্বাভাবিক। 5-এর বেশি মান দীর্ঘ সময় ধরে থাকলে বুঝবেন, ওই মুহূর্তে host-এর ওপর অতিরিক্ত workload রয়েছে। তাই সেই সময়ের window-তে record করা প্রতিটি CPU সংখ্যা আপনার machine-এর কোনো ত্রুটি ছাড়াই কম হবে। CPU line-এ top, %st-এর মতো একই figure দেখায়। benchmark চালানোর সময় দ্বিতীয় SSH session-এ vmstat 1 চালু রাখুন এবং প্রতিটি result-এর পাশে steal figure লিখে রাখুন।

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

yabs.sh (Yet Another Bench Script) একটি shell script। এটি static fio, iperf3 এবং Geekbench binary download করে, সেগুলো চালায় এবং একটি summary দেখায়। VPS benchmark নিয়ে আলোচনায় এটি একটি প্রচলিত মাধ্যম। তাই অন্য কারও সঙ্গে ফলাফল তুলনা করার দ্রুততম উপায় হলো yabs-এর output শেয়ার করা।

Project-এর নিজস্ব one-line form হলো এটি।

curl -sL yabs.sh | bash

এটি URL থেকে বর্তমানে যে content পাওয়া যায়, তা সরাসরি একটি shell-এ pipe করে। আগে এটি download করে পড়ুন। তারপর চালান।

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

Pipe করলে flag-গুলো -s ---এর পরে দিতে হয়। Local copy চালালে flag-গুলো filename-এর পরে সরাসরি দিতে হয়। দরকারি flag-গুলো হলো: -f disk test বাদ দেয়, -i network test বাদ দেয়, -g Geekbench বাদ দেয়, -r iperf3 location-এর সংখ্যা 2-এ কমিয়ে দেয়, -j ফলাফল JSON হিসেবে দেখায়, এবং -w results.json ওই JSON একটি file-এ লেখে।

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

প্রথমবার চালানোর আগে দুটি বিষয় জানা দরকার। Geekbench আপনার ফলাফল upload করে এবং একটি public browser.geekbench.com URL দেখায়। ওই link যার কাছে থাকবে, সে আপনার CPU model ও score দেখতে পারবে। -g ব্যবহার করলে এই test সম্পূর্ণ বাদ যায়। দ্বিতীয়ত, iperf3 stage-এ বিভিন্ন region-এর server-এ প্রকৃত network traffic পাঠানো হয়। এই traffic আপনার মাসিক bandwidth allowance থেকে গণনা হয়। 1 Gbit/s link-এ একটি সম্পূর্ণ network stage-এ কয়েক দশ GB traffic যেতে পারে। তাই allowance কম হলে -r এবং metered link হলে -i ব্যবহার করুন।

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

Disk section চারটি block size-এ 50/50 read ও write মিশ্রণ ব্যবহার করে fio চালায়: 4k, 64k, 512k এবং 1m। প্রতিটির জন্য এটি IOPS (input/output operations per second) এবং bandwidth দেখায়। Database, mail server বা অনেক ছোট write সম্পাদন করে এমন যেকোনো কাজের ক্ষেত্রে 4k row-টি গুরুত্বপূর্ণ, কারণ অধিকাংশ server IO ছোট এবং বিচ্ছিন্ন হয়। Backup ও video-র ক্ষেত্রে 1m row-টি গুরুত্বপূর্ণ, কারণ সেখানে দীর্ঘ byte sequence স্থানান্তর করা হয়।

Network section কয়েকটি region-এর public server-এর বিরুদ্ধে উভয় দিকের traffic-এ parallel stream ব্যবহার করে iperf3 চালায়। এখানে কম সংখ্যা দেখলে সেটিকে চূড়ান্ত ফল না ধরে তদন্তের সূচনা হিসেবে বিবেচনা করুন, কারণ public iperf3 server শেয়ার করা হয় এবং প্রায়ই সম্পূর্ণ ব্যবহৃত থাকে। তাই খারাপ ফলাফলের কারণ দূরের প্রান্তেও থাকতে পারে।

Geekbench section একটি single core score এবং একটি multi core score দেখায়। Single core score থেকে বোঝা যায় একটি request, একটি compile বা একটি query কত দ্রুত শেষ হবে। Multi core score মূলত দেখায় আপনি বাস্তবে কতগুলি core পেয়েছেন।

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

fio (flexible IO tester) হলো yabs-এর disk section-এর অন্তর্নিহিত tool। সরাসরি এটি চালালেই flags-এর অর্থ পরিষ্কার হয়।

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

আপনার প্রয়োজনীয় filesystem-এ queue depth 32 রেখে 4k random read test চালাতে:

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

output থেকে পড়ার মতো summary line দেখতে এমন হবে।

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

এর নিচে fio একটি clat percentiles block দেখায়। উদ্ধৃত করার মতো সংখ্যা হলো 99.00th percentile, কারণ 100টি request-এর মধ্যে সবচেয়ে ধীর 1টি request কতক্ষণ অপেক্ষা করেছে, এটি তা দেখায়। average latency ব্যবহারকারীর চোখে পড়া stall-গুলো আড়াল করে।

• --direct=1 ব্যবহার করে file-টি O_DIRECT দিয়ে খোলে, তাই read kernel page cache এড়িয়ে চলে। এটি না থাকলে, 8G RAM-এর একটি machine-এ 2G file-এর দ্বিতীয় pass memory থেকে পরিবেশিত হয় এবং fio IOPS millions-এ দেখায়। সংখ্যাটি বাস্তব, তবে এটি memory-এর সংখ্যা।
• --ioengine=libaio asynchronous request submit করে। এর ফলে --iodepth=32 একসঙ্গে 32টি request in flight রাখতে পারে। psync-এর মতো synchronous engine ব্যবহার করলে 1-এর বেশি iodepth কোনো কাজ করে না। তখন একবারে 1টি request মাপা হয়।
• --time_based --runtime=60 নির্দিষ্ট কাজের পরিমাণের বদলে নির্দিষ্ট 60 seconds ধরে চলে। ফলে fast disk এবং slow disk একই wall clock পায় এবং তুলনা ন্যায্য থাকে।
• --size=2G test file-এর size নির্ধারণ করে। path-এর যেকোনো cache-এর চেয়ে file-টি বড় রাখুন এবং আগে free space আছে কি না যাচাই করুন।

Random write একই command, শুধু --rw=randwrite ব্যবহার করতে হবে। এটি আলাদাভাবে চালান, তারপর file-টি delete করুন।

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

বাস্তব network traffic-এর কাছাকাছি mix-এর জন্য --rw=randrw --rwmixread=70 ব্যবহার করুন। আপনি কোন class-এর storage ব্যবহার করছেন, তা যেকোনো flag-এর চেয়ে বেশি মাত্রায় result পরিবর্তন করে। এই পার্থক্যটি VPS-এ NVMe এবং SATA SSD storage-এর পার্থক্য-এ ব্যাখ্যা করা হয়েছে।

fio চালানোর সময় Unknown error -1 দেখা দিলে

প্রতিটি filesystem-এ Direct IO ব্যবহার করা যায় না। overlay, যা Docker একটি container-কে ডিফল্টভাবে দেয়, এবং একাধিক network filesystem O_DIRECT সমর্থন করে না। তাই libaio এমন একটি অনুরোধ পাঠায় যা kernel সম্পন্ন করতে পারে না, এবং 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-কে real storage-এর কোনো path-এ নির্দেশ করুন, যেমন bind mounted volume-এর path। অথবা container-এর পরিবর্তে host-এ fio চালান। real storage ব্যবহার করা সম্ভব না হলে buffered synchronous run অন্তত নিশ্চিত করে যে command-টি সঠিক এবং flag-গুলো সঠিকভাবে parse হচ্ছে।

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

এই run-এর ফলাফল সম্পর্কে সঠিকভাবে উল্লেখ করুন। প্রথম pass-এর পরে 256M file-টি page cache-এ থাকে। তাই IOPS মানটি আপনার RAM-এর কর্মক্ষমতা নির্দেশ করে। এটি fio ইনস্টল করা আছে এবং flag-গুলো parse হচ্ছে কি না নিশ্চিত করতে ব্যবহার করুন। এটিকে কখনো disk-এর ফলাফল হিসেবে উল্লেখ করবেন না।

dd কেন disk benchmark নয়

dd অনেক VPS আলোচনায় দেখা যায়, এবং এটি একটি নির্দিষ্ট প্রশ্নের উত্তর দেয়।

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

এটি একটি thread এবং একসঙ্গে চলমান একটি request ব্যবহার করে sequential write throughput পরিমাপ করে। এটি একটি যুক্তিসংগত প্রাথমিক যাচাই। এটি random IO সম্পর্কে কিছুই জানায় না। একই সময়ে 32টি request এলে কী ঘটে, সে সম্পর্কেও কিছু জানায় না। oflag=direct বাদ দিলে এটি মূলত আপনার kernel কত দ্রুত memory-তে write গ্রহণ করে, তা পরিমাপ করে। এ কারণেই forum post-এ উদ্ধৃত 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। প্রথমে single-threaded পরীক্ষা চালান। একটি PHP request কত দ্রুত শেষ হয় বা একটি compile job কত দ্রুত সম্পন্ন হয়, সেই সংখ্যা তা নির্ধারণ করে। একই দামের host-গুলোর মধ্যে এই ফলাফলেই সাধারণত সবচেয়ে বেশি পার্থক্য দেখা যায়। এরপর সব thread ব্যবহার করে পরীক্ষা চালান। এতে বোঝা যায় আপনার vCPU-গুলো পৃথক core, নাকি একই core-এর ভাগ করা অংশ।

এই পরীক্ষায় কী মাপা হচ্ছে তা পরিষ্কারভাবে বুঝুন: sysbench cpu 64-bit integer arithmetic ব্যবহার করে বারবার prime number খুঁজে বের করে। এটি memory bandwidth, vector unit বা cache এমনভাবে ব্যবহার করে না, যা বাস্তব workload-এর সঙ্গে সামঞ্জস্যপূর্ণ। তাই দুটি host-এর তুলনামূলক ranking-এর জন্য এটি উপযোগী, কিন্তু আপনার application কীভাবে চলবে তা অনুমান করার জন্য নির্ভরযোগ্য নয়।

Ubuntu 24.04-এর সঙ্গে sysbench 1.0.20 সরবরাহ করা হয়। এই version-এ test name শুরুতে থাকে। পুরোনো কোনো post থেকে --test=cpu-সহ একটি command copy করলে আপনি WARNING: the --test option is deprecated পাবেন। sysbench 0.4 এবং sysbench 1.0-এর score কোনোভাবেই তুলনাযোগ্য নয়। তাই যে published number-এ version উল্লেখ নেই, তার সঙ্গে নিজের ফলাফল কখনো তুলনা করবেন না।

মেমরি: sysbench memory

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 রাখুন এবং যেসব host-এর তুলনা করছেন, সেগুলোতে এটি একই রাখুন। 1K ব্যবহার করলে ফলাফল দ্রুত কমে যায়, কারণ প্রতি operation-এর overhead এক হাজার গুণ বেশি ঘন ঘন দিতে হয়। ফলে memory bandwidth-এর পরিবর্তে loop cost মাপা হয়। প্রকাশিত memory score-গুলোর মধ্যে এটিই সবচেয়ে বেশি অসামঞ্জস্যপূর্ণ flag।

নেটওয়ার্ক: iperf3

Throughput পরীক্ষা করার নির্ভরযোগ্য পদ্ধতি হলো আপনার নিয়ন্ত্রণে থাকা দ্বিতীয় একটি মেশিনের সঙ্গে পরীক্ষা করা। এতে উভয় প্রান্তে কী ঘটছে তা আপনি জানতে পারবেন।

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

iperf3 -s

এটি TCP 5201 port-এ সংযোগের জন্য অপেক্ষা করে। যে address থেকে পরীক্ষা করবেন, শুধু সেই address-এর জন্য port-টি খুলুন এবং পরীক্ষা শেষ হলে বন্ধ করে দিন। VPS-এ Basic ufw firewall rule-এ syntax দেওয়া আছে।

পরীক্ষাধীন 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

প্রথম command-টি পরীক্ষাধীন মেশিন থেকে upload মাপে। -R দিক উল্টে দেয়, ফলে download মাপা হয়। -P 8 আটটি parallel stream চালু করে।

একটি stream এবং parallel version—দুটিই চালান, কারণ এগুলো ভিন্ন প্রশ্নের উত্তর দেয়। একটি TCP connection তার window যত unacknowledged data ধারণ করতে দেয়, সর্বোচ্চ ততটুকুই ধরে রাখতে পারে। তাই এর সীমা মোটামুটি window size-কে round trip time দিয়ে ভাগ করলে যা হয়, তার সমান। 80 ms latency এবং 4 MB window হলে এই সীমা প্রায় 400 Mbit/s, link-এর প্রকৃত গতি যত বেশি হোক না কেন। Single stream-এর ফলাফল দেখায় একটি download কত গতি পাবে। Parallel ফলাফল link-এর capacity দেখায়।

এই পরীক্ষা চালানোর সময় bandwidth allowance নজরে রাখুন। 1 Gbit/s গতিতে 30 seconds-এ প্রায় 3.75 GB data স্থানান্তরিত হয়, এবং প্রতিটি direction-এ আপনাকে এটি কয়েকবার চালাতে হবে।

রেফারেন্স মান এবং আপনার ফলাফল কীভাবে পড়বেন

[
  {
    "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"
  }
]

প্রকাশিত ফলাফলে একটি local NVMe volume সাধারণত প্রায় 180,000 4k random read IOPS দেয়। একটি local SATA SSD-এর ফল প্রায় 90,000। Network attached block storage-এ প্রতিটি request disk-এ পৌঁছানোর আগে network অতিক্রম করে, তাই এর ফল সাধারণত 12,000-এর কাছাকাছি থাকে। একটি spinning disk প্রায় 180 দিতে পারে, কারণ প্রতিটি random request-এর জন্য এটিকে physical head সরাতে হয়।

এগুলো প্রতিটি storage class-এর সাধারণ প্রকাশিত মান। এগুলো কোনো একটি host থেকে নেওয়া measurement নয়। এগুলো শুধু একটি কাজে ব্যবহার করুন: আপনার নিজের ফলাফল একই order of magnitude-এ আছে কি না তা যাচাই করতে। NVMe হিসেবে বিক্রি করা কোনো plan-এর benchmark যদি 4k IOPS-এর ক্ষেত্রে low thousands-এ থাকে, তাহলে প্রথমে নিশ্চিত করুন যে --direct=1 চালু ছিল। এটি চালু থাকলে storage product page-এ বর্ণিত storage নয়, অথবা আপনি অত্যন্ত ব্যস্ত কোনো প্রতিবেশী host-এর সঙ্গে এটি ভাগ করে ব্যবহার করছেন।

একবার চালানো কোনো benchmark নয়

একটি ফলাফল shared machine-এ এক মিনিটের একটি snapshot মাত্র। এটিকে একটি sample হিসেবে বিবেচনা করুন।

• প্রতিটি test অন্তত পাঁচবার চালান। আলাদা hour এবং অন্তত দুইটি আলাদা day-তে test চালান। median এবং spread সংরক্ষণ করুন। spread ছাড়া প্রকাশিত ফলাফল marketing figure।
• প্রতিটি run-এর পাশে steal time লিখে রাখুন। st বেশি হলে সেই run বাদ দিন, অথবা অন্তত উল্লেখ করুন যে এটি বেশি ছিল।
• disk test দুইটি duration-এ চালান। অনেক plan-এ burst IOPS allowance থাকে, যা সময়ের সঙ্গে পুনরায় পূরণ হয়। তাই 60 second-এর fio run burst মাপে, আর --runtime=600 floor মাপে। খারাপ দিনে আপনি যে performance পান, floor সেটিই।
• অন্য কোনো কাজ চলছে না তা যাচাই করুন। CPU test চলার মাঝখানে unattended-upgrades apt transaction শুরু করলে প্রকৃত score কমে, এবং প্রতিটি run-এর আগে ps -e -o comm= | grep -E 'apt|dpkg' চালাতে এক second সময় লাগে।
• একবারে একটি variable পরিবর্তন করুন। আলাদা tool version, block size বা thread count এমন সংখ্যা তৈরি করে, যেগুলো দেখতে একই রকম হলেও তুলনা করা যায় না।

দুই provider তুলনা করার সময় একই day-এর একই hour-এ test চালান। অন্যথায় আপনি provider নয়, দিনের সময় মেপেছেন।

নিজের workload দিয়ে শেষে benchmark করুন

Synthetic tool মেশিনগুলোর র‍্যাঙ্ক নির্ধারণ করে। কোনো মেশিন আপনার জন্য যথেষ্ট কি না, তা কেবল আপনার নিজের workload-ই জানায়। আপনি বাস্তবে যে কাজ করেন, সেটির সময় মাপুন।

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

এটি কয়েকশ megabyte compress করে। তাই CPU এবং disk—দুটিই একসঙ্গে ব্যবহার হয়, এবং যেকোনো একটির পরিবর্তন হলে ফলও বদলে যায়। Removing leading / from member names warning স্বাভাবিক। আরও ভালো হয়, যদি নিজের build, নিজের সবচেয়ে ধীর query বা নিজের page render-এর সময় মাপেন। একটি host-এ build শেষ হতে 4 মিনিট এবং অন্যটিতে 7 মিনিট লাগলে, Geekbench যা-ই বলুক, সিদ্ধান্ত পরিষ্কার। কোন সময় বেশি ক্ষমতাসম্পন্ন machine-এর জন্য অর্থ দেওয়া আর সার্থক নয়, এই measurement সেটিও জানায়। তাই একটি VPS-এর মাসিক প্রকৃত খরচ পড়ার বা workload-টি একটি dedicated server-এ স্থানান্তর করার আগে এই তথ্য জানা গুরুত্বপূর্ণ।

FAQ

প্রতিবার চালালে benchmark-এর ফল ভিন্ন কেন পাই?

একটি VPS অন্য tenant-দের সঙ্গে physical CPU, storage এবং network ভাগ করে ব্যবহার করে। তাই ফলাফলটি ওই মুহূর্তে তারা কী করছে তার ওপর নির্ভর করে। Test চলাকালে vmstat 1 চালান এবং st column দেখুন: 5-এর বেশি sustained steal time হলে host ব্যস্ত ছিল, এবং আপনার machine-এর বাইরের কারণে CPU score কম হয়েছে। এর সমাধান tuning নয়, পদ্ধতি ঠিক রাখা। বিভিন্ন সময়ে প্রতিটি test পাঁচ বা তার বেশি বার চালান। এরপর spread-এর সঙ্গে median report করুন।

fio millions of IOPS report করে কেন?

প্রায় সব ক্ষেত্রেই কারণ হলো --direct=1 অনুপস্থিত। এটি না থাকলে fio kernel page cache-এর মাধ্যমে পড়ে। তাই প্রথম pass-এর পর 2G test file RAM থেকে সরবরাহ হয়, এবং আপনি আসলে memory bandwidth মাপছেন। --direct=1 যোগ করুন। Test file-টি path-এর যেকোনো cache-এর চেয়ে বড় রাখুন। --direct=1 এরপর err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1 দিয়ে ব্যর্থ হলে df -hT . চালান: Type-এর overlay O_DIRECT support করে না। তাই test-টি real storage-এ চালান।

yabs.sh কি একাই যথেষ্ট?

প্রাথমিক যাচাইয়ের জন্য যথেষ্ট। এটি চারটি block size-এ fio চালায়, উভয় দিকে iperf3 চালায় এবং এমন একটি summary দেখায় যা অন্যরা পড়তে পারে। কোনো সংখ্যার কারণ জানতে চাইলে এটি আর যথেষ্ট নয়, কারণ প্রতিটি test-এর জন্য এর flags আলাদাভাবে পরিবর্তন করা যায় না। yabs-এর ফল অস্বাভাবিক মনে হলে সরাসরি fio বা sysbench দিয়ে তা পুনরায় চালান এবং একবারে একটি flag পরিবর্তন করুন।

আমার application কেমন অনুভূত হবে তা কোন একক সংখ্যা সবচেয়ে ভালোভাবে অনুমান করে?

বেশিরভাগ web এবং database workload-এর ক্ষেত্রে প্রথমে single core CPU speed, তারপর 4k random read latency গুরুত্বপূর্ণ। Throughput-এর সংখ্যা আকর্ষণীয় দেখালেও সাধারণত সিদ্ধান্ত নির্ধারণ করে না, কারণ একটি সাধারণ request ছোট হয়। গড়ের বদলে fio-এর clat percentiles block থেকে 99th percentile উল্লেখ করুন। কারণ প্রতি 100টি request-এর মধ্যে ধীরতম একটি request-ই user লক্ষ্য করেন।

Benchmark করার আগে কি কিছু install করতে হবে?

fio, sysbench এবং iperf3 Ubuntu ও Debian archive-এ রয়েছে: sudo apt install -y fio sysbench iperf3। yabs.sh-এর জন্য শুধু curl প্রয়োজন, কারণ অনুপস্থিত জিনিসের জন্য এটি static binary download করে। কাজ শেষ হলে প্রতিটি test file মুছে ফেলুন। কারণ 20G disk-এ রেখে যাওয়া 2G fio file কয়েক সপ্তাহ পরে disk full alert-এর কারণ হতে পারে।