VPS کی درست benchmark کیسے کریں؟

VPS کی benchmark سے کیا مراد ہے

VPS کی benchmark کے لیے آپ 4 چیزیں ناپتے ہیں: ایک CPU core کتنی رفتار سے چلتا ہے، مشین کی memory bandwidth کتنی ہے، storage ہر second کتنے چھوٹے random disk operations فراہم کرتی ہے، اور network link کتنی throughput فراہم کرتا ہے۔ yabs.sh کو ایک بار چلانے سے تقریباً 10 minutes میں یہ چاروں نتائج مل جاتے ہیں۔ نتائج کو سمجھنا زیادہ مشکل حصہ ہے، کیونکہ VPS دوسرے tenants کے ساتھ physical hardware شیئر کرتا ہے۔ اس لیے ایک ہی مشین 03:00 بجے ایک number اور 20:00 بجے اس سے بہت مختلف number دکھا سکتی ہے۔

یہاں طریقہ یہ ہے کہ فوری جائزے کے لیے پہلے yabs.sh چلائیں، پھر اس کے اندر استعمال ہونے والے tools کو خود چلائیں۔ انہیں خود چلانے سے آپ ایک flag تبدیل کر سکتے ہیں، number میں آنے والی تبدیلی دیکھ سکتے ہیں، اور سمجھ سکتے ہیں کہ وہ number حقیقت میں کیا ناپ رہا تھا۔ یہ کام مشین set up ہونے کے بعد کریں، پہلے نہیں۔ نئے VPS کے پہلے 10 minutes کے مراحل پہلے مکمل کریں، کیونکہ جو box ابھی updates کے پہلے مرحلے کا اطلاق کر رہا ہو، اس کی benchmark ایسے اسباب کی وجہ سے خراب آتی ہے جن کا hardware سے کوئی تعلق نہیں ہوتا۔

مشین کی پیمائش سے پہلے اسے سمجھیں

ہر خراب 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 limits virtual hardware کے بجائے cgroup (control group) settings ہوتی ہیں۔ cgroup v2 والے system پر CPU limit براہِ راست پڑھی جا سکتی ہے۔

cat /sys/fs/cgroup/cpu.max

max 100000 کا مطلب ہے کہ کوئی quota مقرر نہیں ہے۔ 200000 100000 کا مطلب ہے کہ ہر 100000% microsecond period میں CPU کے 200000% microseconds استعمال کیے جا سکتے ہیں، یعنی quota کے لحاظ سے دو cores۔ اگر کسی plan کی تشہیر 4 vCPU کے طور پر کی گئی ہو لیکن quota دو cores کا ہو، تو اس کا benchmark score کبھی بھی چار cores جیسا نہیں ہوگا، اور کوئی benchmark tool ایسی سطر نہیں دکھاتا جو اس کی وجہ بتائے۔

df -hT / ایک مختلف وجہ سے اہم ہے: Type column۔ اگر اس میں overlay لکھا ہو تو آپ container کے اندر ہیں، اور نیچے دیا گیا disk test تبدیل کرنا ہوگا۔ اسے ابھی نوٹ کر لیں۔

مسلسل steal time کی نگرانی کریں

steal time اس وقت کا حصہ ہے جب آپ کا virtual CPU چلنے کے لیے تیار تھا، لیکن hypervisor نے physical core کسی دوسرے کام کو دے دیا۔ یہ جاننے کے لیے سب سے مفید واحد اشارہ ہے کہ نتیجہ پڑوسی virtual machines کی وجہ سے ہے، hardware کی وجہ سے نہیں۔

vmstat 1 10

دائیں جانب موجود st column دیکھیں۔ مسلسل 0 یا 1 معمول ہے۔ 5 سے زیادہ کی مسلسل values کا مطلب ہے کہ اس وقت host پر وسائل کی طلب دستیاب وسائل سے زیادہ ہے۔ اس لیے اس مدت میں ریکارڈ کیا گیا ہر CPU number آپ کی machine کی کسی خرابی کے بغیر کم ہوگا۔ top، CPU line پر %st کے طور پر یہی figure دکھاتا ہے۔ Benchmark چلاتے وقت vmstat 1 کو دوسری SSH session میں جاری رکھیں، اور ہر result کے ساتھ steal figure بھی لکھیں۔

