Cara Benchmark VPS dengan Benar: yabs.sh, fio, dan iperf3

Makna benchmark VPS

Untuk melakukan benchmark VPS, ukur empat hal: seberapa cepat satu inti CPU berjalan, seberapa besar bandwidth memori yang dimiliki mesin, berapa banyak operasi disk acak berukuran kecil yang dapat dilayani storage setiap detik, dan berapa throughput yang dapat diberikan oleh koneksi jaringan. Satu kali menjalankan yabs.sh memberikan hasil CPU, disk, dan jaringan dalam waktu sekitar sepuluh menit; gunakan pengujian memori terpisah di bawah ini untuk mengukur bandwidth memori. Membaca hasilnya lebih sulit karena VPS (virtual private server) berbagi perangkat keras fisik dengan tenant lain. Karena itu, mesin yang sama dapat melaporkan satu angka pada 03:00 dan angka yang sangat berbeda pada 20:00.

Rencana ini adalah menjalankan yabs.sh untuk memperoleh gambaran cepat, lalu menjalankan alat-alat di baliknya secara manual. Menjalankannya sendiri memungkinkan Anda mengubah satu flag, memantau perubahan angka, dan memahami apa yang sebenarnya diukur oleh angka tersebut. Lakukan ini setelah mesin selesai disiapkan, bukan sebelumnya. Langkah-langkah dalam sepuluh menit pertama pada VPS baru harus dilakukan terlebih dahulu karena mesin yang masih menerapkan rangkaian pembaruan pertamanya akan menghasilkan benchmark yang buruk karena alasan yang tidak berkaitan dengan perangkat keras.

Periksa mesin sebelum mengukurnya

Setengah dari setiap benchmark yang buruk disebabkan oleh mesin yang tidak dipahami oleh penulisnya.

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

Hypervisor vendor: KVM berarti virtualisasi penuh, sehingga Anda menjalankan kernel sendiri. systemd-detect-virt yang menampilkan lxc atau openvz berarti virtualisasi berbasis container: Anda berbagi kernel host, sedangkan batas CPU dan memori Anda merupakan pengaturan cgroup (control group), bukan perangkat keras virtual. Pada sistem cgroup v2, Anda dapat membaca batas CPU dari cgroup container; path berikut berlaku jika cgroup tersebut di-mount pada /sys/fs/cgroup.

cat /sys/fs/cgroup/cpu.max

max 100000 berarti cgroup ini tidak memiliki kuota sendiri; cgroup leluhur masih dapat memberlakukan kuota. 200000 100000 berarti Anda dapat menggunakan CPU selama 200000 mikrodetik dalam setiap periode 100000 mikrodetik, yang setara dengan kuota dua core. Paket yang diiklankan sebagai 4 vCPU dengan kuota dua core tidak akan pernah mencapai skor seperti empat core. Tool benchmark dapat mengidentifikasi pembatasan ini: VoxelBench melaporkan kuota CPU dan menandai CPU sebagai shared atau throttled jika host mengekspos jauh lebih banyak CPU daripada yang dapat digunakan server.

df -hT / penting karena alasan yang berbeda: kolom Type. Jika nilainya overlay, Anda berada di dalam container, dan hasil disk Anda akan menggambarkan media penyimpanan apa pun yang berada di bawah overlay tersebut. Catat sekarang.

Pantau steal time sepanjang pengujian

Steal time adalah persentase waktu CPU virtual Anda menunggu tanpa bisa menghindar ketika hypervisor tidak menjadwalkannya. Nilai ini berguna untuk menunjukkan bahwa waktu CPU tidak tersedia, tetapi tidak dapat membedakan tetangga yang sedang sibuk dari provider yang menerapkan kuota CPU Anda.

vmstat 1 10

