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

بنچ‌مارک کردن یک VPS به چه معناست

برای بنچ‌مارک کردن یک VPS، چهار مورد را اندازه‌گیری می‌کنید: سرعت اجرای یک هسته CPU، پهنای باند حافظه (RAM)، تعداد عملیات کوچک و تصادفی دیسک در هر ثانیه، و میزان پهنای باند شبکه. یک بار اجرای yabs.sh نتایج CPU، دیسک و شبکه را در حدود ده دقیقه به شما می‌دهد؛ برای پهنای باند حافظه از تست جداگانه‌ای که در ادامه آمده استفاده کنید. تفسیر نتایج بخش دشوارتر کار است، زیرا یک 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 را از cgroup کانتینر خود بخوانید؛ مسیر زیر زمانی معتبر است که آن cgroup در /sys/fs/cgroup مونت شده باشد.

cat /sys/fs/cgroup/cpu.max

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

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

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

مقدار steal time نشان‌دهنده بخشی از زمان است که CPU مجازی شما به‌طور غیرارادی در انتظار سپری کرده، زیرا هایپروایزر آن را زمان‌بندی نکرده است. این شاخص سیگنال مفیدی برای تشخیص عدم دسترسی به زمان CPU است، اما تفاوت بین همسایه‌های پرمشغله و اعمال سهمیه CPU توسط ارائه‌دهنده را مشخص نمی‌کند.

vmstat 1 10

ستون st را در سمت راست بخوانید. وجود steal time پایدار به این معناست که زمان CPU برای سیستم‌عامل مهمان در دسترس نبوده است، اما مقدار بالای 5% لزوماً به معنای oversubscribed بودن میزبان نیست. ارائه‌دهندگان ممکن است اعمال سهمیه CPU را به‌عمد به‌عنوان steal time نمایش دهند. مقدار top همان عددی است که در %st در خط CPU مشاهده می‌شود. در حین انجام بنچمارک، vmstat 1 را در یک نشست SSH دوم باز نگه دارید و مقدار steal را در کنار هر نتیجه یادداشت کنید.

شروع با yabs.sh

yabs.sh (Yet Another Bench Script) یک اسکریپت shell است که fio، iperf3 و Geekbench را اجرا کرده و یک خروجی خلاصه ارائه می‌دهد. این ابزار در صورت نصب بودن fio و iperf3 از آن‌ها استفاده می‌کند و در غیر این صورت، باینری‌های استاتیک را دانلود می‌کند. این اسکریپت زبان مشترک بحث‌های بنچمارک VPS است، بنابراین خروجی yabs سریع‌ترین راه برای مقایسه نتایج با دیگران است.

دستور تک‌خطی خود پروژه به این صورت است.

curl -sL yabs.sh | bash

این دستور هر آنچه را که URL در حال حاضر ارائه می‌دهد، مستقیماً به یک shell ارسال می‌کند. آن را دانلود کنید، بخوانید و سپس اجرا کنید.

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

