autocannon: Pengujian Beban HTTP Node.js (Langkah demi Langkah)

Anda menulis sebuah endpoint HTTP. Ini berfungsi ketika Anda mengujinya sekali dari Postman. Namun apa yang terjadi ketika 200 klien mengaksesnya secara bersamaan? Anda membutuhkan angka-angka: permintaan per detik, persentil latensi, dan berapa banyak respons yang kembali dengan status non-2xx. autocannon memberikan Anda angka-angka tersebut dari terminal Anda dalam sekitar sepuluh detik.

autocannon adalah alat benchmark HTTP/1.1 yang ditulis dalam Node.js. Ini meluncurkan banjir permintaan terkontrol ke sebuah URL dan melaporkan throughput serta latensi. Panduan ini akan memandu Anda melalui instalasi, eksekusi dasar, setiap flag yang akan Anda gunakan, membaca output, dan menjalankan autocannon dari skrip Node. Ini juga menarik garis yang jelas antara apa yang dapat diberitahukan oleh uji beban dan apa yang tidak, sehingga Anda tahu kapan harus menggunakan uji fungsional dan kontrak sebagai gantinya.

tombol

Apa itu autocannon

autocannon membuka sejumlah koneksi bersamaan yang tetap ke sebuah URL dan terus mengirim permintaan untuk durasi yang ditentukan (atau jumlah permintaan yang ditentukan). Saat berjalan, ia mengambil sampel latensi dan menghitung respons. Setelah selesai, ia mencetak tabel persentil latensi dan ringkasan total permintaan serta byte yang dibaca.

Ini mengukur satu hal: seberapa banyak beban yang dapat ditangani server Anda dan seberapa cepat ia merespons di bawah beban tersebut. Ini tidak memeriksa apakah badan respons sudah benar, apakah API Anda cocok dengan spesifikasi OpenAPI-nya, atau apakah alur kerja multi-langkah mengembalikan data yang benar di setiap langkah. Ingatlah perbedaan ini. Ini membentuk posisi autocannon dalam tumpukan pengujian Anda, yang akan dibahas di akhir.

Jika Anda pernah menggunakan wrk atau Apache Bench, autocannon mengisi posisi yang sama dengan instalasi Node-native dan API terprogram yang dapat Anda panggil dari JavaScript.

Instalasi

autocannon dikirim sebagai paket npm. Instal secara global untuk mendapatkan perintah autocannon di mana saja:

npm i autocannon -g

Anda perlu menginstal Node.js terlebih dahulu. Jika Anda tidak ingin menginstal secara global, jalankan sesuai permintaan dengan npx:

npx autocannon http://localhost:3000

Atau tambahkan ke proyek sebagai dependensi dev ketika Anda berencana untuk membuat skripnya:

npm i autocannon --save-dev

Verifikasi instalasi:

autocannon --version

Eksekusi dasar

Bentuk paling sederhana adalah perintah ditambah URL. Ini menjalankan benchmark default: 10 koneksi selama 10 detik.

autocannon http://localhost:3000

Atur parameter dengan tiga flag yang akan sering Anda gunakan. -c mengatur jumlah koneksi bersamaan, -d mengatur durasi dalam detik, dan -p mengatur pipelining (berapa banyak permintaan yang dikirim setiap koneksi sebelum menunggu respons).

autocannon -c 100 -d 30 -p 10 http://localhost:3000

Perintah itu membuka 100 koneksi, berjalan selama 30 detik, dan memipelines 10 permintaan per koneksi. Jumlah koneksi dan pipelining yang lebih tinggi mendorong lebih banyak beban, itulah cara Anda menemukan titik di mana latensi mulai meningkat.

Untuk mengirim sejumlah permintaan tetap daripada berjalan untuk durasi, gunakan -a (jumlah):

autocannon -c 10 -a 10000 http://localhost:3000

Itu berhenti setelah 10.000 permintaan tanpa memandang waktu.

Permintaan POST, header, dan body

Ubah metode dengan -m, tambahkan header dengan -H, dan lewatkan body permintaan dengan -b. Berikut adalah contoh POST ke endpoint JSON:

autocannon -c 50 -d 20 \
  -m POST \
  -H 'Content-Type=application/json' \
  -H 'Authorization=Bearer YOUR_TOKEN' \
  -b '{"name":"load-test","active":true}' \
  http://localhost:3000/api/users

Perhatikan format header: -H 'Key=Value', dan Anda mengulang -H untuk setiap header. Jika body Anda besar atau berada dalam file, gunakan -i untuk membacanya dari disk daripada menyisipkannya langsung:

autocannon -m POST -H 'Content-Type=application/json' -i payload.json http://localhost:3000/api/users

Membatasi laju pengujian

Secara default, autocannon mengirim secepat mungkin. Terkadang Anda menginginkan laju yang stabil dan realistis daripada banjir tekanan maksimum. -R membatasi total permintaan per detik di semua koneksi:

autocannon -c 50 -R 500 -d 60 http://localhost:3000

Itu menjaga pengujian pada 500 permintaan per detik selama 60 detik. Ini berguna ketika Anda ingin mengukur latensi pada beban produksi yang diharapkan daripada pada titik puncaknya.

Pemanasan dan thread worker

Dua flag lagi membantu dalam pengujian yang lebih berat. -W (pemanasan) mengirimkan lalu lintas untuk interval singkat sebelum autocannon mulai mengambil sampel, sehingga angka-angka pertama Anda tidak bias oleh cache yang dingin atau JIT yang belum memanas. -w (pekerja) menyebarkan beban ke beberapa thread worker Node, yang penting ketika satu thread tidak dapat menghasilkan permintaan yang cukup untuk membanjiri server yang cepat:

autocannon -c 200 -d 30 -w 4 http://localhost:3000

Gunakan -w hanya ketika Anda telah mengonfirmasi bahwa generator beban itu sendiri adalah bottleneck. Jika latensi terlihat mencurigakan datar saat Anda menaikkan -c, generator Anda mungkin sudah mencapai batasnya, dan menambahkan worker memberikan gambaran yang lebih akurat tentang batas kemampuan server.

Membaca hasil

Ketika sebuah eksekusi selesai, autocannon mencetak tabel latensi dan baris ringkasan. Contoh yang dipersingkat:

Running 10s test @ http://localhost:3000
10 connections

┌─────────┬──────┬──────┬───────┬──────┬─────────┬─────────┬──────────┐
│ Stat    │ 2.5% │ 50%  │ 97.5% │ 99%  │ Avg     │ Stdev   │ Max      │
├─────────┼──────┼──────┼───────┼──────┼─────────┼─────────┼──────────┤
│ Latency │ 0 ms │ 1 ms │ 4 ms  │ 6 ms │ 1.2 ms  │ 0.9 ms  │ 24.1 ms  │
└─────────┴──────┴──────┴───────┴──────┴─────────┴─────────┴──────────┘

251k requests in 10.05s, 27.9 MB read

Berikut cara membacanya:

Kolom persentil (2.5%, 50%, 97.5%, 99%) lebih penting daripada rata-rata. Kolom 50% adalah median. Kolom 99% memberi tahu Anda latensi yang dialami oleh 1 persen pengguna Anda yang paling lambat. Latensi ekor adalah tempat masalah sebenarnya bersembunyi, jadi perhatikan angka 97.5% dan 99%.
Avg dan Stdev memberi Anda rata-rata dan seberapa tersebar latensi. Deviasi standar yang tinggi berarti waktu respons yang tidak konsisten.
Baris ringkasan ("251k permintaan dalam 10.05s") adalah throughput Anda. Bagi permintaan dengan detik untuk mendapatkan permintaan per detik.

Dua flag membuat output lebih berguna. Tambahkan -l untuk mencetak set lengkap persentil latensi (termasuk p99.9 dan seterusnya), dan tambahkan --renderStatusCodes untuk melihat rincian per-kode status sehingga Anda dapat menangkap gelombang 500-an yang tersembunyi di balik angka throughput yang baik:

autocannon -c 100 -d 20 -l --renderStatusCodes http://localhost:3000