Baca kolom st di sebelah kanan. Steal time yang terus-menerus berarti waktu CPU tidak tersedia bagi guest, tetapi nilai di atas 5% tidak membuktikan bahwa host mengalami oversubscription. Provider dapat dengan sengaja menampilkan penerapan kuota CPU sebagai steal time. top menampilkan angka yang sama seperti %st pada baris CPU. Biarkan vmstat 1 tetap berjalan dalam sesi SSH kedua saat Anda melakukan benchmark, lalu catat nilai steal di samping setiap hasil.

Mulai dengan yabs.sh

yabs.sh (Yet Another Bench Script) adalah skrip shell yang menjalankan fio, iperf3, dan Geekbench, lalu menampilkan satu ringkasan. Skrip ini menggunakan fio dan iperf3 jika keduanya sudah terpasang, serta mengunduh binary statis jika belum terpasang. Skrip ini umum digunakan dalam diskusi benchmark VPS, sehingga output yabs merupakan cara tercepat untuk membandingkan hasil dengan pengguna lain.

Format satu baris resmi dari proyek ini adalah sebagai berikut.

curl -sL yabs.sh | bash

Perintah tersebut meneruskan apa pun yang disediakan URL saat itu langsung ke shell. Unduh, baca, lalu jalankan isinya.

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

Letakkan flag setelah -s -- ketika menggunakan pipe, atau langsung setelah nama file ketika menjalankan salinan lokal. Flag yang berguna: -f melewati pengujian disk, -i melewati pengujian jaringan, -g melewati Geekbench, -r membatasi lokasi iperf3 menjadi tiga, -j menampilkan hasil dalam format JSON, dan -w results.json menulis JSON tersebut ke file.

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

Ada dua hal yang perlu diketahui sebelum menjalankan skrip untuk pertama kali. Geekbench mengunggah hasil Anda dan menampilkan URL publik browser.geekbench.com, sehingga siapa pun yang memiliki tautan tersebut dapat melihat model CPU dan skor Anda. -g melewati pengujian tersebut sepenuhnya. Kedua, tahap iperf3 mengirimkan trafik nyata ke server di beberapa wilayah, dan penggunaan ini diperhitungkan dalam kuota bandwidth bulanan Anda. Pada koneksi 1 Gbit/s, satu tahap jaringan penuh dapat memindahkan puluhan gigabyte, jadi gunakan -r jika kuota Anda kecil dan -i jika koneksi Anda menggunakan tarif berdasarkan pemakaian.

Makna setiap bagian output yabs

Bagian disk menjalankan fio dengan campuran pembacaan dan penulisan 50/50 pada empat ukuran blok: 4k, 64k, 512k, dan 1m. Bagian ini melaporkan IOPS (operasi input/output per detik) dan bandwidth untuk setiap ukuran. Baris 4k penting untuk database, mail server, atau beban kerja yang melakukan banyak penulisan kecil, karena sebagian besar IO server berukuran kecil dan tersebar. Baris 1m digunakan untuk backup dan video, ketika Anda memindahkan rangkaian byte yang panjang.

Bagian network menjalankan iperf3 terhadap server publik di beberapa region, dalam kedua arah, menggunakan stream paralel. Perlakukan angka yang rendah sebagai pertanyaan, bukan kesimpulan, karena server iperf3 publik digunakan bersama dan sering mengalami saturasi. Hasil yang buruk dapat disebabkan oleh sisi tujuan.

Bagian Geekbench memberikan skor single core dan multi core. Single core memperkirakan seberapa cepat satu request, satu proses compile, atau satu query selesai. Multi core terutama menunjukkan berapa banyak core yang benar-benar Anda dapatkan.

Disk: jalankan fio sendiri

fio (flexible IO tester) adalah alat yang digunakan pada bagian disk yabs. Menjalankannya secara langsung membuat fungsi setiap flag lebih jelas.

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

Pengujian pembacaan acak 4k dengan queue depth 32 pada filesystem yang benar-benar ingin Anda ukur:

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

Baris ringkasan yang perlu dibaca dari output terlihat seperti ini.

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

