VPS benchmark సరిగ్గా ఎలా చేయాలి

VPS ను benchmark చేయడం అంటే ఏమిటి

VPS ను benchmark చేయడానికి నాలుగు విషయాలను కొలుస్తారు: ఒకే CPU core ఎంత వేగంగా పనిచేస్తుందో, machine కు ఎంత memory bandwidth ఉందో, storage ప్రతి సెకనుకు ఎన్ని చిన్న random disk operations అందించగలదో, network link ఎంత throughput అందిస్తుందో. yabs.sh ను ఒక్కసారి run చేస్తే సుమారు పది నిమిషాల్లో ఈ నాలుగు కొలతలు లభిస్తాయి. ఫలితాన్ని అర్థం చేసుకోవడం కష్టమైన భాగం. VPS భౌతిక hardware ను ఇతర tenants తో పంచుకుంటుంది. అందువల్ల అదే machine 03:00 సమయంలో ఒక సంఖ్యను, 20:00 సమయంలో దానికి చాలా భిన్నమైన సంఖ్యను చూపవచ్చు.

ఇక్కడి విధానం ముందుగా త్వరిత అంచనా కోసం yabs.sh ను run చేసి, తరువాత దాని కింద పనిచేసే tools ను చేతితో run చేయడం. మీరే వాటిని run చేసినప్పుడు ఒక flag ను మార్చి, సంఖ్య ఎలా మారుతుందో గమనించి, ఆ సంఖ్య వాస్తవంగా ఏమి కొలుస్తోందో తెలుసుకోవచ్చు. Machine setup పూర్తయిన తరువాత ఇది చేయండి, అంతకు ముందు కాదు. కొత్త VPS పై మొదటి పది నిమిషాలు లోని దశలు ముందుగా పూర్తి కావాలి. ఎందుకంటే మొదటి updates సమూహాన్ని ఇంకా apply చేస్తున్న machine, hardware తో సంబంధం లేని కారణాల వల్ల సరిగ్గా benchmark ఫలితాలు ఇవ్వదు.

కొలిచే ముందు యంత్రాన్ని పరిశీలించండి

ప్రతి చెడు benchmarkలో సగం కారణం, దాన్ని రాసిన వ్యక్తికి యంత్రం గురించి సరైన అవగాహన లేకపోవడమే.

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

Hypervisor vendor: KVM అంటే పూర్తి virtualisation అని అర్థం. అందువల్ల మీరు మీ స్వంత kernel ను నడుపుతారు. systemd-detect-virt లో lxc లేదా openvz కనిపిస్తే, అది container virtualisation అని అర్థం. ఇందులో host kernel ను భాగస్వామ్యం చేస్తారు. మీ CPU మరియు memory పరిమితులు virtual hardware కాకుండా cgroup (control group) settings గా ఉంటాయి. cgroup v2 ఉన్న system లో CPU పరిమితిని నేరుగా చదవవచ్చు.

cat /sys/fs/cgroup/cpu.max

max 100000 అంటే quota లేదని అర్థం. 200000 100000 అంటే ప్రతి 100000 microsecond కాలవ్యవధిలో 200000 microseconds CPU ఉపయోగించవచ్చని అర్థం. ఇది రెండు cores కు సమానమైన quota. రెండు cores quota ఉన్నప్పటికీ 4 vCPUగా ప్రకటించిన plan, నాలుగు cores ఉన్న plan లాగా ఎప్పటికీ score సాధించదు. దీనికి కారణం ఏమిటో ఏ benchmark tool కూడా ప్రత్యేకంగా చూపించదు.

df -hT / వేరే కారణంతో ముఖ్యమైనది: Type column. అందులో overlay కనిపిస్తే, మీరు container లో ఉన్నారు. అప్పుడు దిగువ disk test కు మార్పు అవసరం. దీన్ని ఇప్పుడే గమనించండి.

Steal time ను మొత్తం సమయం పర్యవేక్షించండి

Steal time అనేది మీ virtual CPU అమలు కావడానికి సిద్ధంగా ఉన్నప్పటికీ, hypervisor physical core ను మరొకరికి కేటాయించిన సమయం యొక్క వాటా. ఫలితం hardware వల్ల కాకుండా మీ పొరుగు virtual machine ల వల్ల ప్రభావితమవుతోందో గుర్తించడానికి ఇది అత్యంత ఉపయోగకరమైన ఒక్క సూచిక.

