VPS کا درست benchmark کیسے لیں؟ yabs.sh، fio اور iperf3

VPS کا بینچ مارک لینے کا مطلب

VPS کا بینچ مارک لینے کے لیے آپ چار چیزیں ناپتے ہیں: ایک CPU core کتنی رفتار سے چلتا ہے، machine میں memory bandwidth کتنی ہے، storage ہر سیکنڈ کتنے چھوٹے random disk operations انجام دیتا ہے، اور network link کتنی throughput فراہم کرتا ہے۔ yabs.sh کی ایک run تقریباً دس منٹ میں یہ چاروں نتائج دیتی ہے۔ نتیجہ سمجھنا زیادہ مشکل ہے، کیونکہ VPS (virtual private server) physical hardware کو دوسرے tenants کے ساتھ شیئر کرتا ہے۔ اس لیے ایک ہی machine 03:00 پر ایک number اور 20:00 پر اس سے بہت مختلف number دکھا سکتی ہے۔

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

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

ہر ناقص بینچ مارک کا نصف سبب ایسی مشین ہوتی ہے جسے مصنف نے سمجھا نہیں ہوتا۔

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

Hypervisor vendor: KVM کا مطلب مکمل ورچوئلائزیشن ہے، اس لیے آپ اپنا kernel چلاتے ہیں۔ systemd-detect-virt میں lxc یا openvz کی پرنٹنگ اس کے بجائے container ورچوئلائزیشن کی نشاندہی کرتی ہے: آپ host kernel کا اشتراک کرتے ہیں، اور آپ کے CPU اور memory limits ورچوئل hardware کے بجائے cgroup (control group) کی ترتیبات ہوتی ہیں۔ cgroup v2 والے نظام میں آپ CPU limit براہِ راست پڑھ سکتے ہیں۔

cat /sys/fs/cgroup/cpu.max

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

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

ہر وقت steal time کی نگرانی کریں

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

vmstat 1 10

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

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

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

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

curl -sL yabs.sh | bash

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

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 -- کے بعد لگائیں، یا local copy چلاتے وقت 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 منتقل کرتا ہے، اور یہ آپ کے monthly bandwidth allowance میں شمار ہوتا ہے۔ 1 Gbit/s link پر مکمل network stage دسیوں gigabytes منتقل کر سکتا ہے۔ اس لیے کم allowance پر -r اور metered link پر -i استعمال کریں۔

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

ڈسک والا حصہ 4k، 64k، 512k اور 1m کے چار block sizes پر 50/50 read اور write تناسب کے ساتھ fio چلاتا ہے۔ یہ ہر 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 کے خلاف، دونوں directions میں، parallel streams استعمال کرتے ہوئے iperf3 چلاتا ہے۔ یہاں کم number کو حتمی جواب کے بجائے ایک سوال سمجھیں، کیونکہ public iperf3 servers مشترکہ استعمال میں ہوتے ہیں اور اکثر saturated ہوتے ہیں۔ اس لیے خراب result دور موجود سرے کی وجہ سے بھی ہو سکتا ہے۔

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

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

fio (flexible IO tester) وہ ٹول ہے جو yabs کے disk حصے کے پسِ منظر میں استعمال ہوتا ہے۔ اسے براہِ راست چلانے سے 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 requests میں سب سے سست request نے کتنی دیر انتظار کیا۔ اوسط latency ان تاخیر کے وقفوں کو چھپا دیتی ہے جنہیں user محسوس کرتا ہے۔

• --direct=1 file کو O_DIRECT کے ساتھ کھولتا ہے، اس لیے reads kernel page cache کو bypass کرتی ہیں۔ اس کے بغیر، 8G RAM والی machine پر 2G file کا دوسرا pass memory سے پورا ہوتا ہے اور fio لاکھوں IOPS رپورٹ کرتا ہے۔ یہ number حقیقی ہے، لیکن یہ memory کا number ہے۔
• --ioengine=libaio asynchronous requests submit کرتا ہے، جس سے --iodepth=32 ان میں سے 32 کو in flight رکھ سکتا ہے۔ psync جیسے synchronous engine کے ساتھ 1 سے زیادہ iodepth کا کوئی اثر نہیں ہوتا، اس لیے آپ ایک وقت میں صرف ایک request measure کرتے ہیں۔
• --time_based --runtime=60 کام کی مقررہ مقدار کے بجائے مقررہ 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 پر کام کر رہے ہیں، اس سے نتائج کسی بھی flag کے مقابلے میں زیادہ تبدیل ہوتے ہیں۔ اس تقسیم کی وضاحت VPS پر NVMe اور SATA SSD storage کے درمیان فرق میں کی گئی ہے۔

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

Direct IO ہر filesystem پر دستیاب نہیں ہوتا۔ overlay، جو filesystem Docker بطور ڈیفالٹ container کو دیتا ہے، اور کئی 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 کی طرف متعین کریں، مثلاً 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 کے طور پر کبھی پیش نہ کریں۔

dd ڈسک بینچ مارک کیوں نہیں ہے

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 memory میں writes قبول کرتا ہے۔ اسی لیے فورم پوسٹس میں دیے گئے 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 کے حصے ہیں۔

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

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

نیٹ ورک: iperf3

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

دوسرے سرے پر:

iperf3 -s

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

پہلی کمانڈ زیرِ جانچ مشین سے upload کی پیمائش کرتی ہے۔ -R سمت کو الٹ دیتا ہے، جس سے download کی پیمائش ہوتی ہے۔ -P 8 آٹھ متوازی streams کھولتا ہے۔

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

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