Di bawahnya, fio mencetak blok clat percentiles. Persentil ke-99.00 adalah angka yang layak dicantumkan karena menunjukkan waktu tunggu permintaan paling lambat dari setiap seratus permintaan. Latensi rata-rata menyembunyikan perlambatan yang justru dirasakan pengguna.

• --direct=1 membuka file dengan O_DIRECT, sehingga pembacaan melewati page cache kernel. Tanpa flag ini, proses kedua pada file 2G di mesin dengan RAM 8G akan dilayani dari memori, dan fio melaporkan IOPS dalam jutaan. Angka itu nyata, tetapi menunjukkan kinerja memori.
• --ioengine=libaio mengirimkan permintaan asinkron. Hal ini memungkinkan --iodepth=32 mempertahankan 32 permintaan secara bersamaan. Dengan engine sinkron seperti psync, iodepth di atas 1 tidak berpengaruh sama sekali. Pengukuran hanya mencakup satu permintaan pada satu waktu.
• --time_based --runtime=60 menjalankan pengujian selama 60 detik tetap, bukan berdasarkan jumlah pekerjaan tetap. Dengan demikian, disk cepat dan disk lambat menggunakan durasi pengujian yang sama, sehingga perbandingannya tetap adil.
• --size=2G menetapkan ukuran file pengujian. Gunakan ukuran yang lebih besar daripada cache apa pun pada jalur tersebut, dan pastikan ruang kosong tersedia terlebih dahulu.

Penulisan acak menggunakan perintah yang sama dengan --rw=randwrite. Jalankan secara terpisah, lalu hapus file tersebut.

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

Untuk campuran yang lebih mendekati trafik nyata, gunakan --rw=randrw --rwmixread=70. Kelas storage yang digunakan memengaruhi hasil ini lebih besar daripada flag apa pun. Perbedaan tersebut dibahas dalam perbedaan antara storage SSD NVMe dan SATA pada VPS.

Saat fio berhenti dengan Unknown error -1

Direct IO tidak tersedia pada semua filesystem. Karena itu, ketika fio gagal pada request pertamanya dengan --direct=1 yang ditetapkan, hal pertama yang perlu disingkirkan adalah direct IO. Kegagalannya dapat terlihat seperti berikut:

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

Jalankan df -hT . terlebih dahulu. Type berupa overlay, yaitu filesystem yang secara default diberikan Docker kepada container, bukan penyebabnya. overlayfs meneruskan O_DIRECT ke filesystem di bawahnya dan hanya menolaknya jika filesystem tersebut tidak mendukung direct IO. Karena itu, --direct=1 --ioengine=libaio berfungsi pada overlay yang berada di atas ext4 atau xfs. Jika filesystem di bawah file pengujian memang tidak mendukung direct IO, fio biasanya menyatakannya saat membuka file: fio: looks like your file system does not support direct=1/buffered=0. Dalam kasus tersebut, arahkan --filename ke path pada penyimpanan lokal yang sebenarnya, misalnya volume yang di-bind mount, atau jalankan fio pada host, bukan di dalam container. Jika penyimpanan sebenarnya tidak dapat diakses, jalankan pengujian buffered synchronous. Setidaknya, cara ini membuktikan bahwa perintahnya sendiri sudah benar.

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

Jelaskan hasil pengujian tersebut secara tepat. Setelah pass pertama, file berukuran 256M berada di page cache. Karena itu, angka IOPS menggambarkan RAM Anda. Gunakan pengujian ini untuk memastikan fio telah terpasang dan flag dapat diproses. Jangan pernah menyajikannya sebagai hasil pengujian disk.

Mengapa dd bukan alat benchmark disk

dd sering muncul dalam banyak diskusi VPS, dan perintah ini hanya menjawab satu pertanyaan yang spesifik.

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