فلگ‌ها هنگام استفاده از 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 و در صورت استفاده از لینک‌های دارای محدودیت حجمی (metered) از -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 در همهٔ سیستم‌فایل‌ها در دسترس نیست؛ بنابراین وقتی fio در اولین درخواست خود با تنظیم --direct=1 شکست می‌خورد، اولین چیزی که باید بررسی کنید همین قابلیت است. این خطا ممکن است به شکل زیر نمایش داده شود:

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 که Docker به‌صورت پیش‌فرض به کانتینر اختصاص می‌دهد، به‌تنهایی عامل این خطا نیست. سیستم O_DIRECT درخواست‌های O_DIRECT را به سیستم‌فایل زیرین منتقل می‌کند و تنها زمانی آن را رد می‌کند که سیستم‌فایل زیرین قادر به انجام Direct IO نباشد؛ بنابراین --direct=1 --ioengine=libaio روی یک overlay که بر پایه ext4 یا xfs قرار دارد، به‌درستی کار می‌کند. هنگامی که سیستم‌فایل زیرِ فایلِ تست واقعاً قادر به انجام Direct IO نباشد، fio معمولاً هنگام باز کردن فایل این موضوع را اعلام می‌کند: fio: looks like your file system does not support direct=1/buffered=0. در این حالت، --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 تصادفی (random IO) ارائه نمی‌دهد و مشخص نمی‌کند وقتی 32 درخواست به‌طور هم‌زمان می‌رسند، چه اتفاقی می‌افتد. اگر oflag=direct را حذف کنید، عملیات نوشتن از طریق page cache انجام می‌شود، اما conv=fdatasync همچنان داده‌های خروجی را پیش از پایان دستور، مجبور به انتقال به حافظه ذخیره‌سازی می‌کند. اگر این پارامتر را هم حذف کنید، نتیجه عمدتاً سرعت پذیرش داده‌ها توسط کرنل در حافظه رم را اندازه‌گیری می‌کند؛ به همین دلیل است که ارقام 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 یا یک عملیات کامپایل است و بیشترین تفاوت را میان میزبان‌هایی با قیمت یکسان نشان می‌دهد. سپس تست را با تمام رشته‌ها اجرا کنید تا مشخص شود توان عملیاتی (throughput) در میان vCPUهای تخصیص‌یافته شما چگونه مقیاس‌پذیر است.