yabs.sh سے آغاز کریں

yabs.sh (Yet Another Bench Script) ایک shell script ہے جو static fio، iperf3 اور Geekbench binaries ڈاؤن لوڈ کرتی ہے، انہیں چلاتی ہے، اور ایک خلاصہ دکھاتی ہے۔ VPS benchmark مباحث میں یہی عام زبان ہے، اس لیے yabs output کسی دوسرے شخص کے نتائج سے فوری موازنہ کرنے کا تیز ترین طریقہ ہے۔

پروجیکٹ کی اپنی one-line شکل یہ ہے۔

curl -sL yabs.sh | bash

یہ URL سے اس وقت دستیاب مواد کو براہِ راست shell میں pipe کرتی ہے۔ اسے پہلے ڈاؤن لوڈ کریں، پڑھیں، پھر چلائیں۔

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

جب آپ pipe استعمال کریں تو flags، -s -- کے بعد لگائیں۔ مقامی copy چلاتے وقت flags، filename کے فوراً بعد لگائیں۔ مفید flags یہ ہیں: -f disk test کو چھوڑتا ہے، -i network test کو چھوڑتا ہے، -g Geekbench کو چھوڑتا ہے، -r iperf3 locations کی تعداد کم کرکے دو کر دیتا ہے، -j نتائج کو JSON کے طور پر دکھاتا ہے، اور -w results.json اس JSON کو ایک file میں لکھتا ہے۔

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

پہلی run سے پہلے دو باتیں جان لیں۔ Geekbench آپ کا result upload کرتا ہے اور public browser.geekbench.com URL دکھاتا ہے، اس لیے جس کے پاس یہ link ہو وہ آپ کے CPU model اور scores پڑھ سکتا ہے۔ -g اس test کو مکمل طور پر چھوڑ دیتا ہے۔ دوسری بات یہ ہے کہ iperf3 stage کئی regions میں موجود servers کو حقیقی network traffic بھیجتا ہے، اور یہ آپ کی ماہانہ bandwidth allowance میں شمار ہوتا ہے۔ 1 Gbit/s link پر مکمل network stage دسیوں gigabytes منتقل کر سکتا ہے، اس لیے کم allowance کی صورت میں -r اور metered link پر -i استعمال کریں۔

yabs آؤٹ پٹ کے ہر حصے کا مطلب

ڈسک کا حصہ fio کو 4 block sizes پر 50/50 read اور write mix کے ساتھ چلاتا ہے: 4k، 64k، 512k اور 1m۔ یہ ہر block size کے لیے IOPS (input/output operations per second) اور bandwidth رپورٹ کرتا ہے۔ Database، mail server یا بہت سی چھوٹی writes کرنے والی کسی بھی سروس کے لیے 4k والی row اہم ہے، کیونکہ زیادہ تر server IO چھوٹا اور غیر متواتر ہوتا ہے۔ Backups اور video کے لیے 1m والی row اہم ہے، جہاں bytes کے طویل سلسلے منتقل کیے جاتے ہیں۔

Network کا حصہ متعدد regions میں موجود public servers کے خلاف iperf3 چلاتا ہے۔ یہ دونوں directions میں parallel streams استعمال کرتا ہے۔ یہاں کم number کو حتمی نتیجے کے بجائے مزید جانچ کا اشارہ سمجھیں، کیونکہ public iperf3 servers مشترکہ ہوتے ہیں اور اکثر saturated رہتے ہیں۔ اس لیے خراب result کی وجہ دوسری جانب کا server بھی ہو سکتا ہے۔

Geekbench کا حصہ single core score اور multi core score فراہم کرتا ہے۔ Single core score سے اندازہ ہوتا ہے کہ ایک request، ایک compile یا ایک query کتنی تیزی سے مکمل ہوگی۔ Multi core score بنیادی طور پر یہ بتاتا ہے کہ آپ کو حقیقت میں کتنے cores ملے ہیں۔