Perhatikan jumlah error, timeout, dan non-2xx. Sebuah server dapat mencapai laju permintaan yang tinggi sambil diam-diam mengembalikan error. Jika non-2xx bukan nol, angka throughput Anda mengukur kegagalan, bukan keberhasilan.

Penggunaan secara terprogram dalam skrip

autocannon mengekspos API Node.js, sehingga Anda dapat menjalankan benchmark dari skrip dan bertindak berdasarkan hasilnya. Di sinilah ia membuktikan nilainya dalam otomatisasi: jalankan pengujian, baca angka-angka, dan gagalkan build jika latensi melampaui ambang batas.

Panggilan inti menerima objek opsi dan mengembalikan promise:

const autocannon = require('autocannon')

async function run() {
  const result = await autocannon({
    url: 'http://localhost:3000',
    connections: 100,
    duration: 20,
    pipelining: 1
  })

  console.log(`Avg latency: ${result.latency.average} ms`)
  console.log(`Req/sec: ${result.requests.average}`)
  console.log(`Non-2xx: ${result.non2xx}`)
}

run()

Objek result membawa histogram untuk latency, requests, dan throughput, masing-masing dengan average, min, max, dan bidang persentil seperti p99. Ini juga membawa jumlah errors, timeouts, dan non2xx.

Untuk mengubahnya menjadi gerbang, tambahkan pemeriksaan yang keluar dengan nilai non-nol ketika anggaran terlampaui:

const autocannon = require('autocannon')

const P99_BUDGET_MS = 250

async function run() {
  const result = await autocannon({
    url: 'http://localhost:3000/api/health',
    connections: 100,
    duration: 30
  })

  const p99 = result.latency.p99
  console.log(`p99 latency: ${p99} ms (budget ${P99_BUDGET_MS} ms)`)

  if (p99 > P99_BUDGET_MS || result.non2xx > 0) {
    console.error('Performance budget exceeded')
    process.exit(1)
  }
}

run()

Jika Anda ingin bilah kemajuan langsung dan tabel hasil yang ditampilkan oleh CLI, teruskan instans ke autocannon.track:

const autocannon = require('autocannon')

const instance = autocannon({
  url: 'http://localhost:3000',
  connections: 10,
  duration: 10
}, console.log)

autocannon.track(instance, { renderProgressBar: true })

process.once('SIGINT', () => instance.stop())

Untuk skenario multi-permintaan, teruskan array requests sehingga setiap koneksi berputar melalui beberapa panggilan:

autocannon({
  url: 'http://localhost:3000',
  connections: 20,
  duration: 15,
  requests: [
    { method: 'GET', path: '/api/users' },
    { method: 'POST', path: '/api/data', body: '{"x":1}',
      headers: { 'Content-Type': 'application/json' } }
  ]
}, console.log)

autocannon vs wrk dan ab

Ketiganya menjawab pertanyaan yang sama (seberapa cepat, di bawah berapa banyak beban), dan pilihan yang tepat tergantung pada stack Anda.

Apache Bench (ab) adalah alat biner tunggal klasik. Ini ada di mana-mana dan sederhana, tetapi berutas tunggal dan sudah ketinggalan zaman.
wrk cepat dan dapat mendorong beban berat dengan skrip Lua untuk permintaan kustom. Ini adalah alat C yang dikompilasi, jadi Anda menginstalnya di luar npm.
autocannon menyamai wrk dalam throughput untuk sebagian besar beban kerja dan unggul dalam ergonomi jika Anda sudah sering menggunakan Node: npm i untuk instalasi, API JavaScript untuk skrip, dan dukungan untuk pipelining, file HAR, serta skenario per-permintaan secara bawaan.

Jika Node adalah runtime Anda, autocannon adalah pilihan yang minim gesekan. Lebih suka alat Python? Lihat cara melakukan uji beban tanpa Python. Ingin opsi yang dapat diskrip dengan set fitur besar? Bandingkan pengujian beban k6.

Di mana pengujian fungsional dan Apidog cocok

