راهنمای کامل بنچمارک گرفتن از VPS با ابزارهای استاندارد

معنای بنچمارک گرفتن از یک VPS

برای بنچمارک گرفتن از یک VPS، چهار مورد را اندازه‌گیری می‌کنید: سرعت اجرای یک هسته CPU، پهنای باند حافظه دستگاه، تعداد عملیات کوچک و تصادفی دیسک در هر ثانیه، و میزان توان عملیاتی (throughput) لینک شبکه. یک بار اجرای yabs.sh هر چهار مورد را در حدود 10 دقیقه به شما می‌دهد. خواندن نتیجه بخش دشوارتر کار است، زیرا یک VPS (سرور مجازی خصوصی) سخت‌افزار فیزیکی را با سایر مستأجران به اشتراک می‌گذارد؛ بنابراین همان دستگاه ممکن است در ساعت 03:00 یک عدد و در ساعت 20:00 عددی بسیار متفاوت را گزارش کند.

برنامه در اینجا این است که ابتدا yabs.sh را برای یک تصویر کلی سریع اجرا کنید و سپس ابزارهای زیرمجموعه آن را به‌صورت دستی به کار بگیرید. اجرای دستی این ابزارها به شما امکان می‌دهد یک flag را تغییر دهید، تغییر عدد را مشاهده کنید و بفهمید آن عدد واقعاً چه چیزی را اندازه‌گیری می‌کرده است. این کار را پس از راه‌اندازی دستگاه انجام دهید، نه پیش از آن. مراحل موجود در ده دقیقه اول روی یک VPS جدید در اولویت هستند، زیرا سروری که هنوز در حال اعمال اولین دور از به‌روزرسانی‌های خود است، به دلایلی که هیچ ارتباطی به سخت‌افزار ندارند، نتایج بنچمارک ضعیفی ارائه می‌دهد.

پیش از اندازه‌گیری، وضعیت ماشین را بررسی کنید

نیمی از هر بنچمارک نادرست، ناشی از ماشینی است که نویسنده آن را به‌درستی درک نکرده است.

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

Hypervisor vendor: KVM به معنای مجازی‌سازی کامل است، بنابراین شما هسته (kernel) اختصاصی خود را اجرا می‌کنید. چاپ lxc یا openvz توسط systemd-detect-virt به معنای مجازی‌سازی کانتینری است: شما از هسته میزبان به‌صورت اشتراکی استفاده می‌کنید و محدودیت‌های CPU و حافظه شما، تنظیمات cgroup (گروه کنترل) هستند و نه سخت‌افزار مجازی. در سیستم‌های مبتنی بر cgroup v2 می‌توانید محدودیت CPU را مستقیماً بخوانید.

cat /sys/fs/cgroup/cpu.max

max 100000 به معنای نبود سهمیه (quota) است. 200000 100000 به این معناست که شما اجازه دارید در هر دوره 100000 میکروثانیه‌ای، از 200000 میکروثانیه زمان CPU استفاده کنید که معادل سهمیه دو هسته است. طرحی که به‌عنوان 4 vCPU تبلیغ می‌شود اما سهمیه دو هسته دارد، هرگز عملکردی مشابه چهار هسته نخواهد داشت و هیچ ابزار بنچمارکی خطی که دلیل آن را توضیح دهد، چاپ نمی‌کند.

df -hT / به دلیل متفاوتی اهمیت دارد: ستون Type. اگر مقدار آن overlay باشد، شما داخل یک کانتینر هستید و تست دیسک در ادامه، نیاز به تغییر دارد. این موضوع را همین حالا یادداشت کنید.

نظارت مداوم بر steal time

مقدار steal time نشان‌دهنده بخشی از زمان است که CPU مجازی شما آماده اجرا بوده، اما هایپرویزر (hypervisor) هسته فیزیکی را به پردازش دیگری اختصاص داده است. این شاخص، مفیدترین سیگنال برای تشخیص این موضوع است که نتایج عملکرد، تحت تأثیر همسایگان شما در سرور قرار دارد و نه محدودیت‌های سخت‌افزاری خودتان.

vmstat 1 10

ستون st را در سمت راست بخوانید. مقدار ثابت 0 یا 1 طبیعی است. مقادیر پایدار بالای 5 به این معنی است که میزبان (host) در آن لحظه بیش از حد بارگذاری شده است (oversubscribed)؛ بنابراین، تمام اعداد مربوط به CPU که در آن بازه ثبت می‌کنید، بدون اینکه تقصیر ماشین شما باشد، کمتر از حد واقعی هستند. مقدار top همان عددی را نشان می‌دهد که در خط CPU در %st دیده می‌شود. در حین بنچمارک، vmstat 1 را در یک نشست SSH دوم باز نگه دارید و مقدار steal را در کنار هر نتیجه یادداشت کنید.

