Cara Benchmark VPS dengan Benar

Arti melakukan benchmark pada VPS

Untuk melakukan benchmark pada VPS, Anda mengukur empat hal: kecepatan satu inti CPU, bandwidth memori yang tersedia pada mesin, jumlah operasi disk acak berukuran kecil yang dapat dilayani oleh penyimpanan setiap detik, dan throughput yang disediakan oleh koneksi jaringan. Satu kali menjalankan yabs.sh memberi Anda keempat hasil tersebut dalam waktu sekitar sepuluh menit. Membaca hasilnya lebih sulit, karena VPS (virtual private server) berbagi perangkat keras fisik dengan tenant lain. Oleh 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 mendapatkan gambaran cepat, lalu menjalankan alat-alat yang digunakannya secara manual. Menjalankannya sendiri memungkinkan Anda mengubah satu flag, memantau perubahan angkanya, dan memahami hal 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 awal akan menghasilkan benchmark yang buruk karena alasan yang tidak berkaitan dengan perangkat keras.

Periksa mesin sebelum mengukurnya

Setengah dari setiap hasil 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. Pencetakan systemd-detect-virt lxc atau openvz berarti virtualisasi kontainer: Anda berbagi kernel host, dan batas CPU serta memori Anda ditetapkan oleh cgroup (control group), bukan oleh 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 memperoleh hasil seperti empat core, dan tidak ada alat benchmark yang mencetak baris yang menjelaskan penyebabnya.

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

Pantau steal time sepanjang waktu

Steal time adalah bagian waktu ketika CPU virtual Anda siap berjalan, tetapi hypervisor memberikan core fisik kepada pihak lain. Ini merupakan sinyal tunggal yang paling berguna untuk menentukan bahwa hasil pengukuran disebabkan 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 terus bertahan berarti host kelebihan beban pada saat itu. Karena itu, semua angka CPU yang Anda catat dalam periode tersebut akan rendah bukan karena masalah pada mesin Anda. top menampilkan angka yang sama seperti %st pada baris CPU. Jalankan vmstat 1 dalam sesi SSH kedua saat Anda melakukan benchmark, lalu catat angka 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, menjalankan semuanya, lalu mencetak satu ringkasan. Skrip ini merupakan bahasa umum dalam pembahasan 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 meneruskan apa pun yang saat ini disediakan URL langsung ke shell. Unduh skrip, baca isinya, 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 lokasi iperf3 menjadi dua, -j mencetak 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 mencetak URL publik browser.geekbench.com. Siapa pun yang memiliki tautan tersebut dapat membaca model CPU dan skor Anda. -g melewati pengujian tersebut sepenuhnya. Kedua, tahap iperf3 mengirimkan traffic jaringan nyata ke server di beberapa region. Traffic ini diperhitungkan dalam kuota bandwidth bulanan Anda. Pada koneksi 1 Gbit/s, tahap jaringan penuh dapat memindahkan puluhan gigabyte. Karena itu, gunakan -r jika kuota Anda kecil dan -i pada koneksi dengan biaya berdasarkan penggunaan.

Arti setiap bagian output yabs

Bagian disk menjalankan fio dengan campuran baca dan tulis 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, server email, atau beban kerja yang melakukan banyak penulisan kecil, karena sebagian besar IO server berukuran kecil dan tersebar. Baris 1m digunakan untuk pencadangan dan video, yang memindahkan rangkaian byte dalam jumlah besar.

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

Bagian Geekbench menampilkan skor single core dan multi core. Single core memperkirakan seberapa cepat satu permintaan, satu proses kompilasi, atau satu kueri selesai. Multi core terutama menunjukkan jumlah core yang benar-benar Anda dapatkan.

Disk: jalankan fio sendiri

fio (flexible IO tester) adalah alat yang digunakan di balik bagian disk yabs. Menjalankannya secara langsung membantu Anda memahami fungsi setiap flag.

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

Berikut pengujian pembacaan acak 4k dengan kedalaman antrean 32 pada filesystem yang benar-benar Anda perlukan:

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 100 permintaan. Latensi rata-rata menyembunyikan jeda yang justru dirasakan pengguna.