autocannon memberi tahu Anda bahwa endpoint Anda melayani 12.000 permintaan per detik pada p99 sebesar 40 ms. Ini tidak memberi tahu Anda bahwa endpoint mengembalikan data yang benar. Uji beban dapat lulus dengan sangat baik sementara API mengembalikan JSON yang salah format, mengabaikan header otentikasi, atau menyimpang dari kontrak OpenAPI-nya. Throughput bukanlah kebenaran.

Itulah celah yang diisi oleh pengujian fungsional dan kontrak, dan di sinilah Apidog melengkapi alat beban daripada menggantikannya. Apidog bukanlah generator beban. Ini menjalankan skenario pengujian yang disimpan yang menegaskan kode status, skema respons, dan nilai di seluruh alur multi-langkah, sehingga Anda dapat menangkap bug yang tidak dapat dilihat oleh benchmark.

Anda menjalankan keduanya di CI, dan mereka menjawab pertanyaan yang berbeda. Gunakan autocannon (atau wrk) untuk menjawab “apakah cukup cepat di bawah beban?” Gunakan Apidog CLI untuk menjawab “apakah sudah benar?” Apidog CLI bersifat headless dan menjalankan skenario pengujian atau suite yang disimpan dari langkah CI mana pun yang memiliki Node:

npm install -g apidog-cli

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -t <scenarioOrSuiteId> \
  -e <environmentId> \
  -r cli,html,json,junit

Flag -t menargetkan skenario, folder, atau suite yang disimpan berdasarkan id, -e memilih lingkungan, dan -r memilih satu atau lebih reporter (cli, html, json, junit) sehingga eksekusi menghasilkan artefak yang dapat diarsipkan oleh pipeline Anda. Untuk panduan lengkap, lihat cara menjalankan uji API dari Apidog CLI, pipeline CI/CD copy-paste, dan alur kerja GitHub Actions.

Pipeline yang sehat menjalankan pemeriksaan fungsional dan kontrak pada setiap push (apakah berfungsi?), kemudian menjalankan uji beban sebelum rilis (apakah tahan?). autocannon menjawab pertanyaan kedua. Apidog menjawab pertanyaan pertama.

FAQ

Apakah autocannon akurat untuk pengujian beban produksi?

autocannon menghasilkan angka throughput dan latensi yang andal untuk endpoint HTTP/1.1, dan ketika Anda menetapkan laju target dengan -R, ia mengoreksi kelalaian terkoordinasi, langkah yang dilewatkan oleh banyak alat yang lebih sederhana. Untuk hasil yang akurat, jalankan dari mesin yang dekat dengan server Anda (latensi jaringan akan mendominasi jika tidak) dan gunakan koneksi yang cukup untuk membanjiri endpoint. Jalankan terhadap lingkungan staging yang mencerminkan produksi, bukan terhadap server pengembangan laptop Anda.

Apakah autocannon mendukung HTTP/2 atau WebSockets?

Tidak. autocannon mem-benchmark HTTP/1.1. Untuk pengujian beban HTTP/2 atau WebSocket, Anda memerlukan alat yang berbeda. Ini adalah batasan utama yang perlu diperiksa sebelum Anda memilihnya.

Berapa banyak koneksi yang harus saya gunakan?

Mulai dari default 10, lalu tingkatkan -c hingga permintaan per detik berhenti naik dan latensi mulai meningkat. Titik infleksi itu kira-kira adalah kapasitas server Anda. Mendorong jauh melampaui itu lebih mengukur batas generator beban Anda daripada batas server Anda.

Bisakah saya menjalankan autocannon di CI?

Ya. API terprogram dibangun untuk itu: jalankan benchmark, baca result.latency.p99 dan result.non2xx, dan panggil process.exit(1) ketika anggaran terlampaui. Itu mengubah benchmark menjadi gerbang lulus/gagal yang dapat Anda sambungkan ke langkah CI yang mendukung Node.

Apa perbedaan antara -a dan -d?

-d berjalan selama beberapa detik. -a berjalan hingga sejumlah permintaan selesai, lalu berhenti. Gunakan -d untuk uji beban steady-state dan -a ketika Anda ingin mengirim jumlah permintaan yang tepat.