شروع با 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

فلگ‌ها (Flags) هنگام استفاده از pipe بعد از -s -- و هنگام اجرای نسخه محلی، مستقیماً بعد از نام فایل قرار می‌گیرند. فلگ‌های کاربردی عبارتند از: -f برای پرش از تست دیسک، -i برای پرش از تست شبکه، -g برای پرش از Geekbench، -r برای کاهش موقعیت‌های iperf3 به دو مورد، -j برای چاپ نتایج به صورت JSON و -w results.json برای ذخیره آن JSON در یک فایل.

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

پیش از اولین اجرا دو نکته را در نظر داشته باشید. Geekbench نتایج شما را آپلود کرده و یک URL عمومی در browser.geekbench.com چاپ می‌کند؛ بنابراین هر کسی که این لینک را داشته باشد می‌تواند مدل CPU و امتیازات شما را مشاهده کند. -g این تست را به‌طور کامل حذف می‌کند. دوم اینکه، مرحله iperf3 ترافیک واقعی به سرورهایی در مناطق مختلف ارسال می‌کند که این ترافیک از سهمیه پهنای باند ماهانه شما کسر می‌شود. روی یک لینک 1 Gbit/s، یک مرحله کامل شبکه می‌تواند ده‌ها گیگابایت ترافیک مصرف کند؛ بنابراین اگر سهمیه محدودی دارید از -r و اگر لینک شما دارای محدودیت حجمی است از -i استفاده کنید.

معنای هر بخش از خروجی yabs

بخش دیسک، ابزار fio را با ترکیب 50/50 خواندن و نوشتن در چهار اندازه بلاک اجرا می‌کند: 4k، 64k، 512k و 1m. این بخش برای هر کدام، IOPS (عملیات ورودی/خروجی در ثانیه) و پهنای باند را گزارش می‌دهد. ردیف 4k همان ردیفی است که باید برای دیتابیس، میل‌سرور یا هر برنامه‌ای که نوشتن‌های کوچک و متعدد انجام می‌دهد به آن توجه کنید، زیرا بیشتر IO سرور کوچک و پراکنده است. ردیف 1m برای پشتیبان‌گیری و ویدیو است، جایی که حجم زیادی از داده‌ها را جابه‌جا می‌کنید.

بخش شبکه، iperf3 را در برابر سرورهای عمومی در چندین منطقه، در هر دو جهت و با استفاده از جریان‌های موازی اجرا می‌کند. عدد پایین در اینجا را به عنوان یک پرسش در نظر بگیرید، نه یک پاسخ قطعی؛ زیرا سرورهای عمومی iperf3 اشتراکی هستند و اغلب اشباع می‌شوند، بنابراین نتیجه ضعیف ممکن است مربوط به سمت مقابل باشد.

بخش Geekbench یک امتیاز تک‌هسته‌ای و یک امتیاز چندهسته‌ای ارائه می‌دهد. امتیاز تک‌هسته‌ای پیش‌بینی می‌کند که یک درخواست، یک کامپایل یا یک کوئری با چه سرعتی به پایان می‌رسد. امتیاز چندهسته‌ای عمدتاً به شما می‌گوید که واقعاً چند هسته در اختیار دارید.

اجرای دستی fio برای تست دیسک

ابزار fio (مخفف flexible IO tester) همان ابزاری است که در بخش دیسک yabs استفاده می‌شود و استفاده مستقیم از آن، جایی است که فلگ‌ها اهمیت واقعی خود را نشان می‌دهند.

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

یک تست خواندن تصادفی 4k با عمق صف (queue depth) 32، روی فایل‌سیستمی که برای شما اهمیت دارد:

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 (99.00th percentile) عددی است که ارزش استناد دارد، زیرا نشان‌دهنده مدت زمانی است که کندترین درخواست از هر صد درخواست منتظر مانده است. میانگین تأخیر (average latency)، دقیقاً همان وقایع (stalls) که کاربر متوجه می‌شود را پنهان می‌کند.

