VPS goed benchmarken: zo meet u prestaties

Wat het betekent om een VPS te benchmarken

Bij het benchmarken van een VPS meet u vier zaken: hoe snel één CPU-core werkt, hoeveel geheugenbandbreedte de machine heeft, hoeveel kleine willekeurige schijfbewerkingen de opslag per seconde verwerkt en hoeveel doorvoer de netwerkverbinding levert. Eén uitvoering van yabs.sh levert u alle vier metingen in ongeveer tien minuten. Het resultaat interpreteren is lastiger, omdat een VPS (virtual private server) fysieke hardware deelt met andere tenants. Daardoor kan dezelfde machine om 03:00 één waarde rapporteren en om 20:00 een heel andere.

Het plan is om eerst yabs.sh uit te voeren voor een snel overzicht en daarna de onderliggende tools handmatig uit te voeren. Als u ze zelf uitvoert, kunt u één flag wijzigen, zien hoe de waarde verandert en leren wat die waarde werkelijk meet. Doe dit nadat de machine is ingesteld, niet ervoor. De stappen in de eerste tien minuten op een nieuwe VPS komen eerst, omdat een machine die nog de eerste reeks updates toepast slechte benchmarkresultaten oplevert om redenen die niets met de hardware te maken hebben.

Bekijk de machine voordat u deze meet

De helft van elke slechte benchmark wordt veroorzaakt door een machine die de auteur niet begreep.

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

Hypervisor vendor: KVM betekent volledige virtualisatie. U gebruikt dan uw eigen kernel. systemd-detect-virt, lxc of openvz betekent daarentegen containerisatie: u deelt de kernel van de host, en uw CPU- en geheugenlimieten zijn cgroup-instellingen (control group) in plaats van virtuele hardware. Op een systeem met cgroup v2 kunt u de CPU-limiet rechtstreeks uitlezen.

cat /sys/fs/cgroup/cpu.max

max 100000 betekent dat er geen quota is. 200000 100000 betekent dat u in elke periode van 100000 microseconden 200000 microseconden CPU-tijd mag gebruiken. Dat komt overeen met een quota ter waarde van twee cores. Een abonnement dat wordt geadverteerd als 4 vCPU met een quota van twee cores behaalt nooit dezelfde score als vier cores. Geen enkele benchmarktool geeft een regel weer die uitlegt waarom.

df -hT / is om een andere reden van belang: de kolom Type. Als deze overlay bevat, bevindt u zich in een container en moet de onderstaande schijftest worden aangepast. Noteer dit nu.

Controleer steal time gedurende de hele test

Steal time is het aandeel van de tijd waarin uw virtuele CPU gereed was om te draaien, maar de hypervisor de fysieke core aan iemand anders gaf. Dit is het belangrijkste afzonderlijke signaal dat een resultaat door uw buren wordt veroorzaakt en niet door de hardware.

vmstat 1 10

Lees de kolom st aan de rechterkant. Een constante waarde van 0 of 1 is normaal. Aanhoudende waarden boven 5 betekenen dat de host op dat moment overbezet is. Elk CPU-getal dat u in dat tijdvenster vastlegt, is dan laag zonder dat uw machine daar de oorzaak van is. top toont hetzelfde cijfer als %st op de CPU-regel. Laat vmstat 1 in een tweede SSH-sessie draaien terwijl u een benchmark uitvoert. Noteer de steal time naast elk resultaat.

Begin met yabs.sh

yabs.sh (Yet Another Bench Script) is een shellscript dat statische binaries van fio, iperf3 en Geekbench downloadt, deze uitvoert en één samenvatting afdrukt. Het is de standaardtaal in discussies over VPS-benchmarks. Een yabs-uitvoer is daarom de snelste manier om resultaten met iemand anders te vergelijken.

De eigen opdracht van het project met één regel is als volgt.

curl -sL yabs.sh | bash

Hiermee wordt alles wat de URL momenteel aanbiedt rechtstreeks naar een shell doorgestuurd. Download het script, lees het en voer het daarna uit.

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