دقیقاً بدانید که این ابزار چه چیزی را اندازه‌گیری می‌کند: sysbench cpu به‌طور مکرر با استفاده از روش تقسیم آزمایشی، اعداد اول را پیدا می‌کند. برای هر عدد کاندید، یک جذر با دقت مضاعف (double precision) می‌گیرد و سپس مقسوم‌علیه‌ها را با استفاده از عملگر modulo برای اعداد صحیح 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 عدد به‌دست‌آمده به‌شدت افت می‌کند، زیرا هزینهٔ سربار هر عملیات را هزاران برابر بیشتر پرداخت می‌کنید؛ بنابراین در نهایت به‌جای پهنای باند حافظه، هزینهٔ حلقه (loop cost) را اندازه‌گیری می‌کنید. این پرچم (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 عملیات خواندن تصادفی 4k در ثانیه (IOPS) می‌رسد. یک SATA SSD محلی در حدود 90,000 قرار می‌گیرد. فضای ذخیره‌سازی بلوکی متصل به شبکه (Network attached block storage)، که در آن هر درخواست پیش از رسیدن به دیسک از شبکه عبور می‌کند، به حدود 12,000 نزدیک‌تر است و یک دیسک چرخان (HDD) تقریباً 180 را مدیریت می‌کند، زیرا برای هر درخواست تصادفی باید یک هد فیزیکی را جابه‌جا کند.

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

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

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

• هر تست را حداقل 5 بار اجرا کنید؛ این اجراها را در ساعات مختلف و حداقل در 2 روز متفاوت پخش کنید. میانه (median) و دامنهٔ تغییرات (spread) را نگه دارید. نتیجه‌ای که بدون ذکر دامنهٔ تغییرات منتشر شود، صرفاً یک عدد تبلیغاتی است.
• در کنار هر اجرا، میزان steal time را ثبت کنید. اجراهایی که در آن‌ها st بالا بوده است را نگه دارید و بررسی کنید که آیا این موضوع نشان‌دهندهٔ رقابت بر سر منابع (contention) است یا محدودیت CPU quota در پلن؛ حذف این داده‌ها می‌تواند عملکرد واقعی دریافتی شما را پنهان کند.
• تست دیسک را با دو مدت‌زمان متفاوت اجرا کنید. بسیاری از پلن‌ها یک سهمیه IOPS برای burst ارائه می‌دهند که به‌مرور زمان پر می‌شود، اما نه یک اجرای 60 ثانیه‌ای fio و نه --runtime=600 تضمین نمی‌کنند که شما کف عملکرد (floor) را اندازه‌گیری کرده‌اید. اعتبار AWS gp2 می‌تواند حداقل 30 دقیقه از یک موجودی کامل، 3,000 IOPS را حفظ کند، بنابراین هر دو اجرا ممکن است عملکرد burst را اندازه‌گیری کنند. مدل اعتباری ارائه‌دهنده را بررسی کنید و پیش از آنکه نتیجه‌ای را عملکرد پایدار (sustained performance) بنامید، موجودی اعتبار را مانیتور کنید.
• مطمئن شوید هیچ چیز دیگری در حال اجرا نیست. شروع یک تراکنش apt توسط unattended-upgrades در میانهٔ یک تست CPU، امتیاز واقعی شما را کاهش می‌دهد و اجرای ps -e -o comm= | grep -E 'apt|dpkg' پیش از هر تست، یک ثانیه زمان می‌برد.
• در هر مرحله فقط یک متغیر را تغییر دهید. نسخه‌های مختلف ابزار، اندازه بلاک‌ها یا تعداد تردها، اعدادی تولید می‌کنند که فارغ از شباهت ظاهری، قابل مقایسه با یکدیگر نیستند.

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

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

ابزارهای مصنوعی (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 time نشان‌دهنده زمان در دسترس نبودن CPU است، اما می‌تواند هم نشان‌دهنده اعمال محدودیت سهمیه CPU توسط ارائه‌دهنده و هم نشان‌دهنده رقابت بر سر منابع در میزبان (host) باشد. مقداری بالاتر از 5 درصد به تنهایی علت را مشخص نمی‌کند. پاسخ در روش‌شناسی است، نه در تنظیمات. هر تست را پنج بار یا بیشتر در ساعات مختلف اجرا کنید و سپس میانه (median) نتایج را به همراه دامنه تغییرات گزارش دهید.

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

تقریباً همیشه به این دلیل است که --direct=1 فراموش شده است. بدون آن، fio از طریق kernel page cache می‌خواند؛ بنابراین پس از دور اول، یک فایل تست 2G از طریق RAM سرویس‌دهی می‌شود و شما در واقع پهنای باند حافظه را اندازه‌گیری کرده‌اید. --direct=1 را اضافه کنید و فایل تست را بزرگ‌تر از هر کش موجود در مسیر نگه دارید. اگر --direct=1 با خطا مواجه شد، df -hT . را اجرا کنید و بررسی کنید فایل تست روی چه چیزی قرار دارد. نوع overlay به خودی خود مشکل‌ساز نیست، زیرا overlayfs دستور O_DIRECT را به فضای ذخیره‌سازی زیرین منتقل می‌کند. تنها در صورتی فایل تست را به فضای ذخیره‌سازی محلی واقعی منتقل کنید که فایل‌سیستم زیرین از direct IO پشتیبانی نکند.

آیا yabs.sh به تنهایی کافی است؟

برای یک بررسی اولیه، بله. این ابزار fio را در چهار اندازه بلاک، iperf3 را در هر دو جهت و Geekbench را اجرا می‌کند و یک خلاصه قابل‌فهم برای دیگران ارائه می‌دهد. زمانی که می‌خواهید بدانید چرا یک عدد خاص به دست آمده است، این ابزار دیگر کافی نیست، زیرا نمی‌توانید پرچم‌های (flags) آن را برای هر تست تغییر دهید. هنگامی که نتیجه yabs غیرعادی به نظر می‌رسد، آن را مستقیماً با fio یا sysbench بازتولید کنید و هر بار فقط یک پرچم را تغییر دهید.

کدام عدد واحد، تجربه کاربری برنامه من را پیش‌بینی می‌کند؟

برای اکثر بارهای کاری وب و دیتابیس، به ترتیب سرعت تک‌هسته‌ای CPU و تأخیر (latency) خواندن تصادفی 4k. ارقام مربوط به توان عملیاتی (throughput) چشمگیر به نظر می‌رسند اما به‌ندرت تعیین‌کننده هستند، زیرا یک درخواست معمولی حجم کمی دارد. به جای میانگین، صدک نود و نهم (99th percentile) را از بلوک clat percentiles در fio گزارش دهید، زیرا همان یک درخواست کند از هر صد درخواست، چیزی است که کاربر متوجه آن می‌شود.

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

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