Paano Mag-benchmark ng VPS nang Tama

Ano ang ibig sabihin ng pag-benchmark ng VPS

Para i-benchmark ang isang VPS, sinusukat ang 4 na bagay: kung gaano kabilis tumakbo ang isang CPU core, kung gaano kalaki ang memory bandwidth ng machine, kung ilang maliit at random na disk operation ang kayang ihatid ng storage bawat segundo, at kung gaano kalaking throughput ang naihahatid ng network link. Sa isang run ng yabs.sh, makukuha ang CPU, disk, at network results sa loob ng humigit-kumulang 10 minuto; gamitin ang hiwalay na memory test sa ibaba para sa memory bandwidth. Mas mahirap basahin ang resulta dahil ang isang VPS (virtual private server) ay nakikibahagi ng physical hardware sa ibang tenant. Dahil dito, maaaring mag-ulat ang parehong machine ng isang numero sa 03:00 at ibang-iba naman sa 20:00.

Ang plano rito ay patakbuhin muna ang yabs.sh para sa mabilis na pangkalahatang larawan, pagkatapos ay patakbuhin nang mano-mano ang mga tool sa ilalim nito. Kapag ikaw mismo ang nagpatakbo sa mga ito, maaari mong baguhin ang isang flag, obserbahan kung paano nagbabago ang numero, at malaman kung ano talaga ang sinusukat ng numerong iyon. Gawin ito pagkatapos ma-set up ang machine, hindi bago. Unahin ang mga hakbang sa unang 10 minuto sa bagong VPS, dahil hindi maayos ang resulta ng benchmark sa isang machine na inilalapat pa ang unang batch ng updates nito.

Suriin muna ang machine bago ito sukatin

Kalahati ng bawat masamang benchmark ay dulot ng machine na hindi naunawaan ng author.

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

Ang Hypervisor vendor: KVM ay nangangahulugang full virtualisation, kaya sarili mong kernel ang pinapatakbo mo. Ang pag-print ng lxc o openvz sa systemd-detect-virt ay nangangahulugang container virtualisation naman: ginagamit mo ang kernel ng host, at ang mga limitasyon sa CPU at memory ay mga setting ng cgroup (control group), hindi virtual hardware. Sa system na gumagamit ng cgroup v2, mababasa mo ang CPU limit mula sa cgroup ng container; ginagamit ang sumusunod na path kapag naka-mount ang cgroup na iyon sa /sys/fs/cgroup.

cat /sys/fs/cgroup/cpu.max

Nangangahulugan ang max 100000 na walang sariling quota ang cgroup na ito; maaari pa ring magtakda ng quota ang mga ancestor cgroup. Nangangahulugan ang 200000 100000 na maaari kang gumamit ng 200000 microseconds ng CPU sa bawat 100000 microsecond na period, na katumbas ng quota para sa dalawang core. Ang planong ina-advertise bilang 4 vCPU na may quota para sa dalawang core ay hindi kailanman makakakuha ng resulta na katumbas ng apat na core. Matutukoy ng mga benchmark tool ang limitasyong iyon: iniuulat ng VoxelBench ang CPU quota at tina-tag ang CPU bilang shared o throttled kapag mas marami ang CPU na inilalantad ng host kaysa sa pinapayagang gamitin ng server.

Mahalaga ang df -hT / sa ibang dahilan: ang column na Type. Kung overlay ang nakalagay dito, nasa loob ka ng container, at ilalarawan ng mga resulta ng disk ang storage na nasa ilalim ng overlay na iyon. Itala ito ngayon.

Patuloy na subaybayan ang steal time

Ang steal time ay bahagi ng oras na ginugol ng iyong virtual CPU sa sapilitang paghihintay habang hindi ito ini-schedule ng hypervisor. Kapaki-pakinabang itong palatandaan na hindi available ang CPU time, pero hindi nito natutukoy kung abala ang mga katabing virtual machine o ipinapatupad ng provider ang CPU quota para sa iyo.

vmstat 1 10