Disk: خود fio چلائیں

fio (flexible IO tester) وہ tool ہے جو yabs کے disk section کے نیچے کام کرتا ہے، اور اسے براہِ راست چلانے سے flags کا اصل مطلب واضح ہوتا ہے۔

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

queue depth 32 کے ساتھ، اسی filesystem پر 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 وہ figure ہے جسے quote کرنا چاہیے، کیونکہ یہ بتاتا ہے کہ ہر 100 requests میں سب سے سست request نے کتنا وقت انتظار کیا۔ average latency ان stalls کو چھپا دیتی ہے جنہیں user محسوس کرتا ہے۔

• --direct=1 file کو O_DIRECT کے ساتھ کھولتا ہے، اس لیے reads kernel page cache کو bypass کرتی ہیں۔ اس کے بغیر، 8G RAM والی machine پر 2G file کا دوسرا pass memory سے serve ہوتا ہے، اور fio لاکھوں IOPS report کرتا ہے۔ یہ number حقیقی ہے، لیکن یہ memory کا number ہے۔
• --ioengine=libaio asynchronous requests submit کرتا ہے، جس سے --iodepth=32 ان میں سے 32 کو in flight رکھ سکتا ہے۔ `psync` جیسے synchronous engine کے ساتھ 1 سے زیادہ iodepth کا کوئی اثر نہیں ہوتا، اس لیے آپ ایک وقت میں صرف ایک request measure کرتے ہیں۔
• --time_based --runtime=60 fixed amount of work کے بجائے fixed 60 seconds تک چلتا ہے، اس لیے fast disk اور slow disk دونوں کو یکساں wall-clock time ملتا ہے اور comparison منصفانہ رہتا ہے۔
• --size=2G test file کا size مقرر کرتا ہے۔ اسے path میں موجود کسی بھی cache سے بڑا رکھیں، اور پہلے یہ دیکھ لیں کہ free space دستیاب ہے۔

Random write کے لیے یہی command --rw=randwrite کے ساتھ چلائیں۔ اسے الگ سے run کریں، پھر 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 پر کام کر رہے ہیں، وہ ان results کو کسی بھی flag سے زیادہ بدلتی ہے، اور یہ فرق VPS پر NVMe اور SATA SSD storage کے درمیان فرق میں بیان کیا گیا ہے۔

جب fio Unknown error -1 کے ساتھ رک جائے

ہر filesystem پر Direct IO دستیاب نہیں ہوتی۔ overlay، جو Docker کسی container کو بطور default دیتا ہے، اور متعدد network filesystems O_DIRECT کو support نہیں کرتے۔ اس لیے libaio ایسی request submit کرتا ہے جسے 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 column میں overlay لکھا ہو تو --filename کو real storage پر موجود path کی طرف point کریں، مثلاً bind mounted volume، یا container کے بجائے host پر fio چلائیں۔ اگر real storage تک رسائی ممکن نہ ہو تو buffered synchronous run کم از کم یہ ثابت کر دیتا ہے کہ command خود درست ہے۔

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 figure آپ کی RAM کی کارکردگی بیان کرتا ہے۔ اسے fio کے installed ہونے اور flags کے درست parse ہونے کی تصدیق کے لیے استعمال کریں۔ اسے disk result کے طور پر کبھی report نہ کریں۔

dd ڈسک 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 requests آنے پر کیا ہوتا ہے۔ oflag=direct ہٹا دیں تو یہ زیادہ تر اس رفتار کو ناپتا ہے جس سے آپ کا kernel writes کو memory میں قبول کرتا ہے۔ اسی وجہ سے forum posts میں دیے گئے 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 مکمل ہونے میں کتنا وقت لگتا ہے، اور یکساں قیمت والے hosts کے درمیان اسی میں سب سے زیادہ فرق ہوتا ہے۔ پھر اسے تمام threads کے ساتھ چلائیں۔ اس سے معلوم ہوتا ہے کہ آپ کے vCPUs الگ cores ہیں یا ایک ہی core کے حصے ہیں۔