vmstat 1 10

కుడివైపు ఉన్న st column ను చూడండి. నిరంతరం 0 లేదా 1 కనిపించడం సాధారణం. 5 కంటే ఎక్కువ విలువలు ఎక్కువసేపు కనిపిస్తే, ఆ సమయంలో host పై వనరులకు అధిక కేటాయింపు ఉందని అర్థం. అందువల్ల ఆ వ్యవధిలో మీరు నమోదు చేసే ప్రతి CPU సంఖ్య మీ machine లోని లోపం వల్ల కాకుండానే తక్కువగా ఉంటుంది. CPU line లోని top, %st చూపించే అదే సంఖ్యను చూపిస్తుంది. Benchmark నడుపుతున్నప్పుడు vmstat 1 ను మరో SSH session లో అమలులో ఉంచండి. ప్రతి ఫలితం పక్కన steal figure ను నమోదు చేయండి.

yabs.sh తో ప్రారంభించండి

yabs.sh (Yet Another Bench Script) అనేది static fio, iperf3 మరియు Geekbench binaries ను download చేసి, వాటిని run చేసి, ఒకే summary ను print చేసే shell script. VPS benchmark చర్చల్లో ఇది సాధారణంగా ఉపయోగించే భాష వంటిది. అందువల్ల, ఇతరులతో benchmark ఫలితాలను పోల్చడానికి yabs output వేగవంతమైన మార్గం.

ఈ project అందించే one-line రూపం ఇది.

curl -sL yabs.sh | bash

ఇది ప్రస్తుతం URL అందించే కంటెంట్‌ను నేరుగా shell కు pipe చేస్తుంది. ముందుగా దాన్ని download చేసి, చదివి, తరువాత run చేయండి.

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 ను run చేసినప్పుడు వాటిని filename తరువాత నేరుగా ఉంచాలి. ఉపయోగకరమైన flags ఇవి: -f disk test ను skip చేస్తుంది, -i network test ను skip చేస్తుంది, -g Geekbench ను skip చేస్తుంది, -r iperf3 locations ను రెండుకు పరిమితం చేస్తుంది, -j ఫలితాలను JSON గా print చేస్తుంది, -w results.json ఆ JSON ను ఒక file లో రాస్తుంది.

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

మొదటి run కు ముందు రెండు విషయాలు తెలుసుకోండి. Geekbench మీ ఫలితాన్ని upload చేసి, public browser.geekbench.com URL ను print చేస్తుంది. అందువల్ల ఆ link ఉన్న ఎవరైనా మీ CPU model మరియు scores ను చూడగలరు. -g ఆ test ను పూర్తిగా skip చేస్తుంది. రెండవది, iperf3 stage అనేక regions లోని servers కు నిజమైన network traffic ను పంపుతుంది. ఇది మీ monthly bandwidth allowance నుంచి తగ్గుతుంది. 1 Gbit/s link పై పూర్తి network stage tens of gigabytes traffic ను పంపవచ్చు. కాబట్టి allowance తక్కువగా ఉంటే -r ను, usage ఆధారంగా ఛార్జీలు విధించే link అయితే -i ను ఉపయోగించండి.

yabs output లోని ప్రతి భాగం అర్థం

డిస్క్ విభాగం 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 చిన్న పరిమాణంలో, చెల్లాచెదురుగా జరుగుతుంది. Backupలు మరియు video కోసం 1m row ఉపయోగకరం. వీటిలో వరుసగా ఉన్న పెద్ద byte పరిమాణాలను తరలిస్తారు.

Network విభాగం అనేక regions లోని public servers కు iperf3 ను రెండు దిశల్లో parallel streams తో నడుపుతుంది. ఇక్కడ తక్కువ సంఖ్య కనిపిస్తే దాన్ని తుది నిర్ణయంగా కాకుండా పరిశీలించాల్సిన సూచనగా చూడాలి. Public iperf3 servers ఇతర వినియోగదారులతో పంచుకోబడతాయి మరియు తరచుగా saturation కు చేరుతాయి. అందువల్ల తక్కువ ఫలితానికి కారణం దూరంలోని server వైపు కూడా ఉండవచ్చు.

