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

Makna melakukan benchmark VPS

Untuk melakukan benchmark VPS, Anda mengukur empat hal: kecepatan satu inti CPU, bandwidth memori yang tersedia pada mesin, jumlah operasi disk acak berukuran kecil yang dapat dilayani storage setiap detik, serta throughput yang diberikan oleh koneksi jaringan. Satu kali menjalankan yabs.sh memberikan keempat hasil tersebut dalam waktu sekitar sepuluh menit. Bagian yang lebih sulit adalah membaca hasilnya, karena VPS (virtual private server) berbagi hardware fisik dengan tenant lain. Karena itu, mesin yang sama dapat melaporkan satu angka pada pukul 03:00 dan angka yang sangat berbeda pada pukul 20:00.

Rencananya adalah menjalankan yabs.sh untuk memperoleh gambaran singkat, lalu menjalankan tool yang digunakan di baliknya secara manual. Dengan menjalankannya sendiri, Anda dapat mengubah satu flag, memantau perubahan angkanya, 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 pembaruan tahap pertama akan menghasilkan benchmark yang buruk akibat alasan yang tidak berkaitan dengan hardware.

Periksa mesin sebelum mengukurnya

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

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. Pencetakan lxc atau openvz pada systemd-detect-virt berarti virtualisasi container: Anda berbagi kernel host, sedangkan batas CPU dan memori Anda ditetapkan oleh cgroup (control group), bukan perangkat keras virtual. Pada sistem cgroup v2, Anda dapat membaca batas CPU secara langsung.

cat /sys/fs/cgroup/cpu.max

max 100000 berarti tidak ada 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 mendapatkan skor seperti empat core, dan tidak ada alat benchmark yang menampilkan baris yang menjelaskan alasannya.

df -hT / penting karena alasan lain: kolom Type. Jika nilainya overlay, berarti Anda berada di dalam container, dan pengujian disk di bawah ini memerlukan perubahan. Catat sekarang.

Pantau steal time sepanjang pengujian

Steal time adalah persentase waktu ketika CPU virtual Anda siap dijalankan, tetapi hypervisor menyerahkan core fisik kepada pihak lain. Ini merupakan sinyal tunggal yang paling berguna untuk menentukan bahwa suatu hasil dipengaruhi oleh tetangga pada host, bukan oleh perangkat keras.

vmstat 1 10

Baca kolom st di sebelah kanan. Nilai 0 atau 1 yang stabil adalah normal. Nilai di atas 5 yang bertahan menunjukkan bahwa host mengalami oversubscription pada saat itu. Karena itu, setiap angka CPU yang Anda catat dalam rentang waktu tersebut menjadi lebih rendah bukan karena masalah pada mesin Anda. top menampilkan angka yang sama seperti %st pada baris CPU. Jalankan vmstat 1 dalam sesi SSH kedua selama 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 mengunduh biner statis fio, iperf3, dan Geekbench, menjalankannya, lalu menampilkan satu ringkasan. Skrip ini merupakan format umum dalam diskusi benchmark VPS. Karena itu, output yabs adalah cara tercepat untuk membandingkan hasil dengan orang lain.

Format satu baris dari proyek ini adalah sebagai berikut.

curl -sL yabs.sh | bash

Perintah tersebut langsung meneruskan apa pun yang saat ini disediakan URL ke shell. Unduh dan baca skripnya, lalu jalankan.

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 -- saat menggunakan pipe, atau langsung setelah nama file saat menjalankan salinan lokal. Flag yang berguna: -f melewati pengujian disk, -i melewati pengujian jaringan, -g melewati Geekbench, -r mengurangi jumlah lokasi iperf3 menjadi dua, -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 pengujian pertama. Geekbench mengunggah hasil Anda dan menampilkan URL publik browser.geekbench.com. 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. Trafik ini mengurangi kuota bandwidth bulanan Anda. Pada koneksi 1 Gbit/s, satu tahap jaringan lengkap dapat menggunakan puluhan gigabyte. Karena itu, gunakan -r jika kuota Anda kecil dan -i pada koneksi dengan penagihan berdasarkan penggunaan.

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. overlay, yaitu filesystem yang digunakan Docker untuk container secara default, serta beberapa filesystem jaringan tidak mendukung O_DIRECT. Akibatnya, libaio mengirimkan permintaan yang tidak dapat diselesaikan kernel, lalu fio berhenti:

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. Jika kolom Type berisi overlay, arahkan --filename ke path pada storage fisik, misalnya volume yang di-bind mount, atau jalankan fio pada host, bukan di dalam container. Jika storage fisik tidak dapat diakses, pengujian sinkron berbasis buffered setidaknya membuktikan bahwa perintah tersebut 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 proses pertama, file berukuran 256M berada di page cache, sehingga angka IOPS menggambarkan RAM Anda. Gunakan pengujian ini untuk memastikan fio terpasang dan flag dapat diproses. Jangan pernah menyebutnya sebagai hasil disk.

Mengapa dd bukan benchmark disk

dd sering muncul dalam banyak diskusi VPS dan 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 berurutan dengan satu thread dan satu request yang sedang diproses. Ini merupakan pemeriksaan kewajaran yang cukup baik. Perintah tersebut tidak memberikan informasi tentang IO acak atau apa yang terjadi saat 32 request tiba sekaligus. Hapus oflag=direct, dan yang diukur terutama adalah seberapa cepat kernel menerima penulisan ke dalam 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 selesai. Hasilnya juga paling bervariasi antar-host dengan harga yang sama. Kemudian jalankan pengujian dengan semua thread. Hasil ini menunjukkan apakah vCPU Anda merupakan core terpisah atau bagian dari satu core.