واضح رہے کہ یہ test کیا ناپتا ہے: sysbench cpu، 64 bit integer arithmetic استعمال کرتے ہوئے prime numbers تلاش کرنے کا عمل بار بار انجام دیتا ہے۔ یہ memory bandwidth، vector units یا cache کو ایسے انداز میں stress نہیں کرتا جو حقیقی workload سے مماثل ہو۔ اس لیے دو hosts کی درجہ بندی کے لیے یہ مفید ہے، لیکن یہ پیش گوئی کرنے کے لیے موزوں نہیں کہ آپ کی application کیسے چلے گی۔

Ubuntu 24.04 میں sysbench 1.0.20 شامل ہے، جس میں test name پہلے آتا ہے۔ کسی پرانی post سے --test=cpu والی command copy کریں تو آپ کو WARNING: the --test option is deprecated ملتا ہے۔ sysbench 0.4 اور sysbench 1.0 کے scores ایک دوسرے سے بالکل قابلِ موازنہ نہیں ہیں، اس لیے کبھی بھی ایسے 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 میں ہوتا ہے، اور ہر مشین پر reads کی رفتار writes سے زیادہ ہوتی ہے۔ --memory-block-size کو 1M پر رکھیں اور جن hosts کا موازنہ کریں، ان سب پر اسے یکساں رکھیں۔ 1K پر یہ عدد نمایاں طور پر کم ہو جاتا ہے، کیونکہ ہر operation کا اضافی خرچ ایک ہزار گنا زیادہ بار ادا کرنا پڑتا ہے۔ اس طرح آپ memory bandwidth کے بجائے loop cost کی پیمائش کرنے لگتے ہیں۔ شائع شدہ memory scores میں یہی وہ flag ہے جس میں سب سے زیادہ عدم مطابقت پائی جاتی ہے۔

نیٹ ورک: iperf3

تھروپٹ جانچنے کا درست طریقہ یہ ہے کہ اسے اپنے زیرِ انتظام دوسری مشین کے ساتھ جانچا جائے، کیونکہ اس صورت میں آپ کو معلوم ہوتا ہے کہ دونوں سروں پر کیا ہو رہا ہے۔

دوسرے سرے پر:

iperf3 -s

یہ TCP 5201 پر listen کرتا ہے۔ پورٹ صرف اس پتے کے لیے کھولیں جہاں سے آپ test چلا رہے ہیں، اور کام مکمل ہونے پر اسے بند کر دیں۔ VPS پر بنیادی ufw firewall rules میں 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 streams کھولتا ہے۔

Single stream اور parallel version دونوں چلائیں، کیونکہ دونوں مختلف سوالوں کے جواب دیتے ہیں۔ ایک TCP connection اتنے ہی unacknowledged data کو برقرار رکھ سکتا ہے جتنے کی اجازت اس کا window دیتا ہے۔ اس لیے اس کی زیادہ سے زیادہ رفتار تقریباً window size کو round trip time سے تقسیم کرنے کے برابر ہوتی ہے۔ 80 ms latency اور 4 MB window پر یہ حد تقریباً 400 Mbit/s بنتی ہے، چاہے اس کے نیچے موجود link کتنی ہی تیز ہو۔ Single stream کا نتیجہ بتاتا ہے کہ ایک download کو کتنی رفتار ملے گی۔ Parallel نتیجہ link کی capacity بتاتا ہے۔

یہ test چلاتے وقت اپنی bandwidth allowance پر نظر رکھیں۔ 1 Gbit/s پر 30 seconds میں تقریباً 3.75 GB data منتقل ہوتا ہے، اور آپ یہ test ہر سمت میں کئی بار چلائیں گے۔

حوالہ جاتی اعداد، اور اپنے اعداد کو کیسے پڑھیں

