Jak poprawnie wykonać benchmark VPS

Na czym polega testowanie wydajności VPS

Testowanie wydajności VPS obejmuje pomiar czterech parametrów: szybkości pojedynczego rdzenia CPU, przepustowości pamięci operacyjnej, liczby operacji wejścia/wyjścia na sekundę (IOPS) dla małych, losowych odczytów i zapisów na dysku oraz przepustowości łącza sieciowego. Jedno uruchomienie yabs.sh dostarcza wyników dla CPU, dysku i sieci w czasie około 10 minut; do pomiaru przepustowości pamięci należy użyć osobnego testu wskazanego poniżej. Interpretacja wyników jest trudniejsza, ponieważ VPS (virtual private server) współdzieli zasoby fizyczne z innymi użytkownikami, co sprawia, że ta sama maszyna może wykazywać różne wartości o godzinie 03:00 i 20:00.

Plan zakłada uruchomienie yabs.sh w celu uzyskania szybkiego przeglądu, a następnie ręczne uruchomienie poszczególnych narzędzi. Samodzielne wykonanie testów pozwala na zmianę flagi, obserwację zmiany wyniku i zrozumienie, co dany parametr faktycznie mierzy. Testy należy przeprowadzać po zakończeniu konfiguracji maszyny, a nie przed nią. Kroki opisane w pierwsze dziesięć minut na nowym VPS muszą zostać wykonane jako pierwsze, ponieważ serwer w trakcie instalacji pierwszej serii aktualizacji osiąga niskie wyniki z przyczyn niezwiązanych z wydajnością sprzętu.

Analiza maszyny przed wykonaniem pomiarów

Połowa błędnych wyników testów wydajnościowych wynika z braku zrozumienia specyfiki użytej maszyny.

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

Hypervisor vendor: KVM oznacza pełną wirtualizację, co pozwala na uruchomienie własnego jądra systemu. Wykorzystanie systemd-detect-virt, w tym lxc lub openvz, oznacza wirtualizację kontenerową: jądro systemu hosta jest współdzielone, a limity CPU i pamięci są narzucane przez ustawienia cgroup (control group), a nie przez wirtualny sprzęt. W systemach z cgroup v2 limit CPU można odczytać bezpośrednio z cgroup kontenera; poniższa ścieżka ma zastosowanie, gdy cgroup jest zamontowany w /sys/fs/cgroup.

cat /sys/fs/cgroup/cpu.max

max 100000 oznacza, że ta grupa cgroup nie posiada własnego limitu (quota); limity mogą być jednak narzucone przez grupy nadrzędne. 200000 100000 oznacza możliwość wykorzystania 200000 mikrosekund czasu procesora w każdym okresie 100000 mikrosekund, co odpowiada limitowi dwóch rdzeni. Plan oferowany jako 4 vCPU z limitem dwóch rdzeni nigdy nie osiągnie wyników czterech rdzeni. Narzędzia do benchmarków potrafią zidentyfikować to ograniczenie: VoxelBench raportuje limity CPU i oznacza współdzielone lub dławione procesory, gdy host udostępnia znacznie więcej rdzeni, niż serwer może faktycznie wykorzystać.

df -hT / jest istotne z innego powodu: ze względu na kolumnę Type. Jeśli widnieje w niej overlay, oznacza to pracę wewnątrz kontenera, a wyniki testów dyskowych będą odnosić się do pamięci masowej znajdującej się pod warstwą overlay. Należy to odnotować.

Monitorowanie steal time w czasie rzeczywistym

Steal time to udział czasu, w którym wirtualny procesor (vCPU) oczekiwał w sposób niezamierzony, ponieważ hypervisor nie przydzielił mu czasu procesora. Jest to użyteczny wskaźnik niedostępności czasu CPU, jednak nie pozwala on odróżnić obciążenia generowanego przez sąsiednie maszyny od egzekwowania limitów CPU przez dostawcę.

vmstat 1 10