• --direct=1 membuka file dengan O_DIRECT, sehingga operasi baca melewati page cache kernel. Tanpa opsi ini, proses kedua pada file berukuran 2G di mesin dengan RAM 8G dilayani dari memori dan fio melaporkan IOPS hingga jutaan. Angka tersebut benar, tetapi merupakan angka memori.
• --ioengine=libaio mengirimkan permintaan asinkron. Dengan demikian, --iodepth=32 dapat mempertahankan 32 permintaan tetap aktif. Dengan engine sinkron seperti psync, iodepth di atas 1 tidak berpengaruh sama sekali, sehingga Anda mengukur 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 waktu nyata yang sama dan perbandingannya tetap adil.
• --size=2G menetapkan ukuran file pengujian. Pertahankan ukuran ini agar lebih besar daripada cache mana pun di 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 traffic 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 setiap filesystem. overlay, yaitu filesystem yang digunakan Docker secara default untuk container, serta beberapa filesystem jaringan tidak mendukung O_DIRECT. Akibatnya, libaio mengirimkan permintaan yang tidak dapat diselesaikan oleh 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 penyimpanan fisik, misalnya volume yang di-bind mount, atau jalankan fio pada host, bukan di dalam container. Jika penyimpanan fisik tidak dapat diakses, jalankan pengujian buffered synchronous. Setidaknya, cara ini 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

Pahami keterbatasan pengujian tersebut. Setelah pass pertama, file berukuran 256M berada di page cache, sehingga angka IOPS menggambarkan RAM Anda. Gunakan pengujian ini untuk memastikan fio terinstal dan flag dapat diuraikan. Jangan menyajikannya sebagai hasil pengujian disk.

Mengapa dd bukan tolok ukur 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 berurutan dengan satu thread dan satu permintaan yang sedang diproses. Ini merupakan pemeriksaan kewajaran yang cukup baik. Perintah tersebut tidak memberikan informasi tentang IO acak, maupun tentang yang terjadi saat 32 permintaan datang secara bersamaan. Jika oflag=direct dihapus, perintah tersebut sebagian besar hanya 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 dengan satu thread terlebih dahulu. Angka ini menentukan seberapa cepat satu permintaan PHP selesai atau satu tugas kompilasi selesai. Angka ini juga paling bervariasi antara host dengan harga yang sama. Kemudian jalankan pengujian dengan semua thread. Hasilnya 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 tepat untuk memprediksi kinerja aplikasi Anda.

Ubuntu 24.04 menyediakan sysbench 1.0.20. Pada versi ini, nama pengujian ditulis terlebih dahulu. Jika Anda menyalin perintah dengan --test=cpu dari tulisan 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 mencantumkan versinya.

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 dalam MiB/sec, dan kecepatan baca selalu lebih tinggi daripada tulis pada setiap mesin. Tetapkan --memory-block-size pada 1M, dan gunakan nilai yang sama pada setiap host yang Anda bandingkan. 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 diseragamkan dalam skor memori yang dipublikasikan.

Jaringan: iperf3

Cara yang tepat untuk menguji throughput adalah menggunakan mesin kedua yang Anda kendalikan. Dengan demikian, Anda mengetahui aktivitas di kedua ujung koneksi.

Di sisi jarak jauh:

iperf3 -s

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

Dari VPS yang 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 diuji. -R membalik arah koneksi sehingga mengukur download. -P 8 membuka delapan stream paralel.

Jalankan versi dengan satu stream dan versi paralel. Keduanya menjawab pertanyaan yang berbeda. Satu koneksi TCP hanya dapat menampung data yang belum mendapatkan acknowledgment sebanyak yang diizinkan oleh window-nya. Karena itu, batasnya kira-kira sama dengan ukuran window dibagi waktu pulang-pergi. Dengan latensi 80 ms dan window 4 MB, batas tersebut sekitar 400 Mbit/s, secepat apa pun link yang mendasarinya. Angka dari satu stream menunjukkan kecepatan yang diperoleh satu proses download. Angka dari beberapa stream menunjukkan kapasitas link.