[
  {
    "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 volume عموماً 180,000 4k random read IOPS کے قریب ہوتا ہے۔ مقامی SATA SSD کی کارکردگی تقریباً 90,000 ہوتی ہے۔ Network attached block storage میں ہر request disk تک پہنچنے سے پہلے network سے گزرتی ہے، اس لیے یہ عموماً 12,000 کے قریب رہتی ہے۔ Spinning disk تقریباً 180 حاصل کرتی ہے، کیونکہ ہر random request کے لیے physical head کو حرکت دینی پڑتی ہے۔

یہ ہر storage class کے لیے عام شائع شدہ اعداد ہیں، کسی ایک host کی پیمائش نہیں۔ انہیں صرف یہ جانچنے کے لیے استعمال کریں کہ آپ کا اپنا نتیجہ اسی order of magnitude میں ہے یا نہیں۔ اگر NVMe کے طور پر فروخت کیا جانے والا plan 4k IOPS کے کم ہزاروں میں benchmark کرے تو پہلے تصدیق کریں کہ --direct=1 فعال تھا۔ اگر یہ فعال تھا، تو یا storage وہ نہیں جس کی product page میں وضاحت کی گئی ہے، یا آپ اسے بہت مصروف neighbour کے ساتھ share کر رہے ہیں۔

ایک run benchmark کیوں نہیں ہوتا

ایک نتیجہ shared machine پر ایک منٹ کی صرف snapshot ہوتا ہے۔ اسے ایک sample سمجھیں۔

• ہر test کم از کم پانچ بار چلائیں۔ یہ runs مختلف hours اور کم از کم دو مختلف days میں پھیلائیں۔ median اور spread محفوظ رکھیں۔ spread کے بغیر شائع کیا گیا نتیجہ marketing figure ہوتا ہے۔
• ہر run کے ساتھ steal time record کریں۔ جن runs میں st زیادہ ہو، انہیں خارج کریں، یا کم از کم یہ بات note کریں۔
• disk test کو دو durations پر چلائیں۔ بہت سے plans burst IOPS allowance دیتے ہیں جو وقت کے ساتھ refill ہوتی ہے، اس لیے 60 second کا fio run burst کی پیمائش کرتا ہے، جبکہ --runtime=600 floor کی پیمائش کرتا ہے۔ خراب دن میں آپ کو floor ہی ملتا ہے۔
• تصدیق کریں کہ کوئی اور چیز run نہیں ہو رہی۔ CPU test کے دوران unattended-upgrades کا apt transaction شروع کرنا آپ کے حقیقی points کم کر دیتا ہے، اور ہر run سے پہلے ps -e -o comm= | grep -E 'apt|dpkg' میں صرف ایک second لگتا ہے۔
• ایک وقت میں صرف ایک variable تبدیل کریں۔ مختلف tool versions، block sizes یا thread counts ایسے numbers پیدا کرتے ہیں جن کا تقابل نہیں کیا جا سکتا، چاہے وہ بظاہر کتنے ہی یکساں ہوں۔

جب آپ دو providers کا تقابل کریں تو انہیں اسی day کے اسی hour میں run کریں۔ بصورت دیگر آپ نے time of day کی پیمائش کی ہے۔

اپنے workload کو آخر میں benchmark کریں

Synthetic tools مشینوں کی درجہ بندی کرتے ہیں۔ صرف آپ کا اپنا workload بتاتا ہے کہ کوئی مشین کافی ہے یا نہیں۔ اسی کام کا وقت ناپیں جو آپ حقیقت میں کرتے ہیں۔

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

یہ چند سو megabytes کو compress کرتا ہے، اس لیے CPU اور disk دونوں کو استعمال کرتا ہے، اور ان میں سے کسی ایک کی کارکردگی بدلنے پر نتیجہ بھی بدل جاتا ہے۔ Removing leading / from member names warning معمول کی بات ہے۔ اس سے بہتر یہ ہے کہ اپنی build، اپنی سب سے سست query، یا اپنے page render کا وقت ناپیں۔ ایک host پر build مکمل ہونے میں 4 minutes اور دوسرے پر 7 minutes لگیں تو سوال کا جواب واضح ہو جاتا ہے، چاہے Geekbench نے کچھ بھی نتیجہ دیا ہو۔ یہی measurement یہ بھی بتاتی ہے کہ کب زیادہ powerful machine کے لیے ادائیگی کرنا فائدہ مند نہیں رہتا۔ یہ جاننا اس سے پہلے مفید ہے کہ آپ VPS کی ماہانہ اصل لاگت پڑھیں یا workload کو dedicated server پر منتقل کریں۔

FAQ

مجھے ہر بار benchmark چلانے پر مختلف نتیجہ کیوں ملتا ہے؟

ایک VPS physical CPU، storage اور network کو دوسرے tenants کے ساتھ share کرتا ہے، اس لیے نتیجہ اس بات پر منحصر ہوتا ہے کہ اس وقت دوسرے tenants کیا کر رہے ہیں۔ Test کے دوران vmstat 1 چلائیں اور st column دیکھیں: 5 سے زیادہ مسلسل steal time بتاتا ہے کہ host مصروف تھا، اور CPU score آپ کی machine سے باہر کی وجوہات کی بنا پر کم ہے۔ اس کا حل tuning نہیں بلکہ درست method ہے۔ ہر test کو مختلف اوقات میں کم از کم پانچ بار چلائیں، پھر median کے ساتھ نتائج کا spread بھی report کریں۔

fio لاکھوں IOPS کیوں report کرتا ہے؟

تقریباً ہمیشہ اس کی وجہ --direct=1 کا missing ہونا ہے۔ اس کے بغیر fio kernel page cache کے ذریعے read کرتا ہے، اس لیے پہلے pass کے بعد 2G کی test file RAM سے serve ہوتی ہے اور آپ نے memory bandwidth measure کی ہوتی ہے۔ --direct=1 شامل کریں اور test file کو path میں موجود ہر cache سے بڑا رکھیں۔ اگر --direct=1 پھر err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1 کے ساتھ fail ہو جائے تو df -hT . چلائیں: overlay کا Type O_DIRECT support نہیں کرتا، اس لیے test کو real storage پر چلائیں۔

کیا yabs.sh اکیلا کافی ہے؟

ابتدائی جائزے کے لیے ہاں۔ یہ چار block sizes پر fio، دونوں directions میں iperf3 اور Geekbench چلاتا ہے، اور ایک ایسی summary دکھاتا ہے جسے دوسرے لوگ پڑھ سکتے ہیں۔ جب آپ یہ جاننا چاہیں کہ کوئی number ایسا کیوں ہے تو یہ کافی نہیں رہتا، کیونکہ آپ ہر test کے لیے اس کے flags تبدیل نہیں کر سکتے۔ جب yabs کا result غلط معلوم ہو تو اسے براہ راست fio یا sysbench کے ذریعے دوبارہ reproduce کریں اور ایک وقت میں صرف ایک flag تبدیل کریں۔

کون سا واحد number بتاتا ہے کہ میری application کی performance کیسی محسوس ہوگی؟

زیادہ تر web اور database workloads کے لیے پہلے single core CPU speed اور پھر 4k random read latency اہم ہیں۔ Throughput کے figures متاثر کن دکھائی دیتے ہیں، لیکن عموماً فیصلہ کن نہیں ہوتے، کیونکہ عام request چھوٹی ہوتی ہے۔ اوسط کے بجائے fio کے clat percentiles block سے 99th percentile بیان کریں، کیونکہ ہر 100 requests میں ایک سست request ہی وہ ہوتی ہے جسے user محسوس کرتا ہے۔

کیا benchmark سے پہلے کچھ install کرنا ضروری ہے؟

fio، sysbench اور iperf3 سب Ubuntu اور Debian archives میں موجود ہیں: sudo apt install -y fio sysbench iperf3۔ yabs.sh کے لیے صرف curl درکار ہے، کیونکہ یہ missing components کے لیے static binaries download کرتا ہے۔ مکمل ہونے پر ہر test file delete کر دیں، کیونکہ 20G disk پر چھوڑی گئی 2G fio file چند ہفتوں بعد کسی کے disk full alert کا سبب بن سکتی ہے۔