• فلگ --direct=1 فایل را با O_DIRECT باز می‌کند تا عملیات خواندن از کش صفحه (page cache) هسته عبور نکند. بدون این فلگ، در دومین دور خواندن یک فایل 2G روی ماشینی با 8G رم، داده‌ها از حافظه سرو می‌شوند و fio تعداد IOPS را در حد میلیون گزارش می‌دهد. آن عدد واقعی است، اما مربوط به حافظه است، نه دیسک.
• فلگ --ioengine=libaio درخواست‌ها را به‌صورت ناهمگام (asynchronous) ارسال می‌کند که به --iodepth=32 اجازه می‌دهد 32 درخواست را همزمان در حال اجرا نگه دارد. با یک موتور همگام (synchronous) مانند psync، عمق صف (iodepth) بالاتر از 1 هیچ تأثیری ندارد و شما فقط یک درخواست را در هر لحظه اندازه‌گیری می‌کنید.
• فلگ --time_based --runtime=60 تست را برای مدت ثابت 60 ثانیه اجرا می‌کند، نه بر اساس حجم کاری ثابت؛ بنابراین دیسک سریع و دیسک کند هر دو زمان یکسانی را صرف می‌کنند و مقایسه منصفانه باقی می‌ماند.
• فلگ --size=2G اندازه فایل تست را تعیین می‌کند. آن را بزرگ‌تر از هر کش موجود در مسیر نگه دارید و ابتدا بررسی کنید که فضای خالی کافی دارید.

تست نوشتن تصادفی (Random write) با همان دستور و استفاده از --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 استفاده کنید. نوع ذخیره‌سازی که روی آن قرار دارید، بیش از هر فلگ دیگری نتایج را تغییر می‌دهد و این تفاوت در تفاوت بین ذخیره‌سازی NVMe و SATA SSD در VPS پوشش داده شده است.

هنگامی که 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 volume) هدایت کنید یا fio را به جای کانتینر، روی میزبان (host) اجرا نمایید. اگر دسترسی به حافظه واقعی ممکن نیست، یک اجرای همگام (synchronous) با استفاده از بافر، حداقل صحت دستور را تأیید می‌کند.

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 در page cache قرار می‌گیرد؛ بنابراین عدد IOPS به‌دست‌آمده، عملکرد RAM شما را توصیف می‌کند. از این روش فقط برای تأیید نصب بودن fio و صحت پارس شدن فلگ‌ها استفاده کنید. هرگز آن را به عنوان نتیجه عملکرد دیسک گزارش نکنید.

چرا dd یک ابزار بنچمارک دیسک نیست

dd در بسیاری از بحث‌های مربوط به VPS دیده می‌شود و تنها به یک پرسش محدود پاسخ می‌دهد.

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

این دستور، نرخ انتقال (throughput) نوشتن ترتیبی را با یک ترد و یک درخواست در حال اجرا اندازه‌گیری می‌کند. این یک بررسی سلامت (sanity check) معقول است. اما هیچ اطلاعاتی درباره IO تصادفی و یا رفتار سیستم هنگام ورود همزمان 32 درخواست ارائه نمی‌دهد. اگر oflag=direct را حذف کنید، این دستور عمدتاً سرعت پذیرش داده‌ها توسط کرنل در حافظه (RAM) را اندازه‌گیری می‌کند؛ به همین دلیل است که ارقام dd که در پست‌های انجمن‌ها نقل می‌شوند، اغلب غیرمنطقی هستند.

پردازنده: 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 یا یک عملیات کامپایل است و بیشترین تفاوت را بین میزبان‌هایی با قیمت یکسان نشان می‌دهد. سپس تست را با تمام رشته‌ها اجرا کنید؛ این کار مشخص می‌کند که 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 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 است و در هر ماشینی، سرعت خواندن بیشتر از نوشتن است. مقدار --memory-block-size را روی 1M نگه دارید و آن را در تمام میزبان‌هایی که مقایسه می‌کنید، یکسان حفظ کنید. در 1K، عدد به‌شدت افت می‌کند، زیرا هزینه سربار هر عملیات را هزار برابر بیشتر پرداخت می‌کنید؛ بنابراین به‌جای پهنای باند حافظه، هزینه حلقه را اندازه‌گیری می‌کنید. این رایج‌ترین پرچم (flag) ناهماهنگ در امتیازات منتشرشده برای حافظه است.

شبکه: iperf3

روش صادقانه برای تست پهنای باند، استفاده از یک ماشین دوم است که تحت کنترل شما باشد؛ زیرا در این صورت می‌دانید در هر دو سمت چه اتفاقی می‌افتد.

در سمت مقصد:

iperf3 -s

iperf3 -s