Perintah tersebut mengukur throughput penulisan sekuensial dengan satu thread dan satu request yang sedang diproses. Ini merupakan pemeriksaan kewajaran yang cukup baik. Perintah ini tidak memberikan informasi tentang IO acak atau tentang perilaku sistem saat 32 request masuk secara bersamaan. Jika oflag=direct dihapus, penulisan akan melalui page cache, tetapi conv=fdatasync tetap memaksa data keluaran ditulis ke storage sebelum perintah selesai. Jika opsi tersebut juga dihapus, hasilnya sebagian besar dapat mengukur seberapa cepat kernel menerima penulisan ke memori. Karena itu, angka dd yang dikutip dalam posting forum sering kali tidak masuk akal.

CPU: sysbench cpu

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

Angka yang perlu diperhatikan adalah events per second. Jalankan pengujian single-thread terlebih dahulu. Angka ini menentukan seberapa cepat satu permintaan PHP selesai atau satu tugas kompilasi tuntas, dan paling banyak berbeda antara host dengan harga yang sama. Kemudian jalankan pengujian dengan seluruh thread. Hasilnya menunjukkan bagaimana throughput meningkat pada vCPU yang dialokasikan.

Pahami hal yang diukur: sysbench cpu berulang kali mencari bilangan prima melalui pembagian percobaan. Untuk setiap kandidat, program ini menghitung akar kuadrat presisi ganda, lalu menguji pembagi menggunakan operasi modulo bilangan bulat 64 bit dan membandingkan setiap pembagi dengan batas floating point tersebut. Jadi, pengujian ini memadukan operasi bilangan bulat dan floating point. Pengujian ini tidak membebani bandwidth memori, unit vektor, atau cache dengan cara yang menyerupai beban kerja nyata. Karena itu, pengujian ini baik untuk membandingkan dua host, tetapi kurang baik untuk memprediksi kinerja aplikasi Anda.

Ubuntu 24.04 menyertakan sysbench 1.0.20, yang menempatkan nama pengujian di awal. Jika Anda menyalin perintah dengan --test=cpu dari artikel lama, hasilnya adalah WARNING: the --test option is deprecated. Skor dari sysbench 0.4 dan sysbench 1.0 sama sekali tidak dapat dibandingkan. Karena itu, jangan pernah membandingkan hasil Anda dengan angka yang dipublikasikan tanpa versi.

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

Hasilnya dinyatakan dalam MiB/sec. Pertahankan --memory-block-size pada 1M, dan gunakan nilai yang sama pada setiap host yang dibandingkan. Pada 1K, angkanya turun drastis karena overhead per operasi terjadi seribu kali lebih sering. Akibatnya, yang terukur adalah biaya loop, bukan bandwidth memori. Ini adalah flag yang paling sering tidak disamakan dalam skor memori yang dipublikasikan.

Jaringan: iperf3

Cara yang tepat untuk menguji throughput adalah menggunakan mesin kedua yang Anda kendalikan, karena Anda dapat mengetahui aktivitas pada kedua ujung koneksi.

Pada mesin di sisi lain:

iperf3 -s

Perintah tersebut mendengarkan pada TCP 5201. Buka port hanya untuk alamat yang digunakan saat pengujian, lalu tutup kembali setelah selesai. Aturan dasar firewall ufw pada VPS membahas sintaksnya.

Dari VPS yang sedang diuji:

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

Perintah pertama mengukur upload dari mesin yang sedang diuji. -R membalik arah pengukuran sehingga mengukur download. -P 8 membuka delapan stream paralel.

Jalankan versi satu stream dan versi paralel, karena keduanya menjawab pertanyaan yang berbeda. Satu koneksi TCP hanya dapat menampung data yang belum menerima acknowledgment sebanyak kapasitas window-nya. Karena itu, batasnya kira-kira sebesar ukuran window dibagi round-trip time. Dengan latensi 80 ms dan window 4 MB, batas tersebut sekitar 400 Mbit/s, secepat apa pun koneksi yang mendasarinya. Angka dari satu stream menunjukkan kecepatan yang diperoleh satu proses download. Angka dari stream paralel menunjukkan kapasitas koneksi.