Geekbench విభాగం single core score మరియు multi core score ను ఇస్తుంది. Single core score ద్వారా ఒక request, ఒక compile లేదా ఒక query ఎంత వేగంగా పూర్తవుతుందో అంచనా వేయవచ్చు. Multi core score ప్రధానంగా మీకు వాస్తవంగా ఎన్ని cores లభించాయో తెలియజేస్తుంది.

డిస్క్: fio ను స్వయంగా అమలు చేయండి

yabs లోని disk విభాగం వెనుక పనిచేసే సాధనం fio (flexible IO tester). దీన్ని నేరుగా అమలు చేసినప్పుడు 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 ఎంతసేపు వేచి ఉందో ఇది చూపిస్తుంది. Average latency వినియోగదారుడు గమనించే stalls ను దాచిపెడుతుంది.

• --direct=1 తో file ను O_DIRECT ఉపయోగించి తెరుస్తుంది. అందువల్ల reads kernel page cache ను దాటిపోతాయి. ఇది లేకపోతే, 8G RAM ఉన్న machine పై 2G file ను రెండోసారి చదివినప్పుడు data memory నుంచి అందుతుంది. అప్పుడు fio IOPS ను millions లో చూపిస్తుంది. ఆ సంఖ్య నిజమే, కానీ అది memory పనితీరును సూచిస్తుంది.
• --ioengine=libaio asynchronous requests ను submit చేస్తుంది. అందువల్ల --iodepth=32 ఒకేసారి 32 requests ను in flight లో ఉంచగలదు. psync వంటి synchronous engine తో iodepth 1 కంటే ఎక్కువగా ఉన్నా ఎలాంటి ప్రభావం ఉండదు. అప్పుడు ఒక్కోసారి ఒక request ను మాత్రమే కొలుస్తారు.
• --time_based --runtime=60 నిర్ణీత amount of work కు బదులుగా fixed 60 seconds పాటు test ను నడుపుతుంది. అందువల్ల fast disk మరియు slow disk రెండింటికీ ఒకే wall clock సమయం ఉంటుంది, కాబట్టి పోలిక న్యాయంగా ఉంటుంది.
• --size=2G test file size ను నిర్ణయిస్తుంది. ఇది మార్గంలోని ఏ cache కంటే పెద్దదిగా ఉండాలి. ముందుగా తగినంత 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 ఉపయోగించండి. మీరు ఉపయోగిస్తున్న storage class ఈ ఫలితాలను ఏ flag కంటే ఎక్కువగా మార్చగలదు. ఆ తేడాను VPS లో NVMe మరియు SATA SSD storage మధ్య తేడా లో వివరించారు.

fio Unknown error -1తో ఆగిపోయినప్పుడు

ప్రతి filesystemలో Direct IO అందుబాటులో ఉండదు. overlay, containerకు Docker డిఫాల్ట్‌గా అందించే filesystem, అలాగే కొన్ని network filesystems O_DIRECT కు మద్దతు ఇవ్వవు. అందువల్ల libaio kernel పూర్తి చేయలేని requestను submit చేస్తుంది, 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 ను bind mounted volume వంటి నిజమైన storageలోని pathకు point చేయండి లేదా containerలో కాకుండా hostపై fioను అమలు చేయండి. నిజమైన 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 సంఖ్య మీ RAM పనితీరును వివరిస్తుంది. fio install అయిందని, flags సరిగ్గా 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 ను కొలుస్తుంది. సాధారణ sanity check గా ఇది ఉపయోగకరంగా ఉంటుంది. 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 అభ్యర్థన పూర్తయ్యే వేగాన్ని లేదా ఒక compile పని పూర్తయ్యే వేగాన్ని నిర్ణయించేది ఇదే. ఒకే ధరలోని 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 ను copy చేస్తే WARNING: the --test option is deprecated వస్తుంది. sysbench 0.4 మరియు sysbench 1.0 scores అసలు పోల్చదగినవి కావు. అందువల్ల version పేర్కొనని published number తో మీ ఫలితాన్ని ఎప్పుడూ పోల్చవద్దు.

మెమరీ: 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 గానే ఉంచండి. మీరు పోల్చే ప్రతి host లోనూ దాన్ని ఒకే విధంగా ఉంచండి. 1K వద్ద సంఖ్య గణనీయంగా తగ్గుతుంది. కారణం, ప్రతి operation కు సంబంధించిన overhead 1000 రెట్లు ఎక్కువసార్లు చెల్లించాల్సి రావడం. అందువల్ల మీరు memory bandwidth కంటే loop cost ను కొలుస్తారు. ప్రచురితమైన memory scores లో తరచుగా భిన్నంగా ఉండే flag ఇదే.