Basahin ang column na st sa kanan. Kapag tuloy-tuloy ang steal time, hindi available sa guest ang CPU time, pero hindi nito pinatutunayang overloaded ang host kapag lumampas sa 5% ang halaga. Maaaring sadyang ilabas ng mga provider bilang steal time ang pagpapatupad ng CPU quota. Ipinapakita ng top ang parehong figure na ipinapakita ng %st sa linya ng CPU. Panatilihing tumatakbo ang vmstat 1 sa ikalawang SSH session habang nagsasagawa ka ng benchmark, at isulat ang steal figure sa tabi ng bawat resulta.

Magsimula sa yabs.sh

yabs.sh (Yet Another Bench Script) ay isang shell script na nagpapatakbo ng fio, iperf3, at Geekbench at nagpi-print ng isang buod. Ginagamit nito ang fio at iperf3 kung naka-install na ang mga ito, at nagda-download ito ng mga static binary kung hindi pa. Karaniwan itong ginagamit sa mga talakayan tungkol sa VPS benchmark, kaya ang yabs output ang pinakamabilis na paraan upang maikumpara ang resulta sa ibang tao.

Ito ang one-line form mula sa mismong project.

curl -sL yabs.sh | bash

Direktang ipinapasa nito sa shell ang anumang kasalukuyang ibinibigay ng URL. I-download ito, basahin, saka patakbuhin.

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

Ilagay ang mga flag pagkatapos ng -s -- kapag nagpi-pipe, o direkta pagkatapos ng filename kapag nagpapatakbo ng lokal na kopya. Ang mahahalagang flag ay: nilalaktawan ng -f ang disk test, nilalaktawan ng -i ang network test, nilalaktawan ng -g ang Geekbench, nililimitahan ng -r sa tatlo ang mga lokasyon ng iperf3, pini-print ng -j ang mga resulta bilang JSON, at isinusulat ng -w results.json ang JSON sa isang file.

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

Dalawang bagay ang dapat malaman bago ang unang run. Ina-upload ng Geekbench ang iyong resulta at nagpi-print ng public browser.geekbench.com URL, kaya maaaring mabasa ng sinumang may hawak ng link ang iyong CPU model at mga score. Ganap na nilalaktawan ng -g ang test na iyon. Ikalawa, ang iperf3 stage ay naglilipat ng totoong network traffic sa mga server sa ilang rehiyon, at ibinabawas ito sa iyong monthly bandwidth allowance. Sa 1 Gbit/s link, maaaring umabot sa sampu-sampung gigabyte ang naililipat ng buong network stage, kaya gamitin ang -r kapag maliit ang allowance at ang -i kapag metered ang link.

Ano ang ibig sabihin ng bawat bahagi ng yabs output

Gumagamit ang disk section ng fio na may 50/50 na halo ng read at write sa apat na block size: 4k, 64k, 512k, at 1m. Iniuulat nito ang IOPS (input/output operations per second) at bandwidth para sa bawat isa. Ang 4k row ang dapat pagtuunan ng pansin para sa database, mail server, o anumang gumagawa ng maraming maliliit na write, dahil maliit at magkakahiwalay ang karamihan sa server IO. Ang 1m row naman ang para sa mga backup at video, kung saan mahahabang sunod-sunod na byte ang inililipat.

Gumagamit ang network section ng iperf3 laban sa mga public server sa ilang rehiyon, sa parehong direksyon, gamit ang parallel stream. Ituring ang mababang resulta rito bilang tanong, hindi bilang tiyak na sagot, dahil shared at madalas saturated ang mga public iperf3 server. Kaya maaaring ang malayong endpoint ang sanhi ng mahinang resulta.

Nagbibigay ang Geekbench section ng single core score at multi core score. Tinatantiya ng single core kung gaano kabilis matatapos ang isang request, isang compile, o isang query. Pangunahing ipinapakita naman ng multi core kung ilang core ang aktuwal mong nakuha.

Disk: patakbuhin mismo ang fio

Ang fio (flexible IO tester) ang tool sa ilalim ng disk section ng yabs. Kapag direkta mo itong pinatakbo, mas mauunawaan ang kahulugan ng mga flag.

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

Isang 4k random read test sa queue depth na 32, gamit ang filesystem na aktuwal mong sinusuri:

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

