Anda meluncurkan sebuah endpoint. Endpoint tersebut berfungsi di peramban Anda. Tetapi Anda tidak tahu apa yang terjadi ketika 400 orang mengaksesnya secara bersamaan. Apakah latensi tetap stabil, atau apakah persentil kesembilan puluh sembilan melonjak? Bisakah sistem menangani 1.000 permintaan per detik, ataukah akan tumbang pada 300?
wrk menjawab pertanyaan itu. Ini adalah alat baris perintah kecil yang menembakkan banyak lalu lintas HTTP ke sebuah URL dan melaporkan seberapa cepat server merespons di bawah beban tersebut.
Apa itu wrk dan Kapan Menggunakannya
wrk adalah alat pembandingan HTTP modern. Ini menghasilkan beban dari satu mesin multi-inti dan mengukur latensi serta tingkat permintaan yang dikembalikan server. wrk menggunakan multithreading ditambah *event loop* yang skalabel (epoll di Linux, kqueue di macOS), sehingga satu instans dapat mendorong banyak lalu lintas tanpa memerlukan banyak mesin beban.
Gunakan wrk ketika Anda menginginkan angka kinerja mentah:
- Berapa banyak permintaan per detik yang dapat dipertahankan oleh endpoint ini?
- Bagaimana tampilan latensi pada median dibandingkan dengan tail?
- Apakah server bertahan selama jendela yang berkelanjutan, ataukah kinerjanya menurun setelah satu menit?
wrk adalah alat pembandingan, bukan *test suite*. Ini mengukur kecepatan. Ini tidak memeriksa apakah badan JSON benar, bahwa kode status adalah 200, atau bahwa kontrak API terpenuhi. Ingatlah perbedaan itu. Kita akan membahasnya lagi menjelang akhir, karena itu mengubah cara Anda memasukkan wrk ke dalam alur kerja pengujian yang sebenarnya. Jika Anda ingin gambaran yang lebih luas terlebih dahulu, panduan pengujian beban API ini mencakup konsep-konsep yang diterapkan wrk.
Menginstal wrk
macOS
Homebrew memiliki biner yang sudah jadi, yang merupakan cara termudah:
brew install wrk
Pada Apple Silicon, ini penting. Membuat dari sumber dapat mengalami masalah LuaJIT ARM64, jadi biner Homebrew menyelamatkan Anda dari masalah itu.
Linux (build dari sumber)
Tidak ada paket apt resmi, jadi Anda harus membuatnya. Instal toolchain dan header OpenSSL terlebih dahulu:
sudo apt-get install build-essential libssl-dev git -y
Kemudian klon dan kompilasi:
git clone https://github.com/wg/wrk.git
cd wrk
make
Itu akan menghasilkan biner wrk di direktori saat ini. Pindahkan ke PATH Anda sehingga Anda dapat memanggilnya dari mana saja:
sudo cp wrk /usr/local/bin
Konfirmasikan bahwa itu berjalan:
wrk --version
Perintah Dasar
Berikut adalah bentuk setiap eksekusi wrk:
wrk -t12 -c400 -d30s http://127.0.0.1:8080/index.html
Empat hal sedang terjadi. Mari kita bedah flag-nya.
-t, --threadsmengatur jumlah thread OS yang dibuat wrk. Titik awal yang baik adalah satu thread per inti CPU. Di sini adalah 12.-c, --connectionsmengatur total koneksi HTTP yang tetap terbuka di semua thread. Di sini 400 koneksi tersebar di 12 thread. Koneksi adalah cara Anda menyimulasikan klien bersamaan.-d, --durationmengatur berapa lama pengujian berjalan. Menerima nilai seperti30s,2m, atau2h. Di sini adalah 30 detik.
Dua flag lagi yang akan sering Anda gunakan:
--latencymencetak rincian persentil latensi yang detail. Nyalakan ini hampir setiap kali. Rata-rata menyembunyikan latensi tail, dan tail biasanya yang menyakitkan pengguna.--timeoutmencatat permintaan sebagai timeout jika tidak ada respons yang tiba dalam jendela yang Anda tetapkan, misalnya--timeout 2s. Tanpa itu, respons yang lambat dapat menggeser angka latensi Anda.
Eksekusi yang akan sering Anda gunakan terlihat seperti ini:
wrk -t8 -c200 -d30s --latency http://localhost:3000/api/users
Delapan thread, 200 koneksi, 30 detik, dengan distribusi latensi penuh dicetak di akhir.
Membaca Output
wrk mencetak laporan ringkas. Berikut adalah eksekusi nyata terhadap layanan kecil:
Running 5s test @ http://10.135.232.163:3000
2 threads and 5 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 3.82ms 2.64ms 26.68ms 85.81%
Req/Sec 550.90 202.40 0.98k 68.00%
5494 requests in 5.01s, 1.05MB read
Requests/sec: 1096.54
Transfer/sec: 215.24KB
Bacalah dari bawah ke atas, karena dua baris terakhir adalah intinya.
Requests/sec adalah *throughput*: berapa banyak permintaan yang diselesaikan server per detik secara rata-rata. Di sini adalah 1.096. Ini adalah angka yang Anda bandingkan di antara eksekusi dan di antara perubahan kode.
Transfer/sec adalah *bandwidth*: berapa banyak data yang berpindah per detik. Berguna ketika *payload* besar atau Anda mencurigai Anda dibatasi *bandwidth* daripada dibatasi CPU.
Sekarang tabel Thread Stats, yang menjelaskan distribusi, bukan hanya rata-rata:
- Baris Latency: latensi rata-rata adalah 3,82ms, tetapi standar deviasi adalah 2,64ms dan maksimum melonjak hingga 26,68ms. Maksimum yang tinggi relatif terhadap rata-rata adalah sebuah sinyal. Beberapa permintaan lambat meskipun sebagian besar cepat.
- Baris Req/Sec: tingkat permintaan per thread, lagi-lagi dengan sebarannya.
Kolom +/- Stdev memberitahu Anda berapa persentase sampel yang termasuk dalam satu standar deviasi. Persentase yang lebih rendah berarti sebaran yang lebih luas, kurang dapat diprediksi.
Baris 5494 requests in 5.01s mengkonfirmasi total volume yang sebenarnya didorong oleh eksekusi.
Ketika Anda menambahkan --latency, wrk mencetak blok persentil sehingga Anda dapat melihat *tail* secara langsung:
Latency Distribution
50% 3.21ms
75% 4.86ms
90% 7.09ms
99% 14.13ms
Persentil ke-99 adalah angka yang harus diperhatikan. Jika 99% permintaan selesai dalam 14ms tetapi rata-rata Anda adalah 3,82ms, satu dari seratus pengguna menunggu jauh lebih lama dari yang disarankan rata-rata. Rata-rata berbohong tentang *tail*. Persentil tidak.
Mengirim Permintaan POST dan Header Kustom dengan Skrip Lua
Secara default wrk mengirimkan permintaan GET. Untuk mengirim POST, menambahkan *body*, atau mengatur *header* kustom, Anda meneruskan skrip Lua dengan -s.
Buat file bernama post.lua:
wrk.method = "POST"
wrk.body = '{"name": "Ada", "role": "engineer"}'
wrk.headers["Content-Type"] = "application/json"
Tiga bidang melakukan pekerjaan itu. wrk.method mengatur kata kerja HTTP. wrk.body mengatur badan permintaan. wrk.headers adalah tabel di mana setiap kunci adalah nama header.
Jalankan dengan menunjuk -s ke skrip:
wrk -t4 -c100 -d30s -s post.lua --latency http://localhost:3000/api/users
Untuk POST *form-encoded* alih-alih JSON, repositori wrk menyediakan contoh persis ini:
wrk.method = "POST"
wrk.body = "foo=bar&baz=quux"
wrk.headers["Content-Type"] = "application/x-www-form-urlencoded"
Anda juga dapat mengatur *header* dengan flag -H untuk kasus yang lebih sederhana, tanpa skrip:
wrk -t4 -c100 -d30s -H "Authorization: Bearer TOKEN123" --latency http://localhost:3000/api/protected
Gunakan -H untuk satu atau dua *header*. Gunakan skrip Lua ketika Anda membutuhkan *body*, metode non-GET, atau logika per permintaan.
Batas: wrk Tidak Memeriksa Kebenaran
Inilah bagian yang sering terlewatkan orang. wrk memberi tahu Anda seberapa cepat server merespons. wrk tidak memberi tahu Anda apakah jawabannya benar.
Arahkan wrk ke sebuah *endpoint* yang mengembalikan HTTP 500 pada setiap permintaan, dan Anda akan mendapatkan laporan yang terlihat bersih dengan angka *requests-per-second* yang tinggi. wrk menghitung pertukaran HTTP yang selesai. Ini tidak menegaskan kode status, memvalidasi badan respons terhadap skema, atau mengkonfirmasi bahwa API melakukan apa yang seharusnya dilakukan. Kesalahan bahkan bisa terlihat cepat, karena server yang menolak permintaan lebih awal melakukan lebih sedikit pekerjaan per permintaan.
Jadi wrk menjawab "apakah cukup cepat di bawah beban?" Itu tidak bisa menjawab "apakah benar?" Kedua pertanyaan itu penting, dan mereka membutuhkan alat yang berbeda. Angka beban pada *endpoint* yang rusak adalah angka yang tidak boleh Anda percayai. Inilah tepatnya mengapa tim memasangkan alat *benchmarking* dengan *test suite* fungsional. Yang satu membuktikan kecepatan. Yang lain membuktikan perilaku.
Di Mana Apidog dan Pengujian Fungsional Cocok
Alur kerja yang bersih memiliki dua lapisan, dijalankan secara berurutan.
Pertama, validasi perilaku. Sebelum Anda peduli seberapa cepat sebuah *endpoint*, konfirmasikan bahwa itu benar. Di Apidog Anda membangun skenario pengujian yang mengirim permintaan nyata dan menegaskan apa yang kembali: kode status, bidang JSON, skema respons, dan logika bisnis. Anda dapat merangkai permintaan, meneruskan data antar langkah, dan menjalankan skenario yang sama di berbagai lingkungan. Ini adalah lapisan yang menangkap 500 yang rusak yang dengan senang hati di-*benchmark* oleh wrk.
Kemudian, *benchmark* *throughput*. Setelah perilaku diverifikasi, jalankan wrk terhadap *endpoint* yang sama untuk melihat bagaimana mereka bertahan di bawah konkurensi dan beban berkelanjutan. Apidog juga memiliki pengujian kinerja bawaan jika Anda lebih suka menyimpan pekerjaan fungsional dan beban di satu tempat, tetapi wrk adalah alat khusus yang bagus untuk *benchmarking* baris perintah mentah.
Lapisan fungsional berjalan di CI, tidak hanya di laptop Anda. CLI Apidog bersifat *headless*, jadi ia dapat masuk ke langkah *pipeline* mana pun yang dapat menjalankan Node. Instal:
npm install -g apidog-cli
Kemudian jalankan skenario atau *suite* pengujian yang disimpan berdasarkan ID:
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-t <scenarioOrSuiteId> \
-e <environmentId> \
-r cli,html,junit
-t adalah ID skenario, folder, atau *suite* yang akan dijalankan. -e adalah ID lingkungan. -r memilih format laporan, satu atau lebih dari cli, html, json, dan junit. Output JUnit terhubung langsung ke sebagian besar sistem CI untuk *pass/fail gating*. Untuk eksekusi berbasis data, tambahkan -d (atau --iteration-data) dengan jalur file atau ID data pengujian untuk mengulang skenario yang sama di banyak baris masukan.
CLI menjalankan skenario dan *suite* Apidog yang disimpan. Ini *headless*, bukan pengirim permintaan interaktif, dan ini bukan generator beban. Ini adalah gerbang kebenaran. wrk adalah pengukur kecepatan. Jalankan gerbang kebenaran di *pipeline* Anda (lihat panduan *walkthrough* CLI CI/CD ini atau panduan GitHub Actions untuk konfigurasi *copy-paste*), lalu *benchmark* dengan wrk ketika Anda membutuhkan angka *throughput*. Referensi CLI lengkap mencakup sisa *flag*.
FAQ
Apa perbedaan antara wrk dan ab (ApacheBench)? Keduanya menembakkan beban HTTP dan melaporkan permintaan per detik. wrk *multithreaded* dan menggunakan *event loop*, sehingga menghasilkan lebih banyak beban dari satu mesin dan menangani konkurensi tinggi dengan lebih baik. ab adalah *single-threaded*. Untuk beban berat dari satu mesin, wrk biasanya lebih skalabel. Keduanya tidak memeriksa kebenaran respons.
Berapa banyak *thread* dan koneksi yang harus saya gunakan? Mulailah dengan satu *thread* per inti CPU, dan atur koneksi ke tingkat konkurensi yang ingin Anda simulasikan. Jika Anda memiliki 8 inti dan ingin memodelkan 200 klien bersamaan, coba -t8 -c200. Perhatikan mesin klien. Jika wrk sendiri dibatasi CPU, angka Anda mencerminkan batas generator beban, bukan server. Tingkatkan koneksi hingga *throughput* berhenti meningkat.
Bisakah wrk menguji *endpoint* HTTPS? Ya. Arahkan ke URL https:// dan wrk akan menangani TLS. Itulah mengapa *build* Linux membutuhkan libssl-dev. *Handshake* TLS menambahkan biaya CPU di kedua ujungnya, jadi harapkan *throughput* mentah yang lebih rendah untuk HTTPS daripada HTTP biasa.
Apakah wrk memvalidasi badan respons atau kode status? Tidak. wrk menghitung pertukaran HTTP yang selesai dan mengukur waktu. wrk tidak menegaskan kode status atau badan, sehingga *endpoint* yang mengembalikan kesalahan masih dapat mencatat angka permintaan per detik yang tinggi. Gunakan *test suite* fungsional, seperti yang dijalankan melalui Apidog CLI, untuk memverifikasi kebenaran, lalu gunakan wrk untuk *throughput*.
Berapa lama seharusnya uji beban berjalan? Cukup lama untuk melewati efek *warm-up* seperti *cache* dingin dan kompilasi JIT. Beberapa detik cukup untuk pemeriksaan cepat, tetapi 30 detik hingga beberapa menit memberikan angka yang lebih stabil dan menunjukkan degradasi yang hanya muncul di bawah beban berkelanjutan. Gunakan -d30s sebagai default yang masuk akal dan perpanjang ketika Anda mencari kebocoran yang lambat.