این دستور روی پورت TCP 5201 گوش می‌دهد. پورت را فقط برای آدرسی که از آن تست می‌گیرید باز کنید و پس از پایان کار، آن را ببندید. قوانین پایه فایروال ufw روی یک VPS نحو (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

iperf3 -c <remote-ip>

دستور اول، سرعت آپلود از ماشینی که تحت تست است را اندازه‌گیری می‌کند. فلگ -R جهت را معکوس می‌کند که سرعت دانلود را می‌سنجد. فلگ -P 8 هشت استریم موازی باز می‌کند.

هر دو حالت تک‌استریم و موازی را اجرا کنید، زیرا پاسخ‌گوی پرسش‌های متفاوتی هستند. یک اتصال TCP تنها تا حدی می‌تواند داده‌های تاییدنشده (unacknowledged) را نگه دارد که پنجره (window) آن اجازه می‌دهد؛ بنابراین سقف سرعت آن تقریباً برابر است با اندازه پنجره تقسیم بر زمان رفت و برگشت (RTT). با تاخیر 80 میلی‌ثانیه و پنجره 4 مگابایتی، این سقف حدود 400 مگابیت بر ثانیه است، فارغ از اینکه سرعت لینک زیرساختی چقدر باشد. عدد حاصل از تک‌استریم به شما می‌گوید که یک دانلود تکی چه سرعتی خواهد داشت. عدد حاصل از حالت موازی، ظرفیت کلی لینک را نشان می‌دهد.

هنگام انجام این کار، مراقب سهمیه پهنای باند خود باشید. 30 ثانیه تست با سرعت 1 گیگابیت بر ثانیه، حدود 3.75 گیگابایت داده جابه‌جا می‌کند و شما احتمالاً آن را چندین بار در هر جهت اجرا خواهید کرد.

اعداد مرجع و نحوه خواندن نتایج خود

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

یک volume محلی NVMe در نتایج منتشرشده معمولاً به حدود 180,000 عملیات IOPS خواندن تصادفی 4k می‌رسد. یک SATA SSD محلی در حدود 90,000 قرار می‌گیرد. فضای ذخیره‌سازی بلوکی متصل به شبکه (Network attached block storage)، که در آن هر درخواست پیش از رسیدن به دیسک از شبکه عبور می‌کند، به حدود 12,000 نزدیک‌تر است و یک دیسک چرخان (HDD) تقریباً 180 را مدیریت می‌کند، زیرا برای هر درخواست تصادفی باید هد فیزیکی خود را جابه‌جا کند.

این‌ها ارقام معمول منتشرشده برای هر کلاس از فضای ذخیره‌سازی هستند، نه اندازه‌گیری‌های انجام‌شده از یک میزبان واحد. از آن‌ها فقط برای یک هدف استفاده کنید: بررسی اینکه نتیجه خودتان در مرتبه بزرگی درستی قرار دارد یا خیر. اگر طرحی که به عنوان NVMe فروخته می‌شود، در بنچمارک‌ها تنها چند هزار IOPS برای 4k نشان می‌دهد، ابتدا تأیید کنید که --direct=1 فعال بوده است. اگر فعال بود، یا فضای ذخیره‌سازی آن چیزی نیست که در صفحه محصول توصیف شده، یا شما در حال اشتراک آن با یک همسایه بسیار پرمصرف هستید.

چرا یک بار اجرا، بنچمارک محسوب نمی‌شود

یک نتیجهٔ واحد، تنها تصویری از یک دقیقه وضعیت یک ماشین اشتراکی است. با آن به عنوان یک نمونه برخورد کنید.

• هر تست را حداقل 5 بار و در ساعات مختلف و حداقل در 2 روز متفاوت اجرا کنید. میانه و دامنهٔ تغییرات را نگه دارید. نتیجه‌ای که بدون دامنهٔ تغییرات منتشر شود، صرفاً یک عدد تبلیغاتی است.
• زمان steal time را در کنار هر اجرا ثبت کنید. اجراهایی که در آن‌ها st بالا بوده است را کنار بگذارید یا حداقل آن را یادداشت کنید.
• تست دیسک را با 2 مدت‌زمان مختلف اجرا کنید. بسیاری از پلن‌ها اجازهٔ burst IOPS می‌دهند که به مرور زمان پر می‌شود؛ بنابراین یک اجرای 60 ثانیه‌ای fio میزان burst را اندازه می‌گیرد، در حالی که --runtime=600 کف عملکرد را می‌سنجد. کف عملکرد همان چیزی است که در یک روز بد دریافت می‌کنید.
• مطمئن شوید هیچ چیز دیگری در حال اجرا نیست. شروع یک تراکنش apt توسط unattended-upgrades در میانهٔ یک تست CPU، امتیازات واقعی شما را کاهش می‌دهد و اجرای ps -e -o comm= | grep -E 'apt|dpkg' پیش از هر تست، یک ثانیه زمان می‌برد.
• در هر مرحله فقط یک متغیر را تغییر دهید. نسخه‌های مختلف ابزار، اندازه‌های بلاک یا تعداد threadها، اعدادی تولید می‌کنند که صرف‌نظر از شباهت ظاهری، قابل مقایسه با یکدیگر نیستند.

هنگامی که دو ارائه‌دهنده را با هم مقایسه می‌کنید، آن‌ها را در یک ساعت از یک روز مشابه اجرا کنید. در غیر این صورت، شما صرفاً زمانِ روز را اندازه‌گیری کرده‌اید.

سنجش عملکرد با بار کاری اختصاصی خودتان در مرحله آخر

ابزارهای مصنوعی (Synthetic) ماشین‌ها را رتبه‌بندی می‌کنند. تنها بار کاری اختصاصی شماست که مشخص می‌کند آیا یک ماشین برای نیازتان کافی است یا خیر. مدت‌زمان انجام کاری که واقعاً با آن سروکار دارید را اندازه‌گیری کنید.

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

این دستور چند صد مگابایت داده را فشرده می‌کند، بنابراین همزمان CPU و دیسک را درگیر کرده و با تغییر هر یک از آن‌ها، نتیجه تغییر می‌کند. هشدار Removing leading / from member names طبیعی است. حتی بهتر است زمان بیلد (build) اختصاصی خود، کندترین کوئری یا رندر صفحه خود را اندازه‌گیری کنید. اگر یک بیلد روی یک میزبان 4 دقیقه و روی دیگری 7 دقیقه طول بکشد، فارغ از اینکه Geekbench چه امتیازی داده است، موضوع حل شده است. این همان معیاری است که به شما می‌گوید چه زمانی افزایش قدرت سخت‌افزار دیگر ارزش هزینه کردن ندارد؛ دانستن این موضوع پیش از مطالعه هزینه واقعی ماهانه یک VPS یا انتقال بار کاری به یک سرور اختصاصی اهمیت دارد.

FAQ

چرا هر بار که بنچمارک را اجرا می‌کنم، نتیجه متفاوتی می‌گیرم؟

یک VPS منابع CPU، فضای ذخیره‌سازی و شبکه فیزیکی را با سایر مستأجران به اشتراک می‌گذارد، بنابراین نتیجه شما به فعالیت آن‌ها در آن لحظه بستگی دارد. در حین تست، vmstat 1 را اجرا کنید و ستون st را بخوانید: اگر زمان steal پایدار بالای 5 باشد، یعنی میزبان مشغول بوده و امتیاز CPU شما به دلایلی خارج از کنترل ماشین شما پایین است. پاسخ در روش‌شناسی است، نه در تنظیمات. هر تست را پنج بار یا بیشتر در ساعات مختلف اجرا کنید و سپس میانه (median) را به همراه دامنه تغییرات گزارش دهید.

چرا fio میلیون‌ها IOPS گزارش می‌دهد؟

تقریباً همیشه به این دلیل است که --direct=1 فراموش شده است. بدون آن، fio از طریق کش صفحه کرنل (kernel page cache) می‌خواند؛ بنابراین پس از اولین اجرا، یک فایل تست 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. ارقام مربوط به throughput چشمگیر به نظر می‌رسند اما به‌ندرت تعیین‌کننده هستند، زیرا یک درخواست معمولی کوچک است. به‌جای میانگین، صدک 99 (99th percentile) را از بلوک clat percentiles در fio گزارش کنید، زیرا همان یک درخواست کند از هر صد درخواست است که کاربر متوجه آن می‌شود.

آیا پیش از بنچمارک نیاز به نصب چیزی دارم؟

fio، sysbench و iperf3 همگی در مخازن Ubuntu و Debian موجود هستند: sudo apt install -y fio sysbench iperf3. yabs.sh فقط به curl نیاز دارد، زیرا باینری‌های استاتیک را برای هر چیزی که موجود نباشد دانلود می‌کند. پس از پایان کار، تمام فایل‌های تست را حذف کنید، زیرا یک فایل 2G مربوط به fio که روی یک دیسک 20G باقی مانده، می‌تواند هفته‌ها بعد باعث هشدار پر شدن دیسک برای کسی شود.