Ganito ang summary line na dapat basahin mula sa output.

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

Sa ilalim nito, nagpi-print ang fio ng clat percentiles block. Ang 99.00th percentile ang halagang dapat banggitin, dahil ipinapakita nito kung gaano katagal naghintay ang pinakamabagal na 1 request sa bawat 100. Itinatago ng average latency ang mismong mga pagkaantala na napapansin ng user.

• Binubuksan ng --direct=1 ang file gamit ang O_DIRECT, kaya hindi dumaraan ang reads sa kernel page cache. Kung wala ito, ang second pass sa isang 2G file sa machine na may 8G RAM ay manggagaling sa memory at magrereport ang fio ng IOPS na nasa millions. Totoo ang numerong iyon, pero memory number ito.
• Nagsa-submit ang --ioengine=libaio ng asynchronous requests. Dahil dito, kayang panatilihin ng --iodepth=32 na may 32 request na kasalukuyang tumatakbo. Sa synchronous engine gaya ng psync, walang epekto ang iodepth na higit sa 1, kaya isang request lang bawat pagkakataon ang sinusukat.
• Pinapatakbo ng --time_based --runtime=60 ang test sa nakapirming 60 segundo sa halip na sa nakapirming dami ng work. Dahil dito, pareho ang wall clock time para sa mabilis at mabagal na disk, kaya patas ang comparison.
• Itinatakda ng --size=2G ang laki ng test file. Panatilihin itong mas malaki kaysa sa anumang cache sa path, at tiyaking may sapat na free space muna.

Pareho ang command para sa random write, pero gamitin ang --rw=randwrite. Patakbuhin ito nang hiwalay, pagkatapos ay i-delete ang file.

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

Para sa mix na mas malapit sa totoong traffic, gamitin ang --rw=randrw --rwmixread=70. Mas malaki ang epekto sa mga resultang ito ng uri ng storage na ginagamit mo kaysa sa alinmang flag. Saklaw ng pagkakaiba ng NVMe at SATA SSD storage sa isang VPS ang split na iyon.

Kapag huminto ang fio na may “Unknown error -1”

Hindi available ang direct IO sa lahat ng filesystem. Kaya kapag nabigo ang fio sa pinakaunang request nito na may nakatakdang --direct=1, direct IO ang unang dapat i-rule out. Maaaring ganito ang hitsura ng failure:

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

Patakbuhin muna ang df -hT .. Ang Type na overlay, ang filesystem na default na ibinibigay ng Docker sa isang container, ay hindi mismong sanhi. Ipinapasa ng overlayfs ang O_DIRECT sa filesystem sa ilalim nito at tinatanggihan lamang ito kapag hindi kayang magsagawa ng direct IO ng filesystem na iyon. Kaya gumagana ang --direct=1 --ioengine=libaio sa overlay na nasa ibabaw ng ext4 o xfs. Kapag hindi talaga kayang magsagawa ng direct IO ng filesystem sa ilalim ng test file, karaniwang ipinapakita ito ng fio habang binubuksan nito ang file: fio: looks like your file system does not support direct=1/buffered=0. Sa ganitong sitwasyon, ituro ang --filename sa path sa tunay na local storage, gaya ng bind mounted volume, o patakbuhin ang fio sa host sa halip na sa container. Kung hindi maaabot ang tunay na storage, makapagpapatunay man lamang ang buffered synchronous run na tama ang command mismo.

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

Maging malinaw kung ano ang sinusukat ng run na iyon. Pagkatapos ng unang pass, nasa page cache na ang 256M file, kaya inilalarawan ng IOPS figure ang iyong RAM. Gamitin ito upang kumpirmahing naka-install ang fio at tama ang pag-parse ng mga flag. Huwag itong banggitin bilang resulta ng disk.

Bakit hindi disk benchmark ang dd

Madalas lumitaw ang dd sa mga thread tungkol sa VPS, at sinasagot nito ang isang makitid na tanong.

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

