Bir HTTP uç noktası yazdınız. Postman'den bir kez eriştiğinizde çalışıyor. Peki ya 200 istemci aynı anda erişirse ne olur? Sayılara ihtiyacınız var: saniyedeki istek sayısı, gecikme yüzdelikleri ve 2xx olmayan durumla dönen yanıt sayısı. autocannon, bu sayıları terminalinizden yaklaşık on saniye içinde size sunar.
autocannon, Node.js ile yazılmış bir HTTP/1.1 performans test aracıdır. Bir URL'ye kontrollü bir istek seli gönderir ve işlem hacmi ile gecikmeyi raporlar. Bu kılavuz size kurulumu, temel bir çalıştırmayı, gerçekte kullanacağınız her bayrağı, çıktıyı okumayı ve autocannon'u bir Node betiğinden yönetmeyi anlatır. Ayrıca, bir yük testinin size ne söylediği ve ne söylemediği arasında net bir ayrım yapar, böylece ne zaman bunun yerine bir fonksiyonel ve sözleşme testi kullanmanız gerektiğini bilirsiniz.
autocannon Nedir
autocannon, bir URL'ye sabit sayıda eşzamanlı bağlantı açar ve belirli bir süre boyunca (veya belirli bir istek sayısına ulaşana kadar) istek göndermeye devam eder. Çalışırken, gecikmeleri örnekler ve yanıtları sayar. Tamamlandığında, gecikme yüzdeliklerini gösteren bir tablo ve toplam istekler ile okunan baytların bir özetini yazdırır.
Tek bir şeyi ölçer: sunucunuzun ne kadar yükü kaldırabildiğini ve bu yük altında ne kadar hızlı yanıt verdiğini. Yanıt gövdesinin doğru olup olmadığını, API'nizin OpenAPI spesifikasyonuna uyup uymadığını veya çok adımlı bir iş akışının her adımda doğru veriyi döndürüp döndürmediğini kontrol etmez. Bu ayrımı aklınızda bulundurun. Bu, autocannon'ın test yığınınızda nerede konumlandığını şekillendirir ve bu konu sona doğru ele alınmıştır.
Eğer wrk veya Apache Bench kullandıysanız, autocannon aynı boşluğu Node-yerel bir kurulum ve JavaScript'ten çağırabileceğiniz programatik bir API ile doldurur.
Kurulum
autocannon bir npm paketi olarak gelir. autocannon komutuna her yerden erişmek için global olarak kurun:
npm i autocannon -g
Önce Node.js'nin kurulu olması gerekir. Eğer global olarak kurmak istemiyorsanız, isteğe bağlı olarak npx ile çalıştırın:
npx autocannon http://localhost:3000
Veya betik yazmayı planladığınızda bir projeye geliştirme bağımlılığı olarak ekleyin:
npm i autocannon --save-dev
Kurulumu doğrulayın:
autocannon --version
Temel Çalıştırma
En basit hali, komut ve bir URL'dir. Bu, varsayılan performans testini çalıştırır: 10 saniye boyunca 10 bağlantı.
autocannon http://localhost:3000
Sürekli kullanacağınız üç bayrak ile ayarları değiştirin. -c eşzamanlı bağlantı sayısını, -d süreyi saniye cinsinden ve -p pipeline'ı (her bağlantının bir yanıt beklemeye başlamadan önce kaç istek göndereceğini) ayarlar.
autocannon -c 100 -d 30 -p 10 http://localhost:3000
Bu komut 100 bağlantı açar, 30 saniye boyunca çalışır ve bağlantı başına 10 isteği pipeline eder. Daha yüksek bağlantı ve pipeline sayıları daha fazla yük gönderir, bu da gecikmenin artmaya başladığı noktayı nasıl bulacağınızdır.
Belirli bir süre çalıştırmak yerine sabit sayıda istek göndermek için -a (miktar) kullanın:
autocannon -c 10 -a 10000 http://localhost:3000
Bu, zamandan bağımsız olarak 10.000 istekten sonra durur.
POST İstekleri, Başlıklar ve Bir Gövde
Yöntemi -m ile değiştirin, başlıkları -H ile ekleyin ve istek gövdesini -b ile iletin. İşte bir JSON uç noktasına POST isteği:
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
Başlık biçimine dikkat edin: -H 'Anahtar=Değer', ve her başlık için -H'yi tekrarlarsınız. Eğer gövdeniz büyükse veya bir dosyada bulunuyorsa, doğrudan satır içine yazmak yerine diskten okumak için -i kullanın:
autocannon -m POST -H 'Content-Type=application/json' -i payload.json http://localhost:3000/api/users
Testi Hız Sınırlandırma
Varsayılan olarak autocannon olabildiğince hızlı gönderir. Bazen maksimum basınçlı bir sel yerine sabit, gerçekçi bir hız istersiniz. -R tüm bağlantılarda saniyedeki toplam istekleri sınırlar:
autocannon -c 50 -R 500 -d 60 http://localhost:3000
Bu, testi 60 saniye boyunca saniyede 500 istekte tutar. Bu, kırılma noktasında değil, beklenen üretim yükünde gecikmeyi ölçmek istediğinizde kullanışlıdır.
Isınma ve Çalışan İş Parçacıkları
Daha yoğun çalıştırmalarda iki bayrak daha yardımcı olur. -W (ısınma), autocannon örneklemeye başlamadan önce kısa bir süre trafik gönderir, böylece ilk sayılarınız soğuk önbellekler veya ısınmamış bir JIT tarafından çarpıtılmaz. -w (işçiler), yükü birden fazla Node çalışan iş parçacığına dağıtır; bu, tek bir iş parçacığının hızlı bir sunucuyu doyuracak kadar istek üretemediği durumlarda önemlidir:
autocannon -c 200 -d 30 -w 4 http://localhost:3000
-w'ye yalnızca yük üretecinin kendisinin darboğaz olduğunu onayladığınızda başvurun. Eğer -c'yi artırdıkça gecikme şüpheli derecede sabit görünüyorsa, üreteciniz maksimuma ulaşmış olabilir ve çalışanlar eklemek sunucunun tavanı hakkında size daha doğru bir resim verir.
Sonuçları Okuma
Bir çalıştırma bittiğinde, autocannon bir gecikme tablosu ve bir özet satırı yazdırır. Kırpılmış bir örnek:
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
İşte nasıl okunacağı:
- Yüzdelik sütunlar (2.5%, 50%, 97.5%, 99%) ortalamadan daha önemlidir. %50 sütunu medyanı gösterir. %99 sütunu, en yavaş %1'lik kullanıcılarınızın gördüğü gecikmeyi belirtir. Kuyruk gecikmesi, gerçek sorunların saklandığı yerdir, bu nedenle %97.5 ve %99 sayılarını izleyin.
- Ortalama (Avg) ve Standart Sapma (Stdev) size ortalamayı ve gecikmelerin ne kadar yaygın olduğunu verir. Yüksek bir standart sapma, tutarsız yanıt süreleri anlamına gelir.
- Özet satırı ("10.05 saniyede 251 bin istek"), işlem hacminizdir. Saniyedeki istekleri bulmak için istekleri saniyeye bölün.
İki bayrak çıktıyı daha kullanışlı hale getirir. Gecikme yüzdeliklerinin tam setini (p99.9 ve ötesi dahil) yazdırmak için -l ekleyin ve iyi bir işlem hacmi sayısının arkasına gizlenen 500'lük bir dalgayı yakalamak için durum koduna göre bir döküm görmek için --renderStatusCodes ekleyin:
autocannon -c 100 -d 20 -l --renderStatusCodes http://localhost:3000
Hataları, zaman aşımlarını ve 2xx olmayan sayıları izleyin. Bir sunucu, yüksek bir istek hızı sunarken sessizce hatalar döndürebilir. Eğer 2xx olmayan sayı sıfır değilse, işlem hacmi sayınız başarıyı değil, hataları ölçüyor demektir.
Bir Betikte Programatik Kullanım
autocannon bir Node.js API'si sunar, böylece bir betikten performans testleri çalıştırabilir ve sonuçlara göre hareket edebilirsiniz. Otomasyonda işte bu yüzden değerlidir: bir test çalıştırın, sayıları okuyun ve gecikme bir eşiği aşarsa derlemeyi başarısız sayın.
Çekirdek çağrı bir seçenek nesnesi alır ve bir promise döndürür:
const autocannon = require('autocannon')
async function run() {
const result = await autocannon({
url: 'http://localhost:3000',
connections: 100,
duration: 20,
pipelining: 1
})
console.log(`Ortalama gecikme: ${result.latency.average} ms`)
console.log(`İstek/sn: ${result.requests.average}`)
console.log(`2xx Olmayan: ${result.non2xx}`)
}
run()
result nesnesi, latency, requests ve throughput için histogramlar taşır; her biri average, min, max ve p99 gibi yüzdelik alanlara sahiptir. Ayrıca errors, timeouts ve non2xx sayılarını da taşır.
Bunu bir geçide dönüştürmek için, bir bütçe aşıldığında sıfırdan farklı bir değerle çıkan bir kontrol ekleyin:
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 gecikmesi: ${p99} ms (bütçe ${P99_BUDGET_MS} ms)`)
if (p99 > P99_BUDGET_MS || result.non2xx > 0) {
console.error('Performans bütçesi aşıldı')
process.exit(1)
}
}
run()
Eğer CLI'nin gösterdiği canlı ilerleme çubuğunu ve sonuç tablosunu istiyorsanız, örneği autocannon.track'e iletin:
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())
Çoklu istek senaryosu için, her bağlantının birden fazla çağrı arasında döngü yapması için bir requests dizisi iletin:
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 ve ab
Her üçü de aynı soruyu yanıtlar (ne kadar hızlı, ne kadar yük altında) ve doğru seçim teknoloji yığınınıza bağlıdır.
- Apache Bench (ab) klasik tek ikili araçtır. Her yerde bulunur ve basittir, ancak tek iş parçacıklıdır ve eskidir.
- wrk hızlıdır ve özel istekler için Lua betikleme ile ağır yükleri yönetebilir. Derlenmiş bir C aracıdır, bu yüzden npm dışında kurarsınız.
- autocannon çoğu iş yükü için işlem hacmi konusunda wrk ile eşleşir ve eğer zaten Node ortamında çalışıyorsanız ergonomi açısından kazanır: kurmak için
npm i, betik yazmak için bir JavaScript API'si ve kutudan çıkar çıkmaz pipelining, HAR dosyaları ve istek başına senaryolar için destek.
Eğer çalışma zamanınız Node ise, autocannon düşük sürtünmeli bir seçimdir. Python araçlarını mı tercih ediyorsunuz? Python olmadan yük testi nasıl yapılır bölümüne bakın. Geniş özellik setine sahip betiklenebilir bir seçenek mi istiyorsunuz? k6 yük testini karşılaştırın.
Fonksiyonel Test ve Apidog Nereye Uyar
autocannon, uç noktanızın saniyede 12.000 istek sunduğunu, p99 gecikmesinin ise 40 ms olduğunu söyler. Ancak uç noktanın doğru veriyi döndürüp döndürmediğini söylemez. Bir yük testi, API hatalı JSON döndürürken, bir yetkilendirme başlığını göz ardı ederken veya OpenAPI sözleşmesinden saparken başarıyla geçebilir. İşlem hacmi doğruluk değildir.
İşte fonksiyonel ve sözleşme testlerinin doldurduğu boşluk burasıdır ve Apidog bir yük aracını değiştirmek yerine tamamladığı yer burasıdır. Apidog bir yük üreteci değildir. Durum kodları, yanıt şemaları ve çok adımlı akışlar arasındaki değerler üzerinde doğrulama yapan kaydedilmiş test senaryolarını çalıştırır, böylece bir performans testinin göremediği hataları yakalarsınız.
Her ikisini de CI'da çalıştırırsınız ve farklı soruları yanıtlarlar. "Yük altında yeterince hızlı mı?" sorusunu yanıtlamak için autocannon (veya wrk) kullanın. "Doğru mu?" sorusunu yanıtlamak için Apidog CLI'yı kullanın. Apidog CLI başsızdır ve Node kurulu olan herhangi bir CI adımından kaydedilmiş test senaryolarını veya süitlerini çalıştırır:
npm install -g apidog-cli
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-t <senaryoVeyaSüitId> \
-e <ortamId> \
-r cli,html,junit
-t bayrağı bir kimliğe göre kaydedilmiş bir senaryoyu, klasörü veya süiti hedefler, -e ortamı seçer ve -r bir veya daha fazla raporlayıcıyı (cli, html, json, junit) seçer, böylece çalıştırma hattınızın arşivleyebileceği yapıtlar üretir. Tam bir adım adım kılavuz için, Apidog CLI'dan API testleri nasıl çalıştırılır, kopyala-yapıştır CI/CD hattı ve GitHub Actions iş akışı bölümlerine bakın.
Sağlıklı bir işlem hattı, her itmede fonksiyonel ve sözleşme kontrolleri yapar (çalışıyor mu?), ardından yayından önce bir yük testi yapar (dayanıyor mu?). autocannon ikinci soruyu, Apidog ise ilk soruyu yanıtlar.
Sıkça Sorulan Sorular
autocannon üretim yük testleri için doğru mudur?
autocannon, HTTP/1.1 uç noktaları için güvenilir işlem hacmi ve gecikme sayıları üretir ve -R ile hedef bir hız belirlediğinizde, birçok basit aracın atladığı eşgüdümlü ihmali düzeltir. Doğru sonuçlar için, sunucunuza yakın bir makineden çalıştırın (aksi takdirde ağ gecikmesi baskın gelir) ve uç noktayı doyuracak kadar bağlantı kullanın. Üretimi yansıtan bir hazırlık ortamına karşı çalıştırın, dizüstü bilgisayarınızın geliştirme sunucusuna karşı değil.
autocannon HTTP/2 veya WebSockets'i destekliyor mu?
Hayır. autocannon HTTP/1.1'i test eder. HTTP/2 veya WebSocket yük testleri için farklı bir araca ihtiyacınız var. Bu, onu seçmeden önce kontrol etmeniz gereken ana kısıtlamadır.
Kaç bağlantı kullanmalıyım?
Varsayılan 10 ile başlayın, ardından saniyedeki istekler artmayı durdurup gecikme yükselmeye başlayana kadar -c'yi artırın. Bu dönüm noktası kabaca sunucunuzun kapasitesidir. Bunun çok ötesine geçmek, sunucunuzun sınırlarından çok yük üretecinizin sınırlarını ölçer.
autocannon'ı CI'da çalıştırabilir miyim?
Evet. Programatik API bunun için yapılmıştır: bir performans testi çalıştırın, result.latency.p99 ve result.non2xx'i okuyun ve bir bütçe aşıldığında process.exit(1) çağırın. Bu, bir performans testini, Node özellikli herhangi bir CI adımına bağlayabileceğiniz bir geçiş/kalma kapısına dönüştürür.
-a ve -d arasındaki fark nedir?
-d belirli bir saniye boyunca çalışır. -a belirli sayıda istek tamamlanana kadar çalışır, sonra durur. Sabit durumlu bir yük testi için -d'yi ve tam bir istek sayısı göndermek istediğinizde -a'yı kullanın.