Anda telah merilis sebuah endpoint. Ini mengembalikan JSON yang benar di Postman. Tapi Anda tidak tahu apa yang terjadi ketika 200 klien memukulnya sekaligus. Apakah ia mampu menangani 500 permintaan per detik, ataukah latensinya kacau balau pada 50? ApacheBench menjawab pertanyaan itu dalam satu perintah.
ApacheBench, yang dipanggil sebagai ab, adalah alat baris perintah yang mengirimkan sejumlah tetap permintaan HTTP ke satu URL dan melaporkan throughput serta latensi. Alat ini disertakan dengan Apache HTTP Server dan telah ada selama beberapa dekade. Ini kecil, cepat dijalankan, dan memberi Anda gambaran cepat tentang berapa banyak beban yang dapat ditangani oleh satu endpoint.
Panduan ini mencakup instalasi ab, menjalankan pengujian dasar, menguji endpoint POST, membaca output, dan mengetahui kapan ab bukan lagi alat yang tepat. Setiap perintah di sini sesuai dengan tanda (flag) yang didokumentasikan dalam referensi resmi Apache ab.
Apa itu ApacheBench dan dari mana asalnya
ab adalah klien benchmarking yang dibundel dengan Apache HTTP Server. Namanya adalah singkatan dari ApacheBench. Ia membuka koneksi ke satu URL, mengirim permintaan secepat yang diizinkan oleh pengaturan konkurensi Anda, menghitung waktu setiap respons, dan mencetak ringkasan.
Ia mengukur satu hal dengan baik: berapa banyak permintaan per detik yang dapat dilayani oleh satu endpoint, dan bagaimana waktu respons didistribusikan di bawah beban. Itu adalah throughput dan latensi untuk satu URL.
Apa yang tidak dilakukannya sama pentingnya. ab tidak memeriksa apakah badan respons sudah benar. Ia tidak memvalidasi skema atau memastikan suatu bidang. Ia tidak melakukan alur multi-langkah seperti masuk, lalu mengambil, lalu memperbarui. Ia memukul satu URL dan menghitung. Ingatlah cakupan itu dan ab akan tetap berguna. Berharap lebih dan Anda akan kecewa.
Jika Anda ingin pandangan yang lebih luas tentang disiplin tempat ab cocok, lihat apa itu pengujian beban API dan mengapa waktu respons API penting.
Menginstal ab
ab datang dalam paket utilitas Apache. Nama paket berbeda-beda tergantung platform.
Pada Debian dan Ubuntu, instal paket apache2-utils:
sudo apt-get update
sudo apt-get install -y apache2-utils
Pada CentOS, RHEL, dan Fedora, paketnya adalah httpd-tools:
# CentOS 7
sudo yum install -y httpd-tools
# Fedora and CentOS 8+
sudo dnf install -y httpd-tools
Di macOS, ab sudah ada karena sistemnya dilengkapi dengan Apache. Periksa dengan:
ab -V
Anda akan melihat baris versi seperti Version 2.3. Jika perintah tidak ada di macOS, instal melalui formula Apache Homebrew. Setelah ab -V mencetak versi, Anda siap.
Menjalankan uji beban dasar
Dua flag yang akan selalu Anda gunakan adalah -n dan -c.
-n requestsmenetapkan jumlah total permintaan yang akan dilakukan. Defaultnya adalah satu permintaan tunggal, yang tidak memberi tahu Anda apa-apa, jadi selalu atur ini.-c concurrencymenetapkan berapa banyak permintaan yang berjalan pada satu waktu. Defaultnya adalah satu, yang berarti sepenuhnya serial.
Berikut adalah 1000 permintaan, 50 sekaligus, terhadap endpoint JSON:
ab -n 1000 -c 50 https://api.example.com/v1/users
Perhatikan path di akhir. ab membutuhkan URL lengkap dengan path. Jika Anda mengarahkannya ke host kosong tanpa path, akan terjadi error. Untuk root, gunakan garis miring di akhir: https://api.example.com/.
Klien sungguhan menggunakan kembali koneksi TCP alih-alih membuka koneksi baru untuk setiap permintaan. Tambahkan -k untuk mengaktifkan HTTP KeepAlive sehingga ab menggunakan kembali koneksi dalam satu sesi:
ab -n 1000 -c 50 -k https://api.example.com/v1/users
Eksekusi dengan -k biasanya lebih mendekati perilaku browser atau klien API yang baik, karena menghindari biaya penyiapan koneksi pada setiap permintaan. Bandingkan kedua angka tersebut untuk melihat seberapa besar latensi Anda adalah overhead koneksi.
Anda juga bisa membatasi eksekusi berdasarkan waktu alih-alih jumlah. -t menetapkan jumlah detik maksimum dan secara internal menyiratkan -n 50000, sehingga pengujian berhenti pada batas mana pun yang Anda capai lebih dulu:
ab -t 30 -c 50 -k https://api.example.com/v1/users
Itu berjalan hingga 30 detik pada konkurensi 50. Berguna ketika Anda menginginkan pembacaan durasi tetap daripada hitungan tetap.
Menguji endpoint POST
Sebagian besar pekerjaan API bukanlah GET. Untuk menguji POST, letakkan badan permintaan dalam file dan teruskan dengan -p. Anda juga harus mengatur tipe konten dengan -T, atau server akan menolak badan tersebut.
Buat payload:
cat > payload.json <<'EOF'
{"name": "Ada Lovelace", "email": "ada@example.com"}
EOF
Kemudian kirimkan:
ab -n 500 -c 25 -k \
-p payload.json \
-T application/json \
https://api.example.com/v1/users
Flag -p menamai file yang berisi badan POST. Flag -T mengatur header Content-Type. Tipe konten default adalah text/plain, yang hampir tidak pernah diinginkan oleh API JSON, jadi atur -T application/json secara eksplisit.
Jika endpoint Anda memerlukan otentikasi atau header lain, tambahkan dengan -H. Ulangi flag untuk setiap header:
ab -n 500 -c 25 -k \
-p payload.json \
-T application/json \
-H "Authorization: Bearer YOUR_TOKEN" \
https://api.example.com/v1/users
Untuk penyegaran tentang membangun badan permintaan JSON secara manual, lihat cara melakukan POST data JSON dengan curl. Badan yang sama berfungsi sebagai file payload ab.
Membaca output
Sebuah eksekusi mencetak blok angka. Berikut adalah contoh yang dipersingkat:
Concurrency Level: 50
Time taken for tests: 4.212 seconds
Complete requests: 1000
Failed requests: 0
Non-2xx responses: 0
Requests per second: 237.42 [#/sec] (mean)
Time per request: 210.598 [ms] (mean)
Time per request: 4.212 [ms] (mean, across all concurrent requests)
Transfer rate: 142.31 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 5 18 9.4 16 64
Processing: 22 189 41.2 182 310
Waiting: 21 177 39.8 171 295
Total: 31 207 42.7 201 338
Percentage of the requests served within a certain time (ms)
50% 201
66% 221
75% 236
90% 268
95% 291
99% 324
100% 338 (longest request)
Baca bidang-bidang ini terlebih dahulu:
- Permintaan per detik adalah judul throughput Anda. Ini adalah jumlah permintaan dibagi dengan total waktu. Lebih tinggi lebih baik.
- Permintaan yang gagal dan respons Non-2xx memberi tahu Anda apakah server benar-benar menangani beban atau mulai mengalami error. Jumlah permintaan per detik yang tinggi tidak berarti apa-apa jika separuh responsnya adalah 500. Selalu periksa kedua hal ini sebelum Anda mempercayai angka throughput.
- Waktu per permintaan muncul dua kali. Baris pertama adalah waktu rata-rata yang ditunggu oleh satu pengguna (konkurensi dikalikan total waktu dibagi permintaan). Baris kedua, berlabel “di seluruh permintaan bersamaan,” adalah jeda rata-rata antara permintaan yang selesai. Angka pertama adalah yang dirasakan pengguna.
Tabel Persentase permintaan yang dilayani dalam waktu tertentu adalah bagian yang paling berguna. Ini adalah rincian persentil. Baris 50% adalah median Anda. Baris 95% dan 99% menunjukkan bagian paling lambat (tail). Dalam contoh, separuh permintaan selesai dalam 201ms, tetapi 1% membutuhkan waktu 324ms atau lebih. Latensi ekor adalah tempat pengguna sungguhan merasakan dampaknya, jadi perhatikan persentil ke-95 dan ke-99 lebih dari rata-rata.
Ingin angka mentah per permintaan untuk grafik? Tambahkan -e results.csv untuk menulis CSV pasangan persentil-ke-waktu, atau -g results.tsv untuk file yang ramah gnuplot.
Kapan ab bukan lagi alat yang tepat
ab sengaja dibuat sempit. Batasannya perlu dinyatakan dengan jelas agar Anda tidak menyalahgunakannya.
- Satu URL per eksekusi.
abmenyerang satu endpoint. Ia tidak bisa membuat skrip urutan seperti otentikasi, membuat sumber daya, lalu membacanya kembali. Perjalanan pengguna sesungguhnya menyentuh banyak endpoint secara berurutan, danabtidak memiliki konsep itu. - Tidak ada pemeriksaan kebenaran.
abmenghitung kode status dan panjang byte. Ia tidak mengurai JSON Anda atau memastikan bahwa suatu bidang sama dengan nilai yang diharapkan. Respons bisa salah secara struktural dan masih dihitung sebagai keberhasilan. Angka beban bukanlah pengganti untuk rangkaian pengujian yang berhasil. - Penanganan HTTP yang sudah ketinggalan zaman. Dokumen resmi menyatakan bahwa
abtidak mengimplementasikan HTTP/1.x sepenuhnya dan hanya menerima beberapa bentuk respons yang diharapkan. Ia tidak memiliki dukungan HTTP/2. Untuk server yang berperilaku berbeda di bawah HTTP/2,abtidak akan mencerminkan hal itu. - Beban satu mesin.
abberjalan dari satu mesin dan satu proses. Melewati konkurensi tertentu, Anda mengukur batasan klien Anda sendiri alih-alih server. Dokumen bahkan memperingatkan bahwa penguraianabsendiri dapat muncul sebagai bottleneck dalam profil.
Tidak ada satu pun dari ini yang membuat ab buruk. Itu menjadikannya alat yang spesifik: probe throughput cepat untuk satu endpoint. Ketika Anda membutuhkan alur skrip, beban terdistribusi, atau HTTP/2, carilah sesuatu yang dibangun untuk itu. JMeter menangani skenario multi-langkah dan eksekusi terdistribusi, dan ada rangkuman alat pengujian beban yang lebih luas jika Anda membandingkan opsi.
Di mana pengujian fungsional cocok
Throughput adalah salah satu sumbu. Kebenaran adalah yang lain, dan ab tidak menyentuhnya. Sebelum Anda menguji beban sebuah endpoint, Anda ingin tahu bahwa ia mengembalikan data yang benar dengan bentuk yang benar dalam kondisi normal. Itu adalah pengujian fungsional dan kontrak, dan itu adalah pekerjaan yang berbeda.
Di sinilah platform API lengkap mendapatkan tempatnya di samping ab. Apidog memungkinkan Anda membangun skenario pengujian dengan pernyataan visual, merangkai permintaan ke dalam alur multi-langkah, dan memvalidasi respons terhadap skema Anda, hal-hal yang tidak dapat dilakukan ab secara desain. Anda menyimpan skenario tersebut sekali dan menjalankannya di mana saja.
Untuk integrasi berkelanjutan, Apidog CLI menjalankan skenario yang Anda simpan tanpa GUI. Instal dengan Node:
npm install -g apidog-cli
Kemudian jalankan skenario atau suite yang tersimpan terhadap lingkungan yang dipilih, mengeluarkan laporan yang dapat diarsipkan CI Anda:
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-t <scenarioOrSuiteId> \
-e <environmentId> \
-r cli,html,junit
Flag -t menargetkan skenario, folder, atau suite yang disimpan berdasarkan ID. Flag -e memilih lingkungan. Flag -r memilih satu atau lebih pelapor dari cli, html, json, dan junit. Untuk eksekusi berbasis data, tambahkan -d (atau --iteration-data) dengan jalur file data atau ID data uji. CLI tidak memiliki GUI dan menjalankan skenario yang disimpan, sehingga cocok untuk setiap langkah CI yang dapat menjalankan Node. Ini bukan pengirim permintaan dan bukan generator beban, ia menjalankan pengujian fungsional yang tidak pernah dimaksudkan untuk dijalankan oleh ab.
Pengaturan yang sehat menggunakan keduanya. Jalankan skenario Apidog untuk membuktikan bahwa endpoint sudah benar. Jalankan ab untuk membuktikan bahwa ia cukup cepat. Untuk sisi kebenaran, lihat panduan pengujian kinerja Apidog dan tutorial pengujian kinerja API umum.
FAQ
Apakah ApacheBench hanya untuk server Apache?
Tidak. Meskipun namanya demikian, ab mengirimkan permintaan HTTP dan HTTPS biasa ke server mana pun. Ini bekerja melawan Nginx, Node, Go, Python, atau host mana pun yang berbicara HTTP. Keterkaitan dengan Apache hanyalah bahwa alat ini disertakan dengan Apache HTTP Server.
Konkurensi dan jumlah permintaan berapa yang harus saya gunakan?
Mulai dari rendah lalu tingkatkan. Coba -n 1000 -c 10, lalu naikkan -c ke 25, 50, 100, dan perhatikan di mana permintaan per detik berhenti meningkat dan permintaan yang gagal mulai muncul. Titik infleksi itu kira-kira adalah saat endpoint mencapai saturasi. Sesuaikan konkurensi puncak Anda dengan lalu lintas nyata yang diharapkan daripada memilih angka bulat yang besar.
Mengapa permintaan yang gagal saya tinggi padahal API berfungsi dengan baik?
ab menandai permintaan sebagai gagal jika panjang respons bervariasi antar permintaan, yang normal untuk JSON dinamis. Tambahkan flag -l untuk berhenti menghitung perbedaan panjang sebagai kegagalan. Kemudian periksa baris respons Non-2xx untuk melihat apakah ada error nyata di baliknya.
Bisakah ab menguji endpoint yang membutuhkan token login?
Ya, jika Anda sudah memiliki token. Teruskan dengan -H "Authorization: Bearer YOUR_TOKEN". Yang tidak bisa dilakukan ab adalah login terlebih dahulu untuk mendapatkan token baru, lalu menggunakannya. Itu adalah alur multi-langkah, dan Anda membutuhkan alat berbasis skenario seperti Apidog untuk itu.
Apakah ab mendukung HTTP/2?
Tidak. ab menggunakan HTTP/1.x dan, menurut dokumen resmi, bahkan tidak mengimplementasikannya sepenuhnya. Jika perilaku server Anda di bawah HTTP/2 penting, gunakan alat beban dengan dukungan HTTP/2 sebagai gantinya.