Sinusukat nito ang sequential write throughput gamit ang isang thread at isang request na kasalukuyang isinasagawa. Katanggap-tanggap itong sanity check. Wala itong sinasabi tungkol sa random IO, at wala rin itong sinasabi tungkol sa nangyayari kapag 32 request ang sabay-sabay na dumarating. Kapag inalis ang oflag=direct, dumadaan ang mga write sa page cache, pero pinipilit pa rin ng conv=fdatasync na maisulat sa storage ang output data bago matapos ang command. Kapag inalis din iyon, kadalasang nasusukat lamang kung gaano kabilis tumatanggap ang kernel ng mga write papunta sa memory, kaya madalas katawa-tawa ang mga numerong dd na binabanggit sa mga post sa forum.

CPU: sysbench cpu

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

Ang dapat panatilihin ay events per second. Patakbuhin muna ito gamit ang isang thread. Ito ang numerong tumutukoy kung gaano kabilis matapos ang isang PHP request o isang compile job, at ito ang pinakakapansin-pansing nagkakaiba sa mga host na pareho ang presyo. Pagkatapos, patakbuhin ito gamit ang lahat ng thread. Ipinapakita nito kung paano lumalaki ang throughput sa lahat ng inilaan mong vCPU.

Tiyaking malinaw kung ano ang sinusukat nito: paulit-ulit na naghahanap ang sysbench cpu ng mga prime number gamit ang trial division. Para sa bawat candidate, kumukuha ito ng double precision square root. Pagkatapos, sinusuri nito ang mga divisor gamit ang 64 bit integer modulo at ikinukumpara ang bawat divisor sa floating point limit na iyon. Kaya pinagsasama nito ang integer at floating point na trabaho. Hindi nito sinusubok ang memory bandwidth, vector units, o cache sa paraang kahawig ng aktuwal na workload. Dahil dito, angkop ito sa pagraranggo ng dalawang host ngunit hindi maaasahan sa paghula kung paano tatakbo ang iyong application.

Kasama sa Ubuntu 24.04 ang sysbench 1.0.20, kung saan nauuna ang pangalan ng test. Kapag kinopya mo ang isang command na may --test=cpu mula sa lumang post, makukuha mo ang WARNING: the --test option is deprecated. Hindi maikukumpara ang mga score mula sa sysbench 0.4 at sysbench 1.0. Kaya huwag kailanman ikumpara ang resulta mo sa isang inilathalang numero na hindi nagsasaad ng bersyon nito.

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

Ang resulta ay nasa MiB/sec. Panatilihin ang --memory-block-size sa 1M, at tiyaking pareho ito sa bawat host na ikinukumpara mo. Sa 1K, bumabagsak nang malaki ang resulta dahil 1,000 beses na mas madalas mong binabayaran ang overhead sa bawat operation. Kaya ang aktuwal mong nasusukat ay ang loop cost, hindi ang memory bandwidth. Ito ang flag na pinakamadalas magkaiba sa mga inilalathalang memory score.

Network: iperf3

Ang maaasahang paraan para subukan ang throughput ay gumamit ng pangalawang machine na kontrolado mo. Sa ganitong paraan, alam mo kung ano ang nangyayari sa magkabilang dulo.

Sa remote end:

iperf3 -s

Nakikinig ito sa TCP 5201. Buksan ang port para lamang sa address na gagamitin mo sa pag-test, at isara ito kapag tapos ka na. Saklaw ng Mga pangunahing ufw firewall rule sa isang VPS ang syntax.

Mula sa VPS na sinusuri:

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

Sinusukat ng una ang upload mula sa machine na sinusuri. Binabaligtad ng -R ang direksyon, kaya download ang sinusukat nito. Nagbubukas ang -P 8 ng walong parallel stream.

Patakbuhin pareho ang single stream at ang parallel version dahil magkaibang tanong ang sinasagot ng mga ito. Isang TCP connection lang ang kayang magpanatili ng dami ng unacknowledged data na pinapayagan ng window nito. Kaya ang limit nito ay humigit-kumulang window size na hinati sa round trip time. Sa 80 ms na latency at 4 MB na window, nasa 400 Mbit/s ang limit na iyon, gaano man kabilis ang link sa ilalim nito. Ipinapakita ng single stream figure kung ano ang makukuha ng isang download. Ipinapakita naman ng parallel figure ang capacity ng link.

Bantayan ang iyong bandwidth allowance habang ginagawa ito. Sa loob ng 30 segundo sa 1 Gbit/s, humigit-kumulang 3.75 GB ang maililipat, at patatakbuhin mo ito nang ilang beses sa bawat direksyon.

Mga reference figure at kung paano basahin ang iyo

[
  {
    "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"
  }
]

Ang isang lokal na NVMe volume sa mga na-publish na resulta ay karaniwang umaabot sa 180,000 4k random read IOPS. Ang lokal na SATA SSD ay nasa humigit-kumulang 90,000. Ang network-attached block storage, kung saan dumadaan muna sa network ang bawat request bago makarating sa disk, ay mas malapit sa 12,000, habang ang spinning disk ay karaniwang nakakakuha ng humigit-kumulang 180, dahil ginagalaw nito ang physical head para sa bawat random request.

Karaniwang published figures ang mga ito para sa bawat klase ng storage, hindi mga sukat mula sa iisang host. Gamitin ang mga ito para sa isang layunin: tiyaking nasa tamang order of magnitude ang sarili mong resulta. Kung ang isang plan na ibinebentang NVMe ay nagba-benchmark ng mababang libo ng 4k IOPS, kumpirmahin muna kung naka-on ang --direct=1. Kung naka-on ito, tingnan ang IOPS limits at burst credits ng plan, pati ang storage contention at hardware na ipinangako.

Bakit hindi benchmark ang isang run

Ang isang resulta ay snapshot lamang ng isang minuto sa isang shared machine. Ituring ito bilang isang sample.

• Patakbuhin ang bawat test nang hindi bababa sa limang beses, sa magkakaibang oras at sa hindi bababa sa dalawang magkaibang araw. Itago ang median at ang spread. Ang resultang inilathala nang walang spread ay marketing figure.
• Itala ang steal time kasabay ng bawat run. Panatilihin ang mga run kung saan mataas ang st at siyasatin kung nagpapakita ang mga ito ng contention o ng CPU quota ng plan; kapag itinapon ang mga ito, maaaring maitago ang performance na aktuwal mong natatanggap.
• Patakbuhin ang disk test sa dalawang duration. Maraming plan ang nagbibigay ng burst IOPS allowance na napupunan muli sa paglipas ng panahon, ngunit hindi ginagarantiya ng isang 60 second na fio run o ng --runtime=600 na nasukat mo ang floor. Maaaring magpanatili ang AWS gp2 ng 3,000 IOPS nang hindi bababa sa 30 minuto kapag puno ang balance, kaya maaaring masukat ng parehong run ang burst performance. Suriin ang credit model ng provider at i-monitor ang credit balance bago tawaging sustained performance ang isang resulta.
• Tiyaking walang ibang tumatakbo. Kapag nagsimula ang unattended-upgrades ng apt transaction sa kalagitnaan ng CPU test, mababawasan nito ang aktuwal mong points, at isang segundo lamang ang kailangan ng ps -e -o comm= | grep -E 'apt|dpkg' bago ang bawat run.
• Isang variable lang ang baguhin sa bawat pagkakataon. Ang magkakaibang tool version, block size, o thread count ay nagbubunga ng mga numerong hindi maaaring paghambingin, gaano man magkatulad ang hitsura ng mga ito.

Kapag naghambing ka ng dalawang provider, patakbuhin ang mga ito sa parehong oras ng parehong araw. Kung hindi, oras ng araw ang nasukat mo.

Huling i-benchmark ang sarili mong workload

Nagbibigay ng ranggo sa mga machine ang synthetic tool. Ang sarili mong workload lang ang makapagsasabi kung sapat ang isang machine. Sukatin ang oras ng aktuwal mong ginagawa.

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

Kino-compress nito ang ilang daang megabyte, kaya sabay nitong ginagamit ang CPU at disk. Nagbabago ang resulta kapag nagbago ang alinman sa mga ito. Normal ang babalang Removing leading / from member names. Mas mainam pa ring sukatin ang oras ng sarili mong build, ng pinakamabagal mong query, o ng sarili mong page render. Kung tumatagal ng 4 minuto ang build sa isang host at 7 minuto sa isa pa, malinaw na ang sagot, anuman ang naging resulta sa Geekbench. Ito rin ang sukat na magsasabi kung kailan hindi na sulit bayaran ang mas makapangyarihang machine. Mahalagang malaman ito bago mo basahin kung magkano talaga ang VPS bawat buwan o ilipat ang workload sa dedicated server.

FAQ

Bakit iba ang resulta ng benchmark sa bawat pagpapatakbo ko?

Nakikibahagi ang isang VPS sa physical CPU, storage, at network kasama ng ibang tenant, kaya nakadepende ang resulta sa ginagawa nila sa oras na iyon. Patakbuhin ang vmstat 1 habang isinasagawa ang test at basahin ang column na st: itinatala ng sustained steal time ang CPU time na hindi available, pero maaari rin nitong ipakita na ipinapatupad ng provider ang binili mong CPU allocation, bukod sa host contention. Hindi sapat ang halagang lampas 5% para matukoy ang sanhi. Ang tamang sagot ay nasa method, hindi sa tuning. Patakbuhin ang bawat test nang lima o higit pang beses sa magkakaibang oras, pagkatapos ay iulat ang median kasama ang spread.

Bakit milyun-milyong IOPS ang iniuulat ng fio?

Halos palagi itong nangyayari dahil nawawala ang --direct=1. Kung wala ito, nagbabasa ang fio sa kernel page cache. Kaya pagkatapos ng unang pass, mula sa RAM inihahatid ang 2G test file at memory bandwidth ang nasusukat mo. Idagdag ang --direct=1 at tiyaking mas malaki ang test file kaysa sa anumang cache sa path. Kung mabibigo ang --direct=1, patakbuhin ang df -hT . at tingnan kung saan nakalagay ang test file. Hindi problema mismo ang isang overlay type, dahil ipinapasa ng overlayfs ang O_DIRECT sa storage sa ilalim nito. Ilipat lamang ang test file sa totoong local storage kung tinatanggihan ng filesystem sa ilalim nito ang direct IO.

Sapat na ba ang yabs.sh nang mag-isa?

Para sa paunang pagsusuri, oo. Pinapatakbo nito ang fio sa apat na block size, ang iperf3 sa dalawang direksiyon, at ang Geekbench, at nagpi-print ito ng isang summary na mababasa ng ibang tao. Hindi na ito sapat kapag gusto mong malaman kung bakit ganoon ang isang resulta, dahil hindi mo maaaring baguhin ang mga flag nito para sa bawat test. Kapag mukhang mali ang resulta ng yabs, ulitin ito nang direkta gamit ang fio o sysbench at baguhin ang isang flag bawat pagkakataon.

Aling iisang numero ang pinakamahusay na naghuhula kung ano ang mararanasan ko sa application?

Ang single-core CPU speed at 4k random read latency, sa pagkakasunod na iyon, para sa karamihan ng web at database workload. Mukhang kahanga-hanga ang throughput figures, pero bihira itong maging mapagpasya dahil maliit ang karaniwang request. Iulat ang 99th percentile mula sa fio clat percentiles block sa halip na average, dahil ang mabagal na isang request sa bawat 100 ang napapansin ng user.

Kailangan ko bang mag-install ng anuman bago mag-benchmark?

Nasa Ubuntu at Debian archives ang fio, sysbench, at iperf3: sudo apt install -y fio sysbench iperf3. Tumatakbo ang yabs.sh sa Bash at nangangailangan ng curl o wget para sa downloads, pati tar para ma-extract ang Geekbench. Kapag wala ang tar, nilalaktawan nito ang Geekbench. Ginagamit nito ang fio at iperf3 kapag naka-install ang mga ito, at nagda-download ito ng static binaries kapag wala ang mga ito. I-delete ang bawat test file kapag tapos ka na, dahil ang naiwan na 2G fio file sa 20G disk ay maaaring maging alert na puno na ang disk pagkalipas ng ilang linggo.