Pantau kuota bandwidth Anda selama pengujian. Penggunaan selama 30 detik pada 1 Gbit/s memindahkan sekitar 3.75 GB, dan Anda akan menjalankan pengujian ini beberapa kali untuk 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 baca acak 4k. SSD SATA lokal biasanya mencapai sekitar 90,000. Penyimpanan blok terhubung jaringan, yang setiap permintaannya melewati jaringan sebelum mencapai disk, biasanya mendekati 12,000, sedangkan disk berputar hanya mencapai sekitar 180 karena harus menggerakkan head fisik untuk setiap permintaan acak.

Angka ini adalah angka publikasi yang umum untuk setiap kelas penyimpanan, bukan hasil pengukuran dari satu host. Gunakan angka ini hanya untuk satu tujuan: memastikan hasil Anda berada pada orde besaran yang benar. Jika paket yang dipasarkan sebagai NVMe menghasilkan benchmark hanya beberapa ribu IOPS 4k, pastikan terlebih dahulu --direct=1 aktif. Jika aktif, berarti penyimpanannya tidak sesuai dengan deskripsi di halaman produk, atau Anda berbagi penyimpanan tersebut dengan tetangga yang sangat sibuk.

Mengapa satu kali pengujian bukan tolok ukur

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

Saat membandingkan dua penyedia, jalankan pengujian pada jam yang sama di hari yang sama. Jika tidak, Anda telah mengukur waktu dalam sehari.

Uji beban kerja Anda sendiri sebagai langkah terakhir

Alat sintetik memberi peringkat pada mesin. Hanya beban kerja Anda sendiri yang menunjukkan apakah suatu mesin memadai. Ukur waktu tugas yang benar-benar Anda lakukan.

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

Perintah tersebut mengompresi beberapa ratus megabita. Dengan demikian, perintah tersebut menguji CPU dan disk secara bersamaan, dan 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 render halaman Anda sendiri. Build yang memerlukan waktu 4 menit pada satu host dan 7 menit pada host lain sudah menjawab pertanyaan tersebut, terlepas dari hasil Geekbench. Pengukuran ini juga menunjukkan kapan peningkatan mesin tidak lagi sepadan dengan biayanya. Informasi ini perlu diketahui sebelum Anda membaca biaya VPS sebenarnya per bulan atau memindahkan beban kerja ke server khusus.

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 tenant tersebut saat itu. Jalankan vmstat 1 selama pengujian dan baca kolom st. Waktu steal yang terus-menerus di atas 5 berarti host sedang sibuk, sehingga skor CPU Anda rendah karena alasan di luar mesin Anda. Solusinya adalah menggunakan metode yang konsisten, bukan melakukan tuning. Jalankan setiap pengujian lima kali atau lebih pada jam yang berbeda. Setelah itu, laporkan median beserta rentangnya.

Mengapa fio melaporkan jutaan IOPS?

Hampir selalu karena --direct=1 tidak dicantumkan. Tanpa opsi tersebut, fio membaca melalui page cache kernel. Setelah pass 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 sepanjang 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 dengan empat ukuran blok, iperf3 dalam kedua arah, dan Geekbench. Perintah tersebut juga menampilkan satu ringkasan yang dapat dibaca orang lain. yabs.sh tidak lagi cukup jika Anda ingin mengetahui alasan di balik suatu angka, karena Anda tidak dapat mengubah flag untuk setiap pengujian. Jika hasil yabs terlihat tidak benar, ulangi pengujian secara langsung dengan fio atau sysbench dan ubah satu flag setiap kali.

Angka tunggal mana yang memprediksi kinerja 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 umumnya berukuran kecil. Cantumkan persentil ke-99 dari blok clat percentiles fio, bukan rata-ratanya. Satu permintaan lambat dari setiap seratus permintaan adalah hal yang dirasakan pengguna.

Apakah saya perlu menginstal sesuatu sebelum melakukan benchmark?

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