Należy obserwować kolumnę st po prawej stronie. Utrzymujący się wysoki wskaźnik steal time oznacza, że czas procesora był niedostępny dla systemu gościa, jednak wartość powyżej 5% nie stanowi dowodu na to, że host jest przeciążony. Dostawcy mogą celowo prezentować egzekwowanie limitów CPU jako steal time. Wartość top wskazuje tę samą liczbę co %st w wierszu CPU. Podczas wykonywania benchmarków należy uruchomić vmstat 1 w drugiej sesji SSH i zapisywać wartość steal time obok każdego wyniku.

Rozpoczęcie pracy z yabs.sh

yabs.sh (Yet Another Bench Script) to skrypt powłoki, który uruchamia fio, iperf3 oraz Geekbench, a następnie generuje zbiorcze podsumowanie. Narzędzie korzysta z zainstalowanych w systemie wersji fio i iperf3, a w przypadku ich braku pobiera statyczne pliki binarne. Jest to standardowy język w dyskusjach na temat wydajności VPS, dlatego wynik yabs stanowi najszybszy sposób na porównanie parametrów serwera z innymi użytkownikami.

Zalecana przez autorów projektu metoda uruchomienia jednowierszowego wygląda następująco.

curl -sL yabs.sh | bash

Powyższe polecenie przesyła zawartość pobieraną z adresu URL bezpośrednio do interpretera powłoki. Zaleca się pobranie skryptu, przeanalizowanie jego treści, a następnie uruchomienie.

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

Flagi należy umieszczać po -s -- w przypadku potokowania lub bezpośrednio po nazwie pliku przy uruchamianiu lokalnej kopii. Przydatne opcje to: -f pomija test dysku, -i pomija test sieci, -g pomija test Geekbench, -r ogranicza liczbę lokalizacji iperf3 do trzech, -j wyświetla wyniki w formacie JSON, a -w results.json zapisuje ten wynik do pliku.

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

Przed pierwszym uruchomieniem należy pamiętać o dwóch kwestiach. Geekbench przesyła wynik na serwer i generuje publiczny adres URL w serwisie browser.geekbench.com, co oznacza, że każda osoba posiadająca ten link może sprawdzić model procesora oraz uzyskane wyniki. -g całkowicie pomija ten test. Po drugie, etap iperf3 generuje rzeczywisty ruch sieciowy do serwerów w różnych regionach, co jest wliczane do miesięcznego limitu transferu. Na łączu 1 Gbit/s pełny test sieci może wygenerować transfer rzędu kilkudziesięciu gigabajtów, dlatego w przypadku małych limitów należy stosować -r, a przy łączach rozliczanych za transfer -i.

Znaczenie poszczególnych sekcji wyniku yabs

Sekcja disk uruchamia fio z mieszanym odczytem i zapisem w proporcji 50/50 dla czterech rozmiarów bloku: 4k, 64k, 512k oraz 1m. Raportuje ona IOPS (operacje wejścia/wyjścia na sekundę) oraz przepustowość dla każdego z nich. Wiersz 4k jest kluczowy w przypadku baz danych, serwerów pocztowych oraz wszelkich zastosowań wymagających wielu małych operacji zapisu, ponieważ większość operacji wejścia/wyjścia na serwerze jest niewielka i rozproszona. Wiersz 1m dotyczy kopii zapasowych oraz plików wideo, gdzie przesyłane są długie ciągi bajtów.

Sekcja network uruchamia iperf3 w kierunku publicznych serwerów w różnych regionach, w obu kierunkach, przy użyciu równoległych strumieni. Niską wartość w tym teście należy traktować jako sygnał do dalszej weryfikacji, a nie jako ostateczny wynik, ponieważ publiczne serwery iperf3 są współdzielone i często przeciążone, więc słaby wynik może wynikać z ograniczeń po stronie zdalnej.

Sekcja Geekbench podaje wynik dla pojedynczego rdzenia (single core) oraz dla wielu rdzeni (multi core). Wynik single core określa szybkość wykonania pojedynczego żądania, kompilacji lub zapytania. Wynik multi core informuje głównie o rzeczywistej liczbie dostępnych rdzeni.

Dysk: samodzielne uruchomienie fio

fio (flexible IO tester) to narzędzie wykorzystywane w sekcji dyskowej yabs. Bezpośrednie korzystanie z niego pozwala na pełne wykorzystanie dostępnych flag.

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

Test losowego odczytu 4k przy głębokości kolejki 32, wykonany na wybranym systemie plików:

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