Plaats flags na -s -- wanneer u de uitvoer doorstuurt, of direct na de bestandsnaam wanneer u een lokale kopie uitvoert. De belangrijkste opties zijn: -f slaat de schijftest over, -i slaat de netwerktest over, -g slaat Geekbench over, -r beperkt de iperf3-locaties tot twee, -j geeft de resultaten als JSON weer en -w results.json schrijft die JSON naar een bestand.

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

Houd vóór de eerste uitvoering rekening met twee zaken. Geekbench uploadt uw resultaat en geeft een openbare URL van browser.geekbench.com weer. Iedereen met die link kan uw CPU-model en scores bekijken. Met -g slaat u deze test volledig over. Daarnaast genereert de iperf3-fase daadwerkelijk netwerkverkeer naar servers in meerdere regio's. Dit netwerkverkeer wordt afgetrokken van uw maandelijkse bandbreedte. Op een verbinding van 1 Gbit/s kan een volledige netwerkfase tientallen gigabytes aan verkeer genereren. Gebruik daarom -r bij een beperkte bundel en -i op een verbinding waarvoor u per verbruik betaalt.

Wat elk onderdeel van de yabs-uitvoer betekent

In het schijfgedeelte wordt fio uitgevoerd met een verhouding van 50/50 tussen lezen en schrijven, bij vier blokgroottes: 4k, 64k, 512k en 1m. Voor elke blokgrootte worden IOPS (input/output operations per second) en bandbreedte weergegeven. De rij voor 4k is belangrijk voor een database, een mailserver en andere toepassingen die veel kleine schrijfbewerkingen uitvoeren, omdat de meeste server-IO uit kleine, verspreide bewerkingen bestaat. De rij voor 1m is relevant voor back-ups en video, waarbij lange reeksen bytes worden verplaatst.

In het netwerkgedeelte wordt iperf3 uitgevoerd tegen openbare servers in meerdere regio's, in beide richtingen en met parallelle streams. Beschouw een lage waarde hier als een vraag en niet als een conclusie, omdat openbare iperf3-servers gedeeld worden en vaak verzadigd zijn. Een slecht resultaat kan daarom aan de externe kant liggen.

Het Geekbench-gedeelte geeft een score voor één core en een score voor meerdere cores. De score voor één core voorspelt hoe snel één verzoek, één compilatie of één query wordt voltooid. De score voor meerdere cores geeft vooral aan hoeveel cores u daadwerkelijk hebt gekregen.

Schijf: voer fio zelf uit

fio (flexible IO tester) is de tool achter het schijfgedeelte van yabs. Als u fio rechtstreeks aanstuurt, krijgen de flags betekenis.

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

Een test voor willekeurige 4k-reads met queue depth 32, op het bestandssysteem dat u daadwerkelijk gebruikt:

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

De samenvattingsregel die u uit de uitvoer moet lezen, ziet er als volgt uit.

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

Daaronder geeft fio een blok clat percentiles weer. Het 99.00e percentiel is de waarde die u moet vermelden. Deze waarde geeft aan hoe lang het langzaamste verzoek van honderd verzoeken heeft gewacht. Een gemiddelde latentie verbergt precies de vertragingen die een gebruiker merkt.

• --direct=1 opent het bestand met O_DIRECT, zodat reads de page cache van de kernel omzeilen. Zonder deze optie wordt de tweede doorgang over een bestand van 2G op een machine met 8G RAM vanuit het geheugen uitgevoerd en rapporteert fio IOPS in de miljoenen. Dat getal is correct, maar het gaat om geheugenprestaties.
• --ioengine=libaio verstuurt asynchrone verzoeken. Daardoor kan --iodepth=32 32 verzoeken tegelijk uitvoeren. Met een synchrone engine zoals psync heeft een iodepth hoger dan 1 helemaal geen effect. U meet dan steeds één verzoek tegelijk.
• --time_based --runtime=60 laat de test 60 seconden duren in plaats van een vaste hoeveelheid werk uit te voeren. Een snelle en een trage schijf krijgen daardoor dezelfde verstreken tijd, waardoor de vergelijking eerlijk blijft.
• --size=2G stelt de grootte van het testbestand in. Houd deze groter dan elke cache in het pad en controleer eerst of er voldoende vrije ruimte is.