حوالہ جاتی اعداد و شمار، اور اپنے نتائج کو پڑھنے کا طریقہ

[
  {
    "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 کے چند ہزار کی کم کارکردگی دکھائے، تو پہلے تصدیق کریں کہ --direct=1 فعال تھا۔ اگر یہ فعال تھا، تو یا تو storage وہ نہیں جس کی product page میں وضاحت کی گئی ہے، یا آپ اسے ایک بہت مصروف neighbour کے ساتھ share کر رہے ہیں۔

ایک بار چلانا بینچ مارک نہیں ہوتا

ایک نتیجہ مشترکہ مشین پر ایک منٹ کی صورتِ حال دکھاتا ہے۔ اسے ایک نمونے کے طور پر دیکھیں۔

• ہر ٹیسٹ کم از کم پانچ بار چلائیں۔ یہ ٹیسٹ مختلف اوقات اور کم از کم دو مختلف دنوں میں چلائے جائیں۔ میڈین اور پھیلاؤ دونوں محفوظ کریں۔ پھیلاؤ کے بغیر شائع کیا گیا نتیجہ صرف تشہیری اعداد و شمار ہوتا ہے۔
• ہر رن کے ساتھ steal time ریکارڈ کریں۔ جن رنز میں st زیادہ ہو، انہیں خارج کریں، یا کم از کم یہ بات درج کریں۔
• disk ٹیسٹ دو دورانیوں پر چلائیں۔ بہت سے plans وقت کے ساتھ دوبارہ بھرنے والی burst IOPS allowance دیتے ہیں، اس لیے 60 سیکنڈ کا fio run burst کو ناپتا ہے، جبکہ --runtime=600 کم از کم کارکردگی کو ناپتا ہے۔ خراب دن میں آپ کو یہی کم از کم کارکردگی ملتی ہے۔
• یقینی بنائیں کہ کوئی اور عمل نہیں چل رہا۔ unattended-upgrades کا CPU ٹیسٹ کے دوران apt transaction شروع کرنا آپ کے حقیقی اسکور کو کم کرتا ہے، اور ہر رن سے پہلے ps -e -o comm= | grep -E 'apt|dpkg' میں ایک سیکنڈ لگتا ہے۔
• ایک وقت میں صرف ایک variable تبدیل کریں۔ مختلف tool versions، block sizes یا thread counts ایسے اعداد پیدا کرتے ہیں جن کا موازنہ نہیں کیا جا سکتا، چاہے وہ بظاہر کتنے ہی ملتے جلتے ہوں۔

جب آپ دو providers کا موازنہ کریں تو دونوں کو ایک ہی دن کے ایک ہی وقت میں چلائیں۔ ورنہ آپ نے provider کے بجائے دن کا وقت ناپا ہے۔

آخر میں اپنے کام کی کارکردگی جانچیں

مصنوعی ٹولز مشینوں کی درجہ بندی کرتے ہیں۔ صرف آپ کا اپنا کام بتاتا ہے کہ مشین کافی ہے یا نہیں۔ اسی کام کا وقت ناپیں جو آپ واقعی کرتے ہیں۔

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

یہ چند سو میگا بائٹس کو کمپریس کرتا ہے، اس لیے یہ CPU اور ڈسک دونوں کو استعمال کرتا ہے۔ CPU یا ڈسک میں کسی ایک کی تبدیلی سے نتیجہ بھی بدل جاتا ہے۔ Removing leading / from member names انتباہ معمول کے مطابق ہے۔ اس سے بہتر یہ ہے کہ اپنی build، اپنی سب سے سست query، یا اپنے page render کا وقت ناپیں۔ اگر ایک host پر build مکمل ہونے میں 4 منٹ اور دوسرے پر 7 منٹ لگتے ہیں، تو اس سے سوال کا جواب مل جاتا ہے، چاہے Geekbench نے کچھ بھی نتیجہ دیا ہو۔ یہی پیمائش آپ کو بتاتی ہے کہ اضافی مشین کے لیے ادائیگی کرنا کب فائدہ مند نہیں رہتا۔ یہ جاننا اس سے پہلے مفید ہے کہ آپ VPS کی ماہانہ اصل لاگت پڑھیں یا کام کو dedicated server پر منتقل کریں۔

FAQ

ہر بار ٹیسٹ چلانے پر بینچ مارک کا نتیجہ مختلف کیوں آتا ہے؟

ایک VPS فزیکل CPU، storage اور network کو دوسرے tenants کے ساتھ شیئر کرتا ہے، اس لیے آپ کا نتیجہ اس بات پر منحصر ہوتا ہے کہ وہ اس وقت کیا کر رہے ہیں۔ ٹیسٹ کے دوران vmstat 1 چلائیں اور st کالم پڑھیں: 5 سے زیادہ مسلسل steal time ظاہر کرتا ہے کہ host مصروف تھا، اور آپ کا CPU score ان وجوہات کی بنا پر کم ہے جو آپ کی machine سے باہر ہیں۔ اس کا حل tuning نہیں بلکہ درست طریقہ کار ہے۔ ہر ٹیسٹ کو مختلف اوقات میں پانچ یا اس سے زیادہ مرتبہ چلائیں، پھر spread کے ساتھ median رپورٹ کریں۔

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

تقریباً ہمیشہ اس کی وجہ یہ ہوتی ہے کہ --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 . چلائیں: overlay کا Type، O_DIRECT کو support نہیں کرتا، اس لیے ٹیسٹ کو حقیقی storage پر چلائیں۔

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

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

کون سا واحد number یہ پیش گوئی کرتا ہے کہ میری application کی کارکردگی کیسی محسوس ہوگی؟

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

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

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