Pahami hal yang diukur: sysbench cpu berulang kali mencari bilangan prima menggunakan aritmetika integer 64 bit. 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. Pada versi ini, nama pengujian ditulis terlebih dahulu. 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 informasi versinya.

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

Hasilnya dinyatakan dalam MiB/sec, dan kecepatan baca lebih tinggi daripada tulis pada setiap mesin. Pertahankan --memory-block-size pada 1M, dan gunakan nilai yang sama persis pada setiap host yang dibandingkan. Pada 1K, angkanya turun drastis karena overhead per operasi terjadi seribu kali lebih sering. Akibatnya, yang diukur adalah biaya loop, bukan bandwidth memori. Flag ini paling sering tidak konsisten 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 publikasi biasanya mencapai sekitar 180,000 IOPS pembacaan acak 4k. SSD SATA lokal menghasilkan sekitar 90,000. Penyimpanan blok yang terhubung melalui jaringan, yang setiap permintaannya melewati jaringan sebelum mencapai disk, biasanya berada di sekitar 12,000, sedangkan disk berputar menghasilkan sekitar 180 karena harus menggerakkan head fisik untuk setiap permintaan acak.

Angka tersebut merupakan angka publikasi umum untuk setiap kelas penyimpanan, bukan hasil pengukuran dari satu host. Gunakan angka ini hanya untuk memeriksa apakah hasil Anda berada pada orde besaran yang tepat. Jika paket yang dipasarkan sebagai NVMe menghasilkan benchmark hanya beberapa ribu IOPS 4k, pastikan terlebih dahulu bahwa --direct=1 aktif. Jika aktif, penyimpanannya mungkin tidak sesuai dengan yang dijelaskan pada halaman produk, atau Anda berbagi penyimpanan tersebut dengan tetangga yang sangat sibuk.

Mengapa satu kali pengujian bukan benchmark

Satu hasil adalah cuplikan dari 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 median dan sebarannya. Hasil yang dipublikasikan tanpa sebaran adalah angka pemasaran.
• Catat steal time di samping setiap hasil pengujian. Buang hasil ketika st tinggi, atau setidaknya catat kondisi tersebut.
• Jalankan pengujian disk dengan dua durasi. Banyak paket memberikan alokasi burst IOPS yang terisi kembali seiring waktu, sehingga pengujian fio selama 60 detik mengukur burst, sedangkan --runtime=600 mengukur batas bawah. Batas bawah menunjukkan kinerja yang Anda dapatkan pada kondisi buruk.
• Pastikan tidak ada proses lain yang berjalan. unattended-upgrades yang memulai transaksi apt di tengah pengujian CPU akan mengurangi skor Anda secara nyata, dan ps -e -o comm= | grep -E 'apt|dpkg' sebelum setiap pengujian hanya memerlukan satu detik.
• Ubah satu variabel setiap kali. Versi tool, ukuran blok, atau jumlah thread yang berbeda menghasilkan angka yang tidak dapat dibandingkan, meskipun tampak serupa.

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 berbeda setiap kali saya menjalankannya?

VPS berbagi CPU fisik, penyimpanan, dan jaringan dengan tenant lain. Karena itu, hasil Anda bergantung pada aktivitas mereka saat itu. Jalankan vmstat 1 selama pengujian dan baca kolom st: steal time yang terus-menerus di atas 5 berarti host sedang sibuk, sehingga skor CPU Anda rendah karena faktor di luar mesin Anda. Solusinya adalah memperbaiki metode pengujian, bukan melakukan tuning. Jalankan setiap pengujian lima kali atau lebih pada jam yang berbeda. Kemudian laporkan nilai median beserta sebarannya.

Mengapa fio melaporkan jutaan IOPS?

Hampir selalu karena --direct=1 tidak ada. Tanpa opsi tersebut, fio membaca melalui page cache kernel. Setelah proses pertama, file pengujian berukuran 2G dilayani dari RAM, sehingga yang diukur adalah bandwidth memori. Tambahkan --direct=1 dan pastikan file pengujian lebih besar daripada cache apa pun di jalur tersebut. Jika --direct=1 kemudian gagal dengan err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1, jalankan df -hT .: Type dari overlay tidak mendukung O_DIRECT, jadi arahkan pengujian ke penyimpanan sebenarnya.

Apakah yabs.sh sudah cukup jika digunakan sendiri?

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

Angka tunggal mana yang dapat memprediksi pengalaman aplikasi saya?

Kecepatan CPU single-core dan latensi pembacaan acak 4k, dalam urutan tersebut, untuk sebagian besar beban kerja web dan database. Angka throughput terlihat mengesankan, tetapi jarang menentukan hasil karena permintaan yang umum berukuran kecil. Cantumkan persentil ke-99 dari blok fio clat percentiles, bukan nilai rata-rata. Satu dari setiap seratus permintaan yang lambat adalah yang dirasakan pengguna.

Apakah saya perlu menginstal sesuatu sebelum menjalankan benchmark?

fio, sysbench, dan iperf3 semuanya tersedia dalam arsip Ubuntu dan Debian: sudo apt install -y fio sysbench iperf3. yabs.sh hanya memerlukan curl, karena skrip tersebut mengunduh binary statis untuk komponen yang belum tersedia. Hapus semua file pengujian setelah selesai. File fio berukuran 2G yang tertinggal pada disk 20G dapat memicu peringatan disk penuh beberapa minggu kemudian.