Pantau batas penggunaan bandwidth Anda selama pengujian. Pengujian selama 30 detik pada 1 Gbit/s memindahkan sekitar 3.75 GB, dan Anda akan menjalankannya beberapa kali pada setiap arah.

Angka referensi dan cara membaca hasil Anda

[
  {
    "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 NVMe lokal dalam hasil yang dipublikasikan biasanya mencapai sekitar 180,000 IOPS baca acak 4k. SSD SATA lokal menghasilkan sekitar 90,000. Penyimpanan blok terpasang melalui jaringan, yang setiap permintaannya melewati jaringan sebelum mencapai disk, biasanya berada di sekitar 12,000, sedangkan disk dengan piringan berputar menghasilkan sekitar 180 karena harus menggerakkan head fisik untuk setiap permintaan acak.

Angka-angka ini merupakan angka publikasi tipikal untuk setiap kelas penyimpanan, bukan hasil pengukuran dari satu host. Gunakan angka tersebut hanya untuk memeriksa apakah hasil Anda berada pada orde besaran yang tepat. Jika paket yang dipasarkan sebagai NVMe menghasilkan benchmark pada kisaran ribuan IOPS 4k, pastikan terlebih dahulu bahwa --direct=1 aktif. Jika sudah aktif, periksa batas IOPS dan kredit burst paket tersebut, serta contention pada penyimpanan dan spesifikasi hardware yang diiklankan.

Mengapa satu kali pengujian bukan benchmark

Satu hasil adalah gambaran kondisi selama satu menit pada mesin bersama. Perlakukan hasil tersebut sebagai satu sampel.

• Jalankan setiap pengujian setidaknya lima kali, pada jam yang berbeda dan setidaknya dua hari yang berbeda. Simpan nilai median dan rentangnya. Hasil yang dipublikasikan tanpa rentang adalah angka pemasaran.
• Catat steal time di samping setiap hasil pengujian. Simpan pengujian saat st bernilai tinggi dan selidiki apakah kondisi tersebut mencerminkan contention atau CPU quota dari plan; menghapusnya dapat menyembunyikan performa yang sebenarnya Anda terima.
• Jalankan pengujian disk dengan dua durasi. Banyak plan memberikan burst IOPS allowance yang terisi kembali seiring waktu, tetapi baik pengujian fio selama 60 detik maupun --runtime=600 tidak menjamin bahwa Anda telah mengukur batas terendah. Kredit AWS gp2 dapat mempertahankan 3,000 IOPS setidaknya selama 30 menit dari saldo penuh, sehingga kedua pengujian dapat mengukur burst performance. Periksa model kredit provider dan monitor credit balance sebelum menyebut suatu hasil sebagai sustained performance.
• Pastikan tidak ada proses lain yang berjalan. unattended-upgrades yang memulai transaksi apt di tengah pengujian CPU akan mengurangi skor nyata, dan ps -e -o comm= | grep -E 'apt|dpkg' sebelum setiap pengujian hanya memerlukan waktu satu detik.
• Ubah satu variabel setiap kali. Versi tool, block size, atau thread count yang berbeda menghasilkan angka yang tidak dapat dibandingkan, meskipun tampak sangat mirip.

Saat membandingkan dua provider, jalankan pengujian pada jam yang sama di hari yang sama. Jika tidak, yang Anda ukur adalah waktu dalam sehari.

Uji beban kerja Anda sendiri sebagai langkah terakhir

Alat sintetis mengurutkan performa mesin. Hanya beban kerja Anda sendiri yang menunjukkan apakah sebuah mesin sudah memadai. Ukur waktu pekerjaan yang benar-benar Anda lakukan.

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

Perintah tersebut mengompresi beberapa ratus megabita, sehingga menguji CPU dan disk secara bersamaan. Hasilnya berubah jika salah satunya berubah. Peringatan Removing leading / from member names adalah hal yang normal. Lebih baik lagi, ukur waktu build Anda sendiri, kueri Anda sendiri yang paling lambat, atau proses render halaman Anda sendiri. Jika build memerlukan waktu 4 menit pada satu host dan 7 menit pada host lain, jawabannya sudah jelas, apa pun hasil Geekbench. Pengukuran ini juga menunjukkan kapan menambah kapasitas mesin tidak lagi sebanding dengan biayanya. Hal itu perlu diketahui sebelum Anda membaca berapa biaya VPS sebenarnya per bulan atau memindahkan beban kerja ke server dedicated.

FAQ

Mengapa hasil benchmark saya berbeda setiap kali dijalankan?

VPS berbagi CPU fisik, penyimpanan, dan jaringan dengan tenant lain. Karena itu, hasil Anda bergantung pada aktivitas tenant tersebut saat pengujian berlangsung. Jalankan vmstat 1 selama pengujian dan baca kolom st: steal time berkelanjutan mencatat waktu CPU yang tidak tersedia, tetapi juga dapat mencerminkan penerapan alokasi CPU yang Anda beli oleh provider, selain kontensi pada host. Nilai di atas 5% tidak membuktikan penyebabnya. Solusinya adalah memperbaiki metode, bukan melakukan tuning. Jalankan setiap pengujian setidaknya lima kali pada jam yang berbeda, lalu laporkan median beserta rentangnya.

Mengapa fio melaporkan jutaan IOPS?

Hampir selalu karena --direct=1 tidak ada. Tanpa opsi tersebut, fio membaca melalui page cache kernel. Setelah putaran pertama, file pengujian berukuran 2G dilayani dari RAM sehingga yang diukur adalah bandwidth memori. Tambahkan --direct=1 dan gunakan file pengujian yang lebih besar daripada cache mana pun pada jalur tersebut. Jika --direct=1 kemudian gagal, jalankan df -hT . dan periksa media tempat file pengujian berada. Tipe overlay bukan masalah dengan sendirinya, karena overlayfs meneruskan O_DIRECT ke storage di bawahnya. Pindahkan file pengujian ke storage lokal sebenarnya hanya jika filesystem di bawahnya menolak direct IO.

Apakah yabs.sh cukup digunakan sendiri?

Untuk pemeriksaan awal, ya. yabs.sh menjalankan fio pada empat ukuran blok, iperf3 dalam kedua arah, dan Geekbench. Skrip ini juga menampilkan satu ringkasan yang dapat dibaca orang lain. yabs.sh tidak lagi cukup ketika Anda ingin mengetahui alasan di balik suatu angka, karena flag-nya tidak dapat diubah untuk setiap pengujian. Setelah hasil yabs terlihat tidak wajar, ulangi pengujian secara langsung dengan fio atau sysbench dan ubah satu flag setiap kali.

Angka tunggal apa yang memprediksi respons aplikasi saya?

Untuk sebagian besar workload web dan database, kecepatan CPU single-core, kemudian latensi pembacaan acak 4k. Throughput sering terlihat mengesankan, tetapi jarang menentukan hasil karena request tipikal berukuran kecil. Gunakan persentil ke-99 dari blok fio clat percentiles, bukan nilai rata-rata. Satu request yang lambat dari setiap seratus request adalah hal yang dirasakan pengguna.

Apakah saya perlu menginstal sesuatu sebelum melakukan benchmark?

fio, sysbench, dan iperf3 tersedia di archive Ubuntu dan Debian: sudo apt install -y fio sysbench iperf3. yabs.sh berjalan di Bash dan memerlukan curl atau wget untuk mengunduh, serta tar untuk mengekstrak Geekbench. Tanpa tar, skrip akan melewati Geekbench. Skrip menggunakan fio dan iperf3 jika keduanya sudah terinstal, serta mengunduh binary statis jika belum tersedia. Hapus semua file pengujian setelah selesai. File fio berukuran 2G yang tertinggal pada disk berukuran 20G dapat memicu peringatan disk penuh beberapa minggu kemudian.