నెట్‌వర్క్: iperf3

Throughput ను సరిగ్గా పరీక్షించాలంటే మీ నియంత్రణలో ఉన్న రెండవ machine కు వ్యతిరేకంగా పరీక్షించాలి. అప్పుడు రెండు చివరల్లో ఏమి జరుగుతుందో మీకు తెలుసు.

రిమోట్ చివరలో:

iperf3 -s

ఇది TCP 5201 పై listen చేస్తుంది. మీరు పరీక్షించే address కు మాత్రమే ఆ port ను open చేయండి. పరీక్ష పూర్తయ్యాక దాన్ని close చేయండి. VPS పై Basic ufw firewall నియమాలు 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 పరీక్షిస్తున్న machine నుంచి జరిగే upload ను కొలుస్తుంది. -R దిశను reverse చేస్తుంది. ఇది download ను కొలుస్తుంది. -P 8 ఎనిమిది parallel streams ను open చేస్తుంది.

Single stream మరియు parallel version రెండింటినీ run చేయండి. అవి వేర్వేరు ప్రశ్నలకు సమాధానం ఇస్తాయి. ఒక TCP connection window అనుమతించేంత unacknowledged data ను మాత్రమే ఉంచగలదు. అందువల్ల దాని గరిష్ఠ పరిమితి సుమారుగా window size ను round trip time తో భాగించినంత ఉంటుంది. Latency 80 ms, window 4 MB గా ఉంటే, కింద ఉన్న link ఎంత వేగంగా ఉన్నా ఆ పరిమితి సుమారుగా 400 Mbit/s ఉంటుంది. Single stream ఫలితం ఒక download కు లభించే వేగాన్ని చూపుతుంది. Parallel ఫలితం link యొక్క capacity ను చూపుతుంది.

ఈ పరీక్షలు చేస్తున్నప్పుడు మీ bandwidth allowance ను గమనించండి. 1 Gbit/s వద్ద 30 seconds లో సుమారుగా 3.75 GB data బదిలీ అవుతుంది. ప్రతి దిశలో మీరు ఈ పరీక్షను అనేకసార్లు run చేస్తారు.

సూచన గణాంకాలు మరియు మీ ఫలితాలను ఎలా చదవాలి

[
  {
    "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 ప్రతి random request కోసం physical head ను కదిలించాలి కాబట్టి సుమారు 180 IOPS సాధిస్తుంది.

ఇవి ప్రతి storage తరగతికి సంబంధించిన సాధారణంగా ప్రచురితమైన గణాంకాలు. ఇవి ఒకే host పై చేసిన కొలతలు కావు. మీ స్వంత ఫలితం సరైన order of magnitude లో ఉందో తనిఖీ చేయడానికి మాత్రమే వీటిని ఉపయోగించండి. NVMeగా విక్రయించిన plan 4k IOPSలో low thousands వద్ద benchmark అయితే, ముందుగా --direct=1 ఆన్‌లో ఉందో నిర్ధారించండి. అది ఆన్‌లో ఉంటే, storage product page వివరించిన విధంగా లేకపోవచ్చు, లేదా మీరు దాన్ని అధిక పనిభారం ఉన్న మరో వినియోగదారుతో పంచుకుంటుండవచ్చు.

ఒకసారి నడిపిన పరీక్ష benchmark కాదు

ఒకే ఫలితం shared machine పై ఒక నిమిషానికి సంబంధించిన snapshot మాత్రమే. దాన్ని ఒక sample గా పరిగణించండి.

• ప్రతి పరీక్షను కనీసం ఐదుసార్లు నడపండి. వాటిని వేర్వేరు గంటల్లో, కనీసం రెండు వేర్వేరు రోజుల్లో నిర్వహించండి. Median మరియు spread ను నమోదు చేయండి. Spread లేకుండా ప్రచురించిన ఫలితం marketing figure మాత్రమే.
• ప్రతి run పక్కన steal time ను నమోదు చేయండి. st ఎక్కువగా ఉన్న runs ను తొలగించండి. కనీసం అది ఎక్కువగా ఉన్న విషయాన్ని నమోదు చేయండి.
• Disk test ను రెండు వ్యవధుల్లో నడపండి. చాలా plans లో కాలక్రమేణా తిరిగి నిండే burst IOPS allowance ఉంటుంది. అందువల్ల 60 second fio run burst ను కొలుస్తుంది, అయితే --runtime=600 floor ను కొలుస్తుంది. చెడు రోజున మీకు లభించేది ఆ floor.
• మరేదీ నడుస్తూ లేదని నిర్ధారించండి. 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 ను పోల్చేటప్పుడు, అదే రోజు అదే గంటలో వాటిపై tests నడపండి. లేకపోతే మీరు కొలిచింది రోజు సమయంలో వచ్చిన తేడానే.

మీ స్వంత 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, మరో host పై 7 minutes పడితే, Geekbench ఏం చెప్పినా నిర్ణయం స్పష్టమవుతుంది. మరింత శక్తివంతమైన machine కోసం చెల్లించడం ఎప్పుడు ప్రయోజనకరం కాదో కూడా ఈ కొలత చెబుతుంది. VPS కు వాస్తవంగా నెలకు ఎంత ఖర్చవుతుందో చదవడానికి లేదా workload ను dedicated server పైకి మార్చడానికి ముందే ఇది తెలుసుకోవడం ఉపయోగకరం.

FAQ

ప్రతి సారి benchmark నడిపినప్పుడు వేర్వేరు ఫలితాలు ఎందుకు వస్తాయి?

ఒక VPS భౌతిక CPU, storage మరియు network వనరులను ఇతర tenants తో పంచుకుంటుంది. అందువల్ల ఆ సమయంలో వారు ఏమి చేస్తున్నారనే దానిపై మీ ఫలితం ఆధారపడి ఉంటుంది. పరీక్ష సమయంలో vmstat 1 ను నడిపి, st column ను పరిశీలించండి: 5 కంటే ఎక్కువ sustained steal time ఉంటే host busy గా ఉందని అర్థం. మీ machine వెలుపల ఉన్న కారణాల వల్ల మీ CPU score తక్కువగా ఉంటుంది. దీనికి పరిష్కారం tuning కాదు, సరైన పద్ధతి. ప్రతి test ను వేర్వేరు సమయాల్లో ఐదు లేదా అంతకంటే ఎక్కువ సార్లు నడిపి, spread తో పాటు median ను నివేదించండి.

fio millions of 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 . ను నడపండి: Type of overlay కు O_DIRECT support ఉండదు. అందువల్ల test ను నిజమైన storage పై నడపండి.

yabs.sh మాత్రమే సరిపోతుందా?

మొదటి పరిశీలనకు సరిపోతుంది. ఇది నాలుగు block sizes వద్ద fio ను, రెండు దిశల్లో iperf3 ను మరియు Geekbench ను నడిపి, ఇతరులు చదవగలిగే ఒక summary ను ముద్రిస్తుంది. ఒక సంఖ్య ఎందుకు అలా వచ్చిందో తెలుసుకోవాలనుకున్నప్పుడు ఇది సరిపోదు, ఎందుకంటే ప్రతి test కు flags ను వేరుగా మార్చలేరు. yabs ఫలితం తప్పుగా కనిపించినప్పుడు, దాన్ని fio లేదా sysbench తో నేరుగా పునరావృతం చేసి, ప్రతి సారి ఒక flag మాత్రమే మార్చండి.

నా application పనితీరు ఎలా అనిపిస్తుందో అంచనా వేయడానికి ఏ ఒక్క సంఖ్య ఉపయోగపడుతుంది?

చాలా web మరియు database workloads కోసం, ముందుగా single core CPU speed, తరువాత 4k random read latency ముఖ్యమైనవి. Throughput figures ఆకర్షణీయంగా కనిపించినా, సాధారణ request చిన్నదిగా ఉండటం వల్ల అవి చాలా అరుదుగా నిర్ణయాత్మకంగా ఉంటాయి. Average కు బదులుగా fio clat percentiles block నుంచి 99th percentile ను పేర్కొనండి. ప్రతి 100 requests లో slow గా ఉన్న ఒక్క 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 ను delete చేయండి. 20G disk పై మిగిలిపోయిన 2G fio file, కొన్ని వారాల తరువాత ఎవరికైనా disk full alert కు కారణమవుతుంది.