Een random write gebruikt hetzelfde commando met --rw=randwrite. Voer de test afzonderlijk uit en verwijder het bestand daarna.

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

Gebruik --rw=randrw --rwmixread=70 voor een mix die dichter bij echte netwerktraffic ligt. Het type opslag waarop uw systeem draait heeft meer invloed op deze resultaten dan welke flag ook. Dat verschil wordt behandeld in het verschil tussen NVMe- en SATA-SSD-opslag op een VPS.

Wanneer fio stopt met Unknown error -1

Directe I/O is niet op elk bestandssysteem beschikbaar. overlay, het bestandssysteem dat Docker standaard aan een container geeft, en verschillende netwerkbestandssystemen ondersteunen O_DIRECT niet. Daardoor dient libaio een aanvraag in die de kernel niet kan voltooien en stopt 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

Voer eerst df -hT . uit. Als de kolom Type overlay aangeeft, laat u --filename verwijzen naar een pad op echte opslag, bijvoorbeeld een als bind mount gekoppeld volume, of voert u fio uit op de host in plaats van in de container. Als u geen toegang hebt tot echte opslag, toont een gebufferde synchrone uitvoering in elk geval aan dat de opdracht zelf correct is.

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

Wees duidelijk over wat deze uitvoering aantoont. Na de eerste doorgang staat het bestand van 256M in de page cache. Het IOPS-resultaat beschrijft dan uw RAM. Gebruik deze uitvoering om te controleren of fio is geïnstalleerd en of de flags correct worden verwerkt. Citeer het resultaat nooit als schijfresultaat.

Waarom dd geen schijfbenchmark is

dd komt in veel VPS-discussies voor en beantwoordt één specifieke vraag.

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

Hiermee meet u de sequentiële schrijfsnelheid met één thread en één aanvraag tegelijk. Dit is een redelijke plausibiliteitscontrole. De opdracht zegt niets over willekeurige IO en niets over wat er gebeurt wanneer 32 aanvragen tegelijk binnenkomen. Laat oflag=direct weg en u meet grotendeels hoe snel uw kernel schrijfbewerkingen in het geheugen accepteert. Daarom zijn de vermelde dd-waarden in forumberichten vaak absurd.

CPU: sysbench cpu

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

De waarde die u moet bijhouden is events per second. Voer de test eerst met één thread uit. Dit getal bepaalt hoe snel één PHP-verzoek wordt voltooid of één compilatietaak wordt uitgevoerd. Het verschilt het meest tussen hosts met dezelfde prijs. Voer de test daarna met alle threads uit. Daarmee ziet u of uw vCPU's afzonderlijke cores zijn of delen van één core.

Wees duidelijk over wat deze test meet: sysbench zoekt herhaaldelijk priemgetallen met 64-bits gehele getallen. De test belast de geheugenbandbreedte, vectorunits en cache niet op een manier die overeenkomt met een realistische workload. De test is daarom geschikt om twee hosts te rangschikken, maar niet om te voorspellen hoe uw applicatie zal presteren.

Ubuntu 24.04 levert sysbench 1.0.20, waarin de testnaam vooraan staat. Als u een opdracht met --test=cpu uit een oud bericht kopieert, krijgt u WARNING: the --test option is deprecated. Scores van sysbench 0.4 en sysbench 1.0 zijn helemaal niet vergelijkbaar. Vergelijk uw resultaat daarom nooit met een gepubliceerd getal waarbij de versie niet wordt vermeld.

Geheugen: sysbench-geheugen

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

Het resultaat wordt weergegeven in MiB/sec. Lezen is op elke machine sneller dan schrijven. Houd --memory-block-size op 1M en gebruik exact dezelfde waarde op elke host die u vergelijkt. Bij 1K daalt de waarde sterk, omdat de overhead per bewerking duizend keer vaker wordt betaald. U meet daardoor vooral de kosten van de lus in plaats van de geheugenbandbreedte. Dit is de vlag die in gepubliceerde geheugenscores het vaakst niet overeenkomt.

Netwerk: iperf3

De betrouwbare manier om de doorvoer te testen is met een tweede machine die u beheert. Dan weet u wat beide uiteinden doen.

Op het externe uiteinde:

iperf3 -s

Dit luistert op TCP 5201. Open de poort alleen voor het adres waarvan u de test uitvoert en sluit de poort zodra u klaar bent. Basale ufw-firewallregels op een VPS beschrijft de syntaxis.

Vanaf de VPS die u test:

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

De eerste opdracht meet de uploadsnelheid vanaf de machine die u test. -R keert de richting om en meet daarmee de downloadsnelheid. -P 8 opent acht parallelle streams.

Voer zowel de test met één stream als de parallelle variant uit. Ze beantwoorden verschillende vragen. Eén TCP-verbinding kan slechts zoveel niet-bevestigde gegevens bevatten als het venster toestaat. De bovengrens is daarom ongeveer de venstergrootte gedeeld door de round-trip time. Bij een latentie van 80 ms en een venster van 4 MB ligt die bovengrens rond 400 Mbit/s, ongeacht hoe snel de onderliggende verbinding is. Het cijfer voor één stream laat zien wat één download haalt. Het parallelle cijfer laat de capaciteit van de verbinding zien.

Houd tijdens deze test uw datalimiet in de gaten. Dertig seconden met 1 Gbit/s verplaatst ongeveer 3.75 GB. U voert de test meerdere keren in beide richtingen uit.

Referentiewaarden en hoe u uw resultaten leest

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

Een lokaal NVMe-volume haalt in gepubliceerde resultaten meestal ongeveer 180,000 4k-random-read-IOPS. Een lokale SATA-SSD komt uit op ongeveer 90,000. Netwerkopslag voor block storage, waarbij elk verzoek via een netwerk gaat voordat het een schijf bereikt, zit dichter bij 12,000. Een draaiende harde schijf haalt ongeveer 180, omdat deze voor elk willekeurig verzoek een fysieke leeskop verplaatst.

Dit zijn typische gepubliceerde waarden voor elke opslagklasse. Het zijn geen metingen vanaf één host. Gebruik ze uitsluitend om te controleren of uw eigen resultaat in dezelfde orde van grootte ligt. Als een als NVMe verkocht plan slechts enkele duizenden 4k-IOPS haalt, controleer dan eerst of --direct=1 was ingeschakeld. Als dat het geval was, is de opslag niet wat de productpagina beschrijft, of deelt u deze met een zeer drukke buur.

Waarom één meting geen benchmark is

Eén resultaat is een momentopname van één minuut op een gedeelde machine. Beschouw het als één steekproef.

• Voer elke test ten minste vijf keer uit, verspreid over verschillende uren en ten minste twee verschillende dagen. Noteer de mediaan en de spreiding. Een resultaat zonder spreiding is een marketingcijfer.
• Noteer de steal-tijd bij elke run. Verwijder runs waarin st hoog was, of vermeld dit op zijn minst.
• Voer de schijftest uit met twee looptijden. Veel abonnementen bieden een burst-IOPS-tegoed dat na verloop van tijd wordt aangevuld. Een fio-run van 60 seconden meet de burst, terwijl --runtime=600 de ondergrens meet. De ondergrens is wat u op een slechte dag krijgt.
• Controleer of er niets anders actief is. Als unattended-upgrades halverwege een CPU-test een apt-transactie start, kost u dat daadwerkelijk punten. Bovendien neemt ps -e -o comm= | grep -E 'apt|dpkg' vóór elke run een seconde in beslag.
• Wijzig steeds één variabele tegelijk. Verschillende toolversies, blokgroottes of aantallen threads leveren waarden op die u niet kunt vergelijken, hoe vergelijkbaar ze ook lijken.

Wanneer u twee providers vergelijkt, voert u de tests op dezelfde dag en hetzelfde uur uit. Anders meet u het tijdstip van de dag.

Benchmark uw eigen workload als laatste

Synthetische tools rangschikken machines. Alleen uw eigen workload laat zien of een machine volstaat. Meet de tijd van wat u daadwerkelijk doet.

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

Daarbij worden enkele honderden megabytes gecomprimeerd. Hierdoor worden zowel de CPU als de schijf belast en verandert de uitkomst wanneer een van beide verandert. De waarschuwing van Removing leading / from member names is normaal. Nog beter is het om de tijd van uw eigen build, uw eigen traagste query of uw eigen paginarendering te meten. Een build die op de ene host 4 minuten duurt en op een andere 7 minuten, beantwoordt de vraag, ongeacht wat Geekbench aangaf. Dit is ook de meting die laat zien wanneer een krachtigere machine de extra kosten niet meer rechtvaardigt. Dat is nuttig om te weten voordat u leest wat een VPS per maand daadwerkelijk kost of de workload naar een dedicated server verplaatst.

FAQ

Waarom krijg ik elke keer dat ik de benchmark uitvoer een ander resultaat?

Een VPS deelt fysieke CPU, opslag en netwerk met andere tenants. Uw resultaat hangt daarom af van wat zij op dat moment doen. Voer tijdens de test vmstat 1 uit en lees de kolom st: aanhoudende steal time boven 5 betekent dat de host zwaar werd belast en dat uw CPU-score laag is om redenen buiten uw machine. De oplossing is een consistente methode, niet tuning. Voer elke test vijf keer of vaker uit op verschillende tijdstippen en rapporteer vervolgens de mediaan samen met de spreiding.

Waarom rapporteert fio miljoenen IOPS?

Vrijwel altijd omdat --direct=1 ontbreekt. Zonder deze optie leest fio via de page cache van de kernel. Na de eerste doorgang wordt een testbestand van 2G daardoor vanuit RAM geleverd en meet u de geheugenbandbreedte. Voeg --direct=1 toe en houd het testbestand groter dan elke cache in het pad. Als --direct=1 vervolgens mislukt met err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1, voer dan df -hT . uit: een Type van overlay ondersteunt O_DIRECT niet. Richt de test daarom op echte opslag.

Is yabs.sh op zichzelf voldoende?

Voor een eerste indruk wel. Het voert fio uit met vier block sizes, iperf3 in beide richtingen en Geekbench. Ook geeft het één samenvatting die anderen kunnen lezen. Het is niet meer voldoende wanneer u wilt weten waarom een getal is zoals het is, omdat u de flags niet per test kunt aanpassen. Zodra een resultaat van yabs er onjuist uitziet, reproduceert u het rechtstreeks met fio of sysbench en wijzigt u telkens één flag.

Welk afzonderlijk getal voorspelt hoe mijn applicatie zal aanvoelen?

Voor de meeste web- en databaseworkloads zijn single-core CPU-snelheid en 4k random read-latency het belangrijkst, in die volgorde. Throughputcijfers zien er indrukwekkend uit, maar zijn zelden doorslaggevend, omdat een typische request klein is. Vermeld het 99e percentiel uit het fio-blok clat percentiles in plaats van het gemiddelde. Het ene trage request op honderd is namelijk wat een gebruiker merkt.

Moet ik iets installeren voordat ik benchmarks uitvoer?

fio, sysbench en iperf3 staan allemaal in de Ubuntu- en Debian-archieven: sudo apt install -y fio sysbench iperf3. yabs.sh heeft alleen curl nodig, omdat het statische binaries downloadt voor alles wat ontbreekt. Verwijder alle testbestanden wanneer u klaar bent. Een achtergelaten fio-bestand van 2G op een schijf van 20G leidt weken later tot een melding dat de schijf van iemand vol is.