Wiersz podsumowania w wynikach wygląda następująco.

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

Poniżej fio drukuje blok clat percentiles. Wartość 99.00th percentile jest najbardziej istotna, ponieważ określa czas oczekiwania najwolniejszego z każdych stu żądań. Średnie opóźnienie maskuje zatory, które są odczuwalne dla użytkownika.

• --direct=1 otwiera plik z flagą O_DIRECT, dzięki czemu odczyty omijają pamięć podręczną stron jądra systemu. Bez tego drugie przejście przez plik 2G na maszynie z 8G pamięci RAM jest obsługiwane z pamięci, a fio raportuje miliony operacji IOPS. Wynik ten jest poprawny technicznie, ale dotyczy wydajności pamięci RAM, a nie dysku.
• --ioengine=libaio przesyła żądania asynchronicznie, co pozwala --iodepth=32 na utrzymanie 32 żądań w toku. W przypadku silnika synchronicznego, takiego jak psync, wartość iodepth powyżej 1 nie przynosi efektu, więc mierzona jest tylko jedna operacja na raz.
• --time_based --runtime=60 uruchamia test na sztywno przez 60 sekund zamiast wykonywać określoną ilość pracy. Dzięki temu szybki i wolny dysk są testowane przez ten sam czas, co zapewnia sprawiedliwe porównanie.
• --size=2G określa rozmiar pliku testowego. Należy ustawić go na wartość większą niż jakakolwiek pamięć podręczna na ścieżce zapisu i upewnić się, że na dysku jest wystarczająca ilość wolnego miejsca.

Test losowego zapisu wykonuje się tym samym poleceniem z flagą --rw=randwrite. Należy uruchomić go oddzielnie, a następnie usunąć plik testowy.

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

Aby uzyskać mieszane obciążenie zbliżone do rzeczywistego ruchu, należy użyć --rw=randrw --rwmixread=70. Klasa nośnika danych wpływa na wyniki znacznie bardziej niż jakakolwiek flaga, a podział ten został omówiony w różnice między pamięcią NVMe a SATA SSD na VPS.

Gdy fio kończy działanie z błędem Unknown error -1

Direct IO nie jest dostępne w każdym systemie plików, więc gdy fio kończy pracę przy pierwszym żądaniu z ustawioną flagą --direct=1, należy w pierwszej kolejności wykluczyć Direct IO. Błąd może wyglądać następująco:

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

W pierwszej kolejności uruchom df -hT .. Sam Type systemu overlay, który Docker domyślnie przydziela kontenerom, nie jest przyczyną problemu. overlayfs przekazuje O_DIRECT do systemu plików znajdującego się poniżej i odrzuca je tylko wtedy, gdy ten system plików nie obsługuje Direct IO, dlatego --direct=1 --ioengine=libaio działa na overlay umieszczonym na ext4 lub xfs. Gdy system plików pod plikiem testowym faktycznie nie obsługuje Direct IO, fio zazwyczaj informuje o tym podczas otwierania pliku: fio: looks like your file system does not support direct=1/buffered=0. W takim przypadku należy wskazać --filename ścieżkę do rzeczywistej pamięci masowej, na przykład wolumen typu bind mount, lub uruchomić fio na hoście zamiast w kontenerze. Jeśli dostęp do rzeczywistej pamięci masowej jest niemożliwy, uruchomienie z buforowaniem synchronicznym przynajmniej potwierdzi poprawność samej komendy.

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

Należy rzetelnie określać charakter takiego testu. Po pierwszym przebiegu plik 256M znajduje się w pamięci podręcznej stron (page cache), więc wynik IOPS opisuje wydajność pamięci RAM. Użyj tego testu, aby potwierdzić, że fio jest zainstalowane, a flagi są poprawnie interpretowane. Nigdy nie podawaj tego wyniku jako wydajności dysku.

Dlaczego dd nie jest narzędziem do testowania wydajności dysków

dd pojawia się w wielu wątkach dotyczących VPS i odpowiada na jedno, wąskie pytanie.

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

To polecenie mierzy sekwencyjną przepustowość zapisu przy użyciu jednego wątku i jednego żądania w kolejce. Jest to rozsądny test poprawności działania. Nie mówi on jednak nic o operacjach losowych (random IO) ani o zachowaniu systemu, gdy jednocześnie napływają 32 żądania. Usunięcie oflag=direct powoduje, że zapisy przechodzą przez pamięć podręczną strony (page cache), ale conv=fdatasync nadal wymusza zapis danych wyjściowych na nośnik przed zakończeniem działania polecenia. Usunięcie również tego parametru sprawia, że wynik może w dużej mierze mierzyć jedynie szybkość, z jaką jądro przyjmuje zapisy do pamięci RAM, dlatego wartości dd podawane na forach są często absurdalne.

CPU: sysbench cpu

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

Wartością, którą należy zachować, jest events per second. Najpierw należy wykonać test jednowątkowy. Jest to liczba decydująca o tym, jak szybko kończy się pojedyncze żądanie PHP lub zadanie kompilacji, co najbardziej różni hosty w tej samej cenie. Następnie należy uruchomić test z użyciem wszystkich wątków, co pokazuje, jak przepustowość skaluje się w ramach przydzielonych vCPU.

Należy jasno określić, co mierzy ten test: sysbench cpu wielokrotnie znajduje liczby pierwsze metodą próbnych dzieleń. Dla każdej kandydatki obliczany jest pierwiastek kwadratowy podwójnej precyzji, a następnie testowane są dzielniki za pomocą operacji modulo na 64-bitowych liczbach całkowitych, porównując każdy dzielnik z wyznaczonym limitem zmiennoprzecinkowym. Test łączy zatem operacje na liczbach całkowitych i zmiennoprzecinkowych. Nie obciąża on przepustowości pamięci, jednostek wektorowych ani pamięci podręcznej w sposób przypominający rzeczywiste obciążenie, dlatego dobrze sprawdza się przy porównywaniu dwóch hostów, ale słabo przy przewidywaniu wydajności konkretnej aplikacji.

Ubuntu 24.04 dostarcza sysbench 1.0.20, w którym nazwa testu występuje na początku. Skopiowanie polecenia z --test=cpu ze starego wpisu spowoduje otrzymanie WARNING: the --test option is deprecated. Wyniki z sysbench 0.4 oraz sysbench 1.0 nie są w żaden sposób porównywalne, dlatego nigdy nie należy odnosić własnych pomiarów do opublikowanych wartości, jeśli nie podano wersji narzędzia.

Pamięć: 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

Wynik podawany jest w MiB/s. Wartość --memory-block-size należy utrzymywać na poziomie 1M i stosować identycznie dla wszystkich porównywanych hostów. Przy 1K wynik drastycznie spada, ponieważ narzut na każdą operację jest tysiąckrotnie wyższy, co powoduje pomiar kosztu pętli zamiast przepustowości pamięci. Jest to najczęściej błędnie ustawiana flaga w publikowanych wynikach testów pamięci.

Sieć: iperf3

Rzetelnym sposobem na przetestowanie przepustowości jest użycie drugiej maszyny, którą się zarządza, ponieważ wtedy znany jest stan obu końców połączenia.

Na zdalnym końcu:

iperf3 -s

Polecenie to nasłuchuje na porcie TCP 5201. Port należy otworzyć wyłącznie dla adresu, z którego wykonywany jest test, a po zakończeniu pracy zamknąć. Podstawowe reguły zapory ufw na VPS opisuje składnię.

Z testowanego serwera 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

Pierwsze polecenie mierzy prędkość wysyłania z testowanej maszyny. Flaga -R odwraca kierunek, co pozwala zmierzyć prędkość pobierania. Flaga -P 8 otwiera osiem równoległych strumieni.

Należy uruchomić zarówno test pojedynczego strumienia, jak i wersję równoległą, ponieważ odpowiadają one na różne pytania. Jedno połączenie TCP może obsłużyć tylko tyle niepotwierdzonych danych, na ile pozwala jego okno, więc jego limit wynosi w przybliżeniu rozmiar okna podzielony przez czas podróży w obie strony (RTT). Przy opóźnieniu 80 ms i oknie 4 MB limit ten wynosi około 400 Mbit/s, niezależnie od rzeczywistej szybkości łącza. Wynik dla pojedynczego strumienia informuje o prędkości pojedynczego pobierania. Wynik równoległy wskazuje na całkowitą przepustowość łącza.

Podczas testów należy monitorować limit transferu danych. Trzydzieści sekund przy 1 Gbit/s przesyła około 3,75 GB, a testy będą wykonywane wielokrotnie w każdym kierunku.

Wartości referencyjne i sposób ich interpretacji

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

Lokalny wolumen NVMe w opublikowanych wynikach zazwyczaj osiąga wartość zbliżoną do 180,000 operacji IOPS przy losowym odczycie 4k. Lokalny dysk SATA SSD osiąga około 90,000. Sieciowa pamięć masowa typu block storage, w której każde żądanie przechodzi przez sieć przed dotarciem do dysku, oscyluje w granicach 12,000, natomiast dysk talerzowy osiąga około 180, ponieważ przy każdym losowym żądaniu musi fizycznie przemieścić głowicę.

Są to typowe, publikowane wartości dla każdej klasy pamięci masowej, a nie pomiary z jednego konkretnego hosta. Należy je wykorzystywać wyłącznie w jednym celu: weryfikacji, czy uzyskany wynik mieści się w odpowiednim rzędzie wielkości. Jeśli plan sprzedawany jako NVMe osiąga w testach wydajności zaledwie kilka tysięcy operacji IOPS 4k, najpierw należy potwierdzić, czy opcja --direct=1 była włączona. Jeśli tak, należy sprawdzić limity IOPS i kredyty burst dla danego planu, a także stopień obciążenia pamięci masowej oraz specyfikację reklamowanego sprzętu.

Dlaczego pojedyncze uruchomienie nie jest benchmarkiem

Pojedynczy wynik to migawka z jednej minuty pracy na współdzielonej maszynie. Należy go traktować jako jedną próbkę.

• Każdy test należy uruchomić co najmniej pięć razy, rozkładając je na różne godziny i co najmniej dwa różne dni. Należy zachować medianę oraz rozrzut wyników. Wynik opublikowany bez podania rozrzutu jest jedynie liczbą marketingową.
• Obok każdego uruchomienia należy rejestrować czas steal time. Wyniki, w których st było wysokie, należy zachować i zbadać, czy odzwierciedlają one rywalizację o zasoby, czy limit CPU planu; odrzucanie takich wyników może ukryć rzeczywistą wydajność, jaką otrzymuje użytkownik.
• Test dysku należy przeprowadzić w dwóch wariantach czasowych. Wiele planów oferuje pulę burst IOPS, która odnawia się w czasie, jednak ani 60-sekundowy test fio, ani --runtime=600 nie gwarantują pomiaru wydajności bazowej. Kredyty AWS gp2 mogą utrzymać 3 000 IOPS przez co najmniej 30 minut przy pełnym saldzie, więc oba testy mogą mierzyć wydajność typu burst. Należy sprawdzić model kredytowy dostawcy i monitorować saldo kredytów przed uznaniem wyniku za wydajność ciągłą.
• Należy upewnić się, że w tle nie działają inne procesy. unattended-upgrades rozpoczęcie transakcji apt w trakcie testu CPU realnie obniża wynik, a ps -e -o comm= | grep -E 'apt|dpkg' przed każdym uruchomieniem zajmuje sekundę.
• Należy zmieniać tylko jedną zmienną na raz. Różne wersje narzędzi, rozmiary bloków czy liczba wątków generują liczby, których nie można porównywać, niezależnie od tego, jak podobnie wyglądają.

Podczas porównywania dwóch dostawców testy należy uruchomić o tej samej godzinie tego samego dnia. W przeciwnym razie mierzona jest jedynie pora dnia.

Na końcu przetestuj własne obciążenie

Narzędzia syntetyczne szeregują maszyny. Tylko własne obciążenie pozwala ocenić, czy maszyna jest wystarczająca. Zmierz czas operacji, które faktycznie wykonujesz.

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

To polecenie kompresuje kilkaset megabajtów, więc obciąża jednocześnie procesor oraz dysk i reaguje na zmiany w wydajności któregokolwiek z nich. Ostrzeżenie Removing leading / from member names jest normalne. Jeszcze lepiej zmierzyć czas własnej kompilacji, najwolniejszego zapytania lub renderowania strony. Jeśli kompilacja trwa 4 minuty na jednym hoście i 7 na drugim, kwestia wydajności jest rozstrzygnięta, niezależnie od wyników Geekbench. Jest to również pomiar, który wskazuje moment, w którym dalsze zwiększanie zasobów przestaje być opłacalne. Warto o tym wiedzieć przed sprawdzeniem ile faktycznie kosztuje VPS miesięcznie lub przeniesieniem obciążenia na serwer dedykowany.

FAQ

Dlaczego za każdym razem otrzymuję inny wynik benchmarku?

VPS współdzieli fizyczny procesor, pamięć masową i sieć z innymi użytkownikami, więc wynik zależy od ich bieżącej aktywności. Uruchom vmstat 1 podczas testu i sprawdź kolumnę st: wartość steal time rejestruje czas procesora niedostępny dla instancji, co może wynikać zarówno z wymuszania limitów przez dostawcę, jak i obciążenia hosta. Wartość powyżej 5% nie wskazuje jednoznacznie przyczyny. Rozwiązaniem jest odpowiednia metodologia, a nie optymalizacja. Wykonaj każdy test co najmniej pięć razy o różnych porach dnia, a następnie podaj medianę wraz z rozrzutem wyników.

Dlaczego fio raportuje miliony IOPS?

Prawie zawsze dlatego, że brakuje parametru --direct=1. Bez niego fio odczytuje dane przez page cache jądra, więc po pierwszym przebiegu plik testowy o rozmiarze 2G jest serwowany z pamięci RAM, co oznacza pomiar przepustowości pamięci. Dodaj --direct=1 i zadbaj, aby plik testowy był większy niż jakakolwiek pamięć podręczna na ścieżce dostępu. Jeśli --direct=1 kończy się błędem, uruchom df -hT . i sprawdź, na czym znajduje się plik testowy. Typ overlay sam w sobie nie stanowi problemu, ponieważ overlayfs przekazuje O_DIRECT do warstwy bazowej. Przenieś plik testowy na rzeczywisty lokalny system plików tylko wtedy, gdy bazowy system plików odrzuca operacje direct IO.

Czy yabs.sh wystarczy do pełnej oceny?

Do wstępnej weryfikacji – tak. Narzędzie uruchamia fio dla czterech rozmiarów bloku, iperf3 w obu kierunkach oraz Geekbench, generując czytelne podsumowanie. Przestaje wystarczać, gdy zachodzi potrzeba zrozumienia przyczyn konkretnych wartości, ponieważ nie pozwala na zmianę flag dla poszczególnych testów. Jeśli wynik yabs wydaje się nieprawidłowy, należy odtworzyć go za pomocą fio lub sysbench, zmieniając parametry pojedynczo.

Która pojedyncza wartość najlepiej przewiduje wydajność aplikacji?

Dla większości obciążeń webowych i bazodanowych jest to szybkość pojedynczego rdzenia procesora oraz opóźnienie odczytu losowego 4k. Wartości przepustowości wyglądają imponująco, ale rzadko decydują o odczuwalnej wydajności, ponieważ typowe żądanie jest niewielkie. Należy kierować się 99. percentylem z bloku clat percentiles w fio, a nie wartością średnią, ponieważ to właśnie pojedyncze wolne żądania są zauważalne dla użytkownika końcowego.

Czy przed wykonaniem benchmarku muszę coś zainstalować?

fio, sysbench oraz iperf3 znajdują się w repozytoriach Ubuntu i Debian: sudo apt install -y fio sysbench iperf3. Skrypt yabs.sh działa w powłoce Bash i wymaga curl lub wget do pobierania plików, a także tar do rozpakowania Geekbench; bez tar test Geekbench zostanie pominięty. Narzędzie korzysta z zainstalowanych lokalnie fio i iperf3, a w razie ich braku pobiera statyczne pliki binarne. Po zakończeniu testów należy usunąć wszystkie pliki testowe, ponieważ plik fio o rozmiarze 2G pozostawiony na dysku 20G może po kilku tygodniach wywołać alert o braku miejsca.