Jinsi ya kupima utendaji wa VPS kwa usahihi

Maana ya kufanya benchmark ya VPS

Kufanya benchmark ya VPS kunahusisha kupima mambo manne: kasi ya core moja ya CPU, kiasi cha bandwidth ya kumbukumbu (memory) iliyo kwenye mashine, idadi ya operesheni ndogo za disk kwa sekunde, na kiasi cha data kinachopita kwenye mtandao (throughput). Mzunguko mmoja wa yabs.sh hukupa matokeo ya CPU, disk, na mtandao ndani ya dakika kumi; tumia jaribio la kumbukumbu lililo hapa chini kwa ajili ya bandwidth ya memory. Kusoma matokeo ndilo jambo gumu zaidi, kwa sababu VPS (virtual private server) inashiriki vifaa vya kimwili (hardware) na watumiaji wengine, hivyo mashine hiyo hiyo inaweza kutoa namba moja saa 03:00 na namba tofauti kabisa saa 20:00.

Mpango hapa ni kuendesha yabs.sh ili kupata picha ya haraka, kisha kuendesha zana zilizopo chini yake kwa mikono. Kuziendesha mwenyewe ndiko kunakokuwezesha kubadili flag moja, kuona namba ikibadilika, na kujifunza kile ambacho namba hiyo ilikuwa inapima kweli. Fanya hivi baada ya mashine kusanidiwa, si kabla. Hatua zilizo katika dakika kumi za kwanza kwenye VPS mpya lazima zifanyike kwanza, kwa sababu seva inayotekeleza mzunguko wake wa kwanza wa updates hutoa matokeo mabaya ya benchmark kwa sababu zisizohusiana na hardware.

Ichunguze mashine kabla ya kuipima

Nusu ya kila benchmark mbaya husababishwa na mashine ambayo mwandishi hakuielewa.

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

Hypervisor vendor: KVM inamaanisha virtualisation kamili, kwa hivyo unaendesha kernel yako mwenyewe. systemd-detect-virt kuchapisha lxc au openvz inamaanisha container virtualisation badala yake: unashiriki kernel ya host, na mipaka yako ya CPU na kumbukumbu ni mipangilio ya cgroup (control group) badala ya maunzi ya mtandaoni. Kwenye mfumo wa cgroup v2 unaweza kusoma kikomo cha CPU kutoka kwenye cgroup ya container yako; njia ifuatayo inatumika wakati cgroup hiyo imewekwa kwenye /sys/fs/cgroup.

cat /sys/fs/cgroup/cpu.max

max 100000 inamaanisha cgroup hii haina quota yake yenyewe; cgroup za juu bado zinaweza kuweka moja. 200000 100000 inamaanisha unaweza kutumia microsecond 200000 za CPU katika kila kipindi cha microsecond 100000, ambayo ni sawa na quota ya cores mbili. Mpango unaotangazwa kama 4 vCPU wenye quota ya cores mbili hautawahi kutoa matokeo kama cores nne. Zana za benchmark zinaweza kutambua kizuizi hicho: VoxelBench huripoti quota za CPU na kuweka alama ya CPU iliyoshirikiwa au iliyopunguzwa kasi wakati host inaonyesha CPU nyingi zaidi kuliko ambazo seva inaweza kutumia.

df -hT / ni muhimu kwa sababu tofauti: safu ya Type. Ikiwa inasomeka overlay uko ndani ya container, na matokeo yako ya diski yataelezea hifadhi yoyote iliyo chini ya overlay hiyo. Iandike sasa.

Fuatilia steal time wakati wote

Steal time ni sehemu ya muda ambayo CPU yako ya mtandaoni ilitumia kusubiri bila hiari wakati hypervisor haikuiweka kwenye ratiba. Hii ni ishara muhimu ya muda wa CPU ambao haupatikani, lakini haitofautishi kati ya majirani walio na shughuli nyingi na mtoa huduma anayetekeleza quota yako ya CPU.

vmstat 1 10

Soma safu ya st iliyo upande wa kulia. Steal time inayoendelea inamaanisha muda wa CPU haukuwa unapatikana kwa guest, lakini thamani iliyo juu ya 5% haithibitishi kuwa host imezidiwa (oversubscribed). Watoa huduma wanaweza kuonyesha utekelezaji wa quota ya CPU kama steal time kwa makusudi. top inaonyesha takwimu sawa na %st kwenye mstari wa CPU. Endesha vmstat 1 katika kipindi cha pili cha SSH wakati unafanya benchmark, na uandike takwimu ya steal kando ya kila matokeo.

Anza na yabs.sh

yabs.sh (Yet Another Bench Script) ni hati ya shell inayoendesha fio, iperf3 na Geekbench na kutoa muhtasari mmoja. Inatumia fio na iperf3 ikiwa tayari zimesakinishwa, na kupakua binary za static pale ambapo hazipo. Hii ndiyo lugha ya kawaida katika mijadala ya benchmark ya VPS, kwa hivyo matokeo ya yabs ndiyo njia ya haraka zaidi ya kulinganisha taarifa na mtu mwingine.

Njia ya mstari mmoja ya mradi huu ni hii.

curl -sL yabs.sh | bash

Hiyo hupitisha chochote kinachotolewa na URL hiyo moja kwa moja kwenye shell. Ipakue, isome, kisha uiendeshe.

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

Flags huwekwa baada ya -s -- unapopitisha (pipe), au moja kwa moja baada ya jina la faili unapoendesha nakala ya ndani. Zile muhimu ni: -f inaruka jaribio la diski, -i inaruka jaribio la mtandao, -g inaruka Geekbench, -r inapunguza maeneo ya iperf3 hadi matatu, -j inachapisha matokeo kama JSON, na -w results.json inaandika JSON hiyo kwenye faili.

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

Mambo mawili ya kujua kabla ya uendeshaji wa kwanza. Geekbench hupakia matokeo yako na kuchapisha URL ya public browser.geekbench.com, kwa hivyo mtu yeyote aliye na kiungo hicho anaweza kusoma mfano wa CPU yako na alama zako. -g inaruka jaribio hilo kabisa. Pili, hatua ya iperf3 husafirisha trafiki halisi kwenda kwenye seva katika maeneo kadhaa, na hiyo huhesabiwa dhidi ya mgao wako wa bandwidth wa kila mwezi. Kwenye link ya 1 Gbit/s, hatua kamili ya mtandao inaweza kusafirisha makumi ya gigabytes, kwa hivyo tumia -r kwenye mgao mdogo na -i kwenye link yenye kipimo cha matumizi.

Maana ya kila sehemu ya matokeo ya yabs

Sehemu ya disk huendesha fio kwa mchanganyiko wa 50/50 wa kusoma na kuandika katika ukubwa wa block nne: 4k, 64k, 512k na 1m. Inatoa taarifa za IOPS (input/output operations per second) na bandwidth kwa kila moja. Safu ya 4k ndiyo ya kuzingatia kwa database, seva ya barua pepe, au chochote kinachofanya uandikaji mwingi mdogo, kwa sababu IO nyingi za seva ni ndogo na zimetawanyika. Safu ya 1m ni ya backups na video, ambapo unasafirisha data nyingi mfululizo.

Sehemu ya network huendesha iperf3 dhidi ya seva za umma katika maeneo kadhaa, kwa pande zote mbili, ikitumia parallel streams. Hesabu namba ya chini hapa kama swali badala ya jibu, kwa sababu seva za umma za iperf3 zinashirikiwa na mara nyingi huwa zimejaa, hivyo matokeo mabaya yanaweza kusababishwa na upande wa pili.

Sehemu ya Geekbench inatoa alama ya single core na alama ya multi core. Single core inatabiri jinsi ombi moja, compile moja au query moja inavyokamilika haraka. Multi core inakuambia hasa una cores ngapi ulizonazo.

Disk: endesha fio mwenyewe

fio (flexible IO tester) ndicho zana inayotumika nyuma ya sehemu ya disk ya yabs, na kuitumia moja kwa moja ndipo unapoanza kuelewa maana ya flags zake.

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

Jaribio la 4k random read kwenye queue depth ya 32, kwenye filesystem unayoiangalia:

fio --name=randread4k --filename=./fio-testfile --size=2G --bs=4k \
  --rw=randread --ioengine=libaio --iodepth=32 --direct=1 \
  --runtime=60 --time_based --group_reporting

Mstari wa muhtasari unaopaswa kuusoma kutoka kwenye matokeo unaonekana hivi.

read: IOPS=184k, BW=719MiB/s (754MB/s)(42.1GiB/60001msec)

Chini yake, fio huchapisha block ya clat percentiles. Asilimia 99.00 (99.00th percentile) ndiyo takwimu inayofaa kunukuliwa, kwa sababu inaonyesha muda ambao ombi moja kati ya mia moja lilisubiri. Wastani wa latency huficha vipindi vya kukwama (stalls) ambavyo mtumiaji huviona.

• --direct=1 hufungua faili kwa kutumia O_DIRECT, hivyo usomaji hupita pembeni ya kernel page cache. Bila hii, jaribio la pili kwenye faili ya 2G kwenye mashine yenye 8G ya RAM litahudumiwa kutoka kwenye kumbukumbu na fio itaripoti IOPS katika mamilioni. Namba hiyo ni ya kweli, lakini ni namba ya kumbukumbu (memory).
• --ioengine=libaio hutuma maombi kwa njia ya asynchronous, jambo linaloruhusu --iodepth=32 kuweka maombi 32 kwa wakati mmoja. Kwa kutumia engine ya synchronous kama psync, iodepth inayozidi 1 haifanyi kazi yoyote, hivyo utapima ombi moja kwa wakati mmoja.
• --time_based --runtime=60 huendeshwa kwa sekunde 60 kamili badala ya kiasi cha kazi kilichopangwa, hivyo disk ya haraka na disk ya polepole hupata muda sawa wa kupima na kulinganisha kunakuwa kwa haki.
• --size=2G huweka ukubwa wa faili ya jaribio. Iweke kubwa kuliko cache yoyote iliyopo kwenye njia, na hakikisha una nafasi ya kutosha kwanza.

Random write ni amri ileile yenye --rw=randwrite. Iendeshe kivyake, kisha ufute faili hiyo.

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

Kwa mchanganyiko unaokaribia traffic ya kweli, tumia --rw=randrw --rwmixread=70. Aina ya hifadhi (storage) uliyopo hubadilisha matokeo haya zaidi ya flag yoyote, na mgawanyo huo umeelezwa katika tofauti kati ya hifadhi ya NVMe na SATA SSD kwenye VPS.

Wakati fio inaposimama na Unknown error -1

Direct IO haipatikani kwenye kila mfumo wa faili (filesystem), kwa hivyo wakati fio inaposhindwa kwenye ombi lake la kwanza huku --direct=1 ikiwa imewekwa, Direct IO ndilo jambo la kwanza kuliondoa kwenye mashaka. Hitilafu hiyo inaweza kuonekana hivi:

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

Endesha df -hT . kwanza. Type ya overlay, mfumo wa faili ambao Docker huupa container kwa chaguo-msingi, si chanzo cha tatizo lenyewe. overlayfs hupitisha O_DIRECT kwenye mfumo wa faili uliopo chini yake na huikataa tu wakati mfumo huo wa faili hauwezi kufanya Direct IO, kwa hivyo --direct=1 --ioengine=libaio hufanya kazi kwenye overlay iliyopo juu ya ext4 au xfs. Wakati mfumo wa faili ulio chini ya faili ya majaribio hauwezi kufanya Direct IO, fio kwa kawaida husema hivyo inapofungua faili: fio: looks like your file system does not support direct=1/buffered=0. Katika hali hiyo, elekeza --filename kwenye njia (path) iliyo kwenye hifadhi halisi ya ndani kama vile bind mounted volume, au endesha fio kwenye host badala ya ndani ya container. Ikiwa hifadhi halisi haipatikani, uendeshaji wa synchronous uliowekwa kwenye buffer angalau unathibitisha kuwa amri yenyewe ni sahihi.

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

Kuwa mkweli kuhusu uendeshaji huo. Baada ya uendeshaji wa kwanza, faili ya 256M hukaa kwenye page cache, kwa hivyo takwimu ya IOPS inaelezea RAM yako. Itumie kuthibitisha kuwa fio imewekwa na flags zinasomeka vizuri. Usiitumie kamwe kama matokeo ya diski.

Kwa nini dd si kipimo sahihi cha utendaji wa diski

dd hutumiwa sana katika mijadala ya VPS, na inajibu swali moja dogo tu.

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

Hiyo hupima kasi ya uandishi wa mfululizo (sequential write throughput) kwa kutumia thread moja na ombi moja linalosubiri. Hii ni njia ya kawaida ya kuhakiki kama mfumo unafanya kazi. Haielezi chochote kuhusu random IO, wala nini kinatokea wakati maombi 32 yanapofika kwa wakati mmoja. Ondoa oflag=direct na uandishi utapitia kwenye page cache, lakini conv=fdatasync bado hulazimisha data ya pato kwenda kwenye hifadhi kabla ya amri kukamilika. Ondoa hiyo pia na matokeo yanaweza kupima zaidi jinsi kernel yako inavyokubali uandishi kwenye kumbukumbu (memory), ndiyo maana takwimu za dd zinazotajwa kwenye machapisho ya majukwaa mara nyingi huwa hazina mantiki.

CPU: sysbench cpu

sysbench cpu --cpu-max-prime=20000 --threads=1 run
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run

Namba ya kuzingatia ni events per second. Endesha jaribio kwa thread moja kwanza. Hii ndiyo namba inayotathmini kasi ya kukamilisha ombi moja la PHP au kazi moja ya compile, na ndiyo inayotofautiana zaidi kati ya seva zenye bei sawa. Kisha endesha kwa kutumia thread zote, jambo linaloonyesha jinsi throughput inavyoongezeka kulingana na vCPU ulizotengewa.

Elewa vizuri kile ambacho jaribio hili hupima: sysbench cpu hutafuta namba tasa mara kwa mara kwa njia ya mgawanyo wa majaribio (trial division). Kwa kila namba inayojaribiwa, hufanya square root ya double precision, kisha hujaribu divisors kwa kutumia 64 bit integer modulo, ikilinganisha kila divisor na kikomo hicho cha floating point. Kwa hivyo, jaribio hili huchanganya kazi za integer na floating point. Halitumii bandwidth ya kumbukumbu, vector units, au cache kwa namna yoyote inayofanana na workload halisi, hivyo ni zana nzuri ya kulinganisha seva mbili lakini ni mbaya kwa kutabiri jinsi programu yako itakavyofanya kazi.

Ubuntu 24.04 inakuja na sysbench 1.0.20, ambapo jina la jaribio huwekwa mwanzoni. Ukinakili amri yenye --test=cpu kutoka kwenye chapisho la zamani, utapata WARNING: the --test option is deprecated. Alama kutoka sysbench 0.4 na sysbench 1.0 haziwezi kulinganishwa hata kidogo, kwa hivyo usijilinganishe kamwe na namba iliyochapishwa ambayo haitaji toleo lake.

Kumbukumbu: 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

Matokeo yanatolewa katika MiB/sec. Weka --memory-block-size katika 1M, na uihifadhi ikiwa sawa katika kila seva unayolinganisha. Katika 1K namba hupungua sana, kwa sababu unalipia gharama ya ziada ya kila operesheni mara elfu moja zaidi, hivyo unaishia kupima gharama ya mzunguko (loop) badala ya bandwidth ya kumbukumbu. Hii ndiyo flag inayokosewa mara nyingi zaidi katika alama za kumbukumbu zilizochapishwa.

Mtandao: iperf3

Njia sahihi ya kupima kasi ya mtandao (throughput) ni dhidi ya mashine nyingine unayoimiliki, kwa sababu hapo utajua kinachoendelea pande zote mbili.

Upande wa pili (far end):

iperf3 -s

Hii inasikiliza kwenye TCP 5201. Fungua port hiyo kwa ajili ya anwani unayotumia kupima pekee, na uifunge ukimaliza. Kanuni za msingi za firewall ya ufw kwenye VPS inaelezea sintaksia hiyo.

Kutoka kwenye VPS inayopimwa:

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

Amri ya kwanza inapima kasi ya kupakia (upload) kutoka kwenye mashine inayopimwa. -R inageuza mwelekeo, jambo linalopima kasi ya kupakua (download). -P 8 inafungua mitiririko (streams) minane kwa wakati mmoja.

Endesha mtiririko mmoja na ule wa mitiririko mingi, kwa sababu yanajibu maswali tofauti. Muunganisho mmoja wa TCP unaweza kubeba data isiyothibitishwa kulingana na ukubwa wa window yake, hivyo ukomo wake ni takriban ukubwa wa window hiyo ukigawanywa kwa muda wa round trip. Kwa latency ya 80 ms na window ya 4 MB, ukomo huo ni takriban 400 Mbit/s, hata kama link ya msingi ni ya kasi zaidi. Takwimu ya mtiririko mmoja inakuonyesha kasi utakayopata kwenye download moja. Takwimu ya mitiririko mingi inakuonyesha uwezo kamili wa link hiyo.

Fuatilia kiasi cha bandwidth ulichotengewa wakati unafanya hivi. Sekunde thelathini kwa kasi ya 1 Gbit/s huhamisha takriban 3.75 GB, na utaiendesha mara kadhaa kwa kila mwelekeo.

Takwimu za marejeleo, na jinsi ya kusoma zako

[
  {
    "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 ya ndani ya NVMe katika matokeo yaliyochapishwa kwa kawaida hufikia karibu 180,000 4k random read IOPS. SSD ya ndani ya SATA hufikia karibu 90,000. Hifadhi ya block iliyounganishwa kwenye mtandao (network attached block storage), ambapo kila ombi huvuka mtandao kabla ya kufika kwenye diski, huwa karibu na 12,000, na diski inayozunguka (spinning disk) hufikia takriban 180, kwa sababu husogeza kichwa cha kusomea (physical head) kwa kila ombi la random.

Hizi ni takwimu za kawaida zilizochapishwa kwa kila daraja la hifadhi, si vipimo kutoka kwa seva moja. Zitumie kwa lengo moja: kuhakikisha kuwa matokeo yako yapo katika kiwango sahihi cha ukubwa. Ikiwa mpango unaouzwa kama NVMe unatoa matokeo ya chini ya maelfu ya 4k IOPS, kwanza thibitisha kuwa --direct=1 ilikuwa imewashwa. Ikiwa ilikuwa imewashwa, angalia pia mipaka ya IOPS ya mpango huo na burst credits pamoja na msongamano wa hifadhi na maelezo ya vifaa vilivyotangazwa.

Kwa nini jaribio moja si kipimo cha utendaji (benchmark)

Matokeo ya mara moja ni picha ya dakika moja kwenye mashine inayotumiwa na wengine. Ichukulie kama sampuli moja tu.

• Fanya kila jaribio angalau mara tano, kwa nyakati tofauti za siku na angalau siku mbili tofauti. Hifadhi thamani ya kati (median) na mtawanyiko wa matokeo (spread). Matokeo yaliyochapishwa bila kuonyesha mtawanyiko ni takwimu za masoko tu.
• Rekodi steal time kando ya kila jaribio. Hifadhi majaribio ambapo st ilikuwa juu na uchunguze kama yanaakisi ushindani wa rasilimali au CPU quota ya mpango wako; kuyaondoa kunaweza kuficha utendaji halisi unaopata.
• Fanya jaribio la diski kwa muda wa aina mbili. Mipango mingi hutoa kiasi cha burst IOPS kinachojijaza baada ya muda, lakini jaribio la fio la sekunde 60 wala --runtime=600 haikuhakikishii kuwa umepima kiwango cha chini kabisa (floor). AWS gp2 credits zinaweza kudumisha 3,000 IOPS kwa angalau dakika 30 kutoka kwenye salio kamili, kwa hivyo majaribio yote mawili yanaweza kupima utendaji wa burst. Angalia mfano wa credit wa mtoa huduma na ufuatilie salio la credit kabla ya kuita matokeo kuwa utendaji endelevu.
• Hakikisha hakuna kitu kingine kinachoendelea. unattended-upgrades kuanzisha apt transaction katikati ya jaribio la CPU kunakupunguzia alama halisi, na ps -e -o comm= | grep -E 'apt|dpkg' kabla ya kila jaribio huchukua sekunde moja.
• Badilisha kigezo kimoja kwa wakati mmoja. Matoleo tofauti ya zana, ukubwa wa block, au idadi ya thread hutoa namba ambazo haziwezi kulinganishwa, bila kujali jinsi zinavyoonekana kufanana.

Unapolinganisha watoa huduma wawili, wafanyie majaribio hayo saa ileile ya siku ileile. Vinginevyo, utakuwa umepima muda wa siku badala ya utendaji.

Pima mzigo wako wa kazi mwishoni

Zana za usanifu (synthetic tools) hupanga mashine kulingana na viwango fulani. Mzigo wako wa kazi pekee ndio unaoweza kukuambia kama mashine inatosha. Pima muda wa kitu unachokifanya kihalisi.

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

Hiyo inafanya compression ya megabytes mia chache, kwa hivyo inatumia CPU na diski kwa pamoja na hubadilika wakati mojawapo ikibadilika. Onyo la Removing leading / from member names ni la kawaida. Ni bora zaidi kupima muda wa build yako mwenyewe, query yako ya polepole zaidi, au uonyeshaji wa ukurasa (page render) wako. Build inayochukua dakika 4 kwenye host moja na 7 kwenye nyingine imetatua swali hilo, bila kujali Geekbench ilifikiria nini. Hii pia ndiyo kipimo kinachokuambia wakati mashine kubwa zaidi inapoacha kuwa na thamani ya kulipiwa, jambo ambalo ni muhimu kujua kabla ya kusoma gharama halisi ya VPS kwa mwezi au kuhamisha mzigo wa kazi kwenye seva iliyojitolea (dedicated server).

FAQ

Kwa nini ninapata matokeo tofauti ya benchmark kila ninapoiendesha?

VPS inashiriki CPU, hifadhi na mtandao wa kimwili na watumiaji wengine, kwa hivyo matokeo yako yanategemea kile wanachokifanya wakati huo. Endesha vmstat 1 wakati wa jaribio na usome safu ya st: "steal time" endelevu hurekodi muda wa CPU ambao haupatikani, lakini inaweza kuakisi mtoa huduma anayetekeleza mgao wako wa CPU ulioununua pamoja na msongamano wa mwenyeji (host). Thamani iliyo juu ya 5% haithibitishi sababu. Jibu ni mbinu badala ya marekebisho. Endesha kila jaribio mara tano au zaidi kwa saa tofauti, kisha ripoti wastani (median) pamoja na tofauti ya matokeo (spread).

Kwa nini fio inaripoti mamilioni ya IOPS?

Karibu kila mara ni kwa sababu --direct=1 haipo. Bila hiyo, fio inasoma kupitia kernel page cache, kwa hivyo baada ya mzunguko wa kwanza, faili ya jaribio ya 2G hutolewa kutoka RAM na umepima bandwidth ya kumbukumbu. Ongeza --direct=1 na uweke faili ya jaribio kuwa kubwa kuliko cache yoyote iliyo kwenye njia. Ikiwa --direct=1 itafeli, endesha df -hT . na uangalie faili ya jaribio imekaa wapi. Aina ya overlay si tatizo yenyewe, kwa sababu overlayfs hupitisha O_DIRECT moja kwa moja kwenye hifadhi iliyo chini yake. Hamisha faili ya jaribio kwenye hifadhi halisi ya ndani (local storage) ikiwa mfumo wa faili (filesystem) uliopo chini unakataa direct IO.

Je, yabs.sh inatosha yenyewe?

Kwa mtazamo wa kwanza, ndiyo. Inaendesha fio kwa ukubwa wa block nne, iperf3 katika pande zote mbili, na Geekbench, na inachapisha muhtasari mmoja ambao watu wengine wanaweza kuusoma. Inakoma kutosha unapotaka kujua kwa nini namba fulani ni ile, kwa sababu huwezi kubadilisha flag zake kwa kila jaribio. Matokeo ya yabs yakionekana kuwa si sahihi, yanakili kwa kutumia fio au sysbench moja kwa moja na ubadilishe flag moja kwa wakati mmoja.

Ni namba gani moja inayotabiri jinsi programu yangu itakavyofanya kazi?

Kasi ya CPU ya core moja na latency ya 4k random read, kwa mpangilio huo, kwa mizigo mingi ya kazi ya wavuti na database. Takwimu za throughput zinaonekana kuvutia na mara chache huamua chochote, kwa sababu ombi la kawaida ni dogo. Taja asilimia 99 (99th percentile) kutoka kwenye block ya fio clat percentiles badala ya wastani, kwa kuwa ombi moja la polepole kati ya mia moja ndilo mtumiaji analoliona.

Je, ninahitaji kusakinisha chochote kabla ya kufanya benchmark?

fio, sysbench na iperf3 zote zipo kwenye hazina za Ubuntu na Debian: sudo apt install -y fio sysbench iperf3. yabs.sh inaendeshwa katika Bash na inahitaji curl au wget kwa ajili ya vipakuliwa, pamoja na tar ili kutoa (extract) Geekbench; bila tar, inaruka Geekbench. Inatumia fio na iperf3 zinapokuwa zimesakinishwa na kupakua binary tuli (static binaries) zinapokosekana. Futa kila faili ya jaribio unapomaliza, kwa sababu faili ya fio ya 2G iliyoachwa kwenye diski ya 20G inakuwa tahadhari ya "disk full" ya mtu mwingine wiki kadhaa baadaye.