Bir HTTP uç noktası yazdınız. Postman'den bir kez çağırınca çalışıyor. Peki 200 istemci aynı anda çağırırsa ne olur? Bunu tahmin etmeyin; ölçün. İhtiyacınız olan metrikler: saniyedeki istek sayısı, gecikme yüzdelikleri ve 2xx olmayan yanıt sayısı. autocannon, bu metrikleri terminalden birkaç saniye içinde üretir.
autocannon, Node.js ile yazılmış bir HTTP/1.1 performans test aracıdır. Bir URL’ye kontrollü trafik gönderir, işlem hacmini ve gecikmeyi raporlar. Bu rehberde kurulumu, temel komutları, pratik bayrakları, çıktı okumayı ve Node.js içinden otomasyon amaçlı kullanımı göreceksiniz.
autocannon Nedir?
autocannon, hedef URL’ye belirli sayıda eşzamanlı bağlantı açar ve belirlenen süre boyunca veya belirli istek sayısına ulaşana kadar istek göndermeye devam eder.
Test sonunda şunları raporlar:
- Gecikme yüzdelikleri
- Ortalama gecikme
- Maksimum gecikme
- Toplam istek sayısı
- Saniyedeki istek sayısı
- Okunan toplam veri
- Hata, timeout ve 2xx olmayan yanıt sayıları
Önemli ayrım şudur: autocannon performans ölçer, doğruluk kontrolü yapmaz.
Yani şunları söyleyebilir:
Bu endpoint saniyede 12.000 istek karşılıyor ve p99 gecikmesi 40 ms.
Ama şunları söylemez:
- Yanıt gövdesi doğru mu?
- JSON şeması beklenen yapıda mı?
- API OpenAPI sözleşmesine uyuyor mu?
- Yetkilendirme doğru çalışıyor mu?
- Çok adımlı bir akışta veri tutarlı mı?
Bu nedenle autocannon, fonksiyonel ve sözleşme testlerinin yerine geçmez; onları tamamlar.
Eğer daha önce wrk veya Apache Bench kullandıysanız, autocannon benzer ihtiyacı Node.js ekosistemine daha doğal şekilde taşır.
Kurulum
Global kurulum:
npm i autocannon -g
Kurulumu doğrulayın:
autocannon --version
Global kurmak istemiyorsanız npx ile çalıştırabilirsiniz:
npx autocannon http://localhost:3000
Bir projede script veya CI içinde kullanacaksanız geliştirme bağımlılığı olarak ekleyin:
npm i autocannon --save-dev
Temel Çalıştırma
En basit kullanım:
autocannon http://localhost:3000
Varsayılan olarak:
- 10 bağlantı açar
- 10 saniye çalışır
- Hedef URL’ye mümkün olduğunca hızlı istek gönderir
Daha gerçekçi bir test için genellikle şu üç bayrağı kullanırsınız:
autocannon -c 100 -d 30 -p 10 http://localhost:3000
Anlamları:
-
-c 100: 100 eşzamanlı bağlantı -
-d 30: 30 saniye test süresi -
-p 10: bağlantı başına 10 pipelined istek
-p, her bağlantının yanıt beklemeden önce kaç istek göndereceğini belirler. Daha yüksek bağlantı ve pipeline değerleri daha fazla yük üretir.
Belirli bir süre yerine sabit sayıda istek göndermek için -a kullanın:
autocannon -c 10 -a 10000 http://localhost:3000
Bu komut 10.000 istek tamamlanınca durur.
POST İstekleri, Başlıklar ve Gövde Gönderme
Yöntem değiştirmek için -m, başlık eklemek için -H, gövde göndermek için -b kullanılır.
Örnek JSON 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 formatı:
-H 'Key=Value'
Her başlık için -H tekrar edilir.
Gövde büyükse veya ayrı bir dosyada tutuluyorsa -i kullanın:
autocannon -m POST \
-H 'Content-Type=application/json' \
-i payload.json \
http://localhost:3000/api/users
İstek Hızını Sınırlandırma
Varsayılan davranış, hedefe mümkün olan en yüksek hızda istek göndermektir. Ancak çoğu zaman kırılma noktasını değil, üretimde beklenen sabit trafiği ölçmek istersiniz.
Bunun için -R kullanın:
autocannon -c 50 -R 500 -d 60 http://localhost:3000
Bu komut:
- 50 bağlantı açar
- 60 saniye çalışır
- Toplam istek hızını saniyede 500 istekle sınırlar
Bu yaklaşım, özellikle “normal üretim yükünde p95/p99 gecikmem ne?” sorusu için daha uygundur.
Isınma ve Worker Kullanımı
Bazı testlerde ilk saniyeler yanıltıcı olabilir. Bunun nedenleri:
- Soğuk cache
- Henüz ısınmamış JIT
- İlk bağlantı kurulum maliyetleri
- Lazy initialization yapan servisler
Isınma süresi için -W kullanabilirsiniz:
autocannon -c 100 -d 30 -W 5 http://localhost:3000
Bu örnekte autocannon, ölçüme başlamadan önce 5 saniye ısınma trafiği gönderir.
Çok hızlı endpoint’lerde yük üreten makinenin kendisi darboğaz olabilir. Bu durumda worker sayısını artırabilirsiniz:
autocannon -c 200 -d 30 -w 4 http://localhost:3000
-w bayrağını hemen kullanmayın. Önce şu belirtileri kontrol edin:
- Bağlantı sayısını artırıyorsunuz ama gecikme hiç değişmiyor
- CPU yükü istemci makinede yükseliyor
- Sunucu tarafı hala rahat görünüyor
- İstek üretici tarafında sınır oluştuğundan şüpheleniyorsunuz
Bu durumda worker kullanmak daha doğru sonuç almanıza yardımcı olur.
Sonuçları Okuma
Örnek çıktı:
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
Okurken önceliğiniz şu olmalı:
1. p99 gecikmesi
99% sütunu, en yavaş %1’lik isteklerin gördüğü gecikmeyi gösterir. Ortalama düşük olsa bile p99 yüksekse kullanıcı deneyimi kötüleşebilir.
2. p97.5 ve p99
Kuyruk gecikmeleri gerçek sorunları daha iyi gösterir. Özellikle yoğun yük altında p99 değerini takip edin.
3. Ortalama ve standart sapma
Avg, genel ortalamayı verir. Stdev yüksekse yanıt süreleri tutarsızdır.
4. Toplam istek ve süre
Özet satırı işlem hacmini gösterir:
251k requests in 10.05s
Yaklaşık RPS hesabı:
251000 / 10.05 ≈ 24975 req/s
Daha detaylı gecikme yüzdelikleri için -l ekleyin:
autocannon -c 100 -d 20 -l http://localhost:3000
Durum kodlarına göre dağılımı görmek için --renderStatusCodes kullanın:
autocannon -c 100 -d 20 -l --renderStatusCodes http://localhost:3000
Bu özellikle önemlidir. Çünkü bir servis yüksek RPS üretirken aynı anda çok sayıda 500, 401, 429 veya başka 2xx olmayan yanıt döndürüyor olabilir.
Eğer non2xx sıfır değilse, işlem hacmi sayınız başarıyı değil, hataları da içeriyor olabilir.
Node.js İçinden Programatik Kullanım
autocannon, Node.js API’si de sağlar. Bu sayede performans testini script veya CI içinde çalıştırabilirsiniz.
Basit örnek:
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 içinde şunlar bulunur:
latencyrequeststhroughputerrorstimeoutsnon2xx
Örneğin p99 gecikmesini CI kapısı olarak kullanabilirsiniz:
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`)
console.log(`Bütçe: ${P99_BUDGET_MS} ms`)
console.log(`2xx olmayan yanıt: ${result.non2xx}`)
if (p99 > P99_BUDGET_MS || result.non2xx > 0) {
console.error('Performans bütçesi aşıldı')
process.exit(1)
}
}
run()
Bu script şu durumda build’i başarısız yapar:
- p99 gecikmesi 250 ms üstüne çıkarsa
- Herhangi bir 2xx olmayan yanıt dönerse
Canlı ilerleme çubuğu ve sonuç tablosu istiyorsanız autocannon.track kullanın:
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 İstek Senaryosu
Aynı test içinde birden fazla endpoint çağırmak için requests dizisi kullanabilirsiniz:
const autocannon = require('autocannon')
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)
Bu yapı, her bağlantının verilen istekler arasında döngü yapmasını sağlar.
autocannon vs wrk vs ab
Bu üç araç aynı temel soruyu yanıtlar:
Bu servis ne kadar yük altında ne kadar hızlı yanıt veriyor?
Kısa karşılaştırma:
| Araç | Güçlü Yanı | Sınırlama |
|---|---|---|
ab |
Basit, klasik, yaygın | Eski ve tek iş parçacıklı |
wrk |
Çok hızlı, Lua ile script edilebilir | npm ekosistemi dışından kurulur |
autocannon |
Node.js ekosistemine doğal, CLI ve JS API sağlar | HTTP/1.1 ile sınırlıdır |
Node.js tabanlı bir projede çalışıyorsanız autocannon genellikle düşük sürtünmeli bir seçimdir:
npm i autocannon --save-dev
Python tabanlı araçlara alternatif arıyorsanız Python olmadan yük testi nasıl yapılır yazısına bakabilirsiniz.
Daha geniş script yetenekleri olan bir araç arıyorsanız k6 yük testi karşılaştırmasını inceleyebilirsiniz.
Fonksiyonel Test ve Apidog Nereye Uyar?
autocannon, performans sorusunu yanıtlar:
Yük altında yeterince hızlı mı?
Ancak doğruluk sorusunu yanıtlamaz:
Doğru yanıtı döndürüyor mu?
Bir endpoint şu durumda bile yük testinden geçebilir:
- Yanlış JSON döndürüyorsa
- Yetkilendirme başlığını yok sayıyorsa
- OpenAPI sözleşmesinden sapıyorsa
- Beklenen alanları eksik gönderiyorsa
- Çok adımlı akışlarda yanlış veri üretiyorsa
Bu boşluğu fonksiyonel ve sözleşme testleri doldurur. Apidog, yük üretecinin yerine geçmez; onu tamamlar.
Tipik ayrım:
-
autocannon: yük altında hız ve gecikme ölçer - Apidog: durum kodu, yanıt şeması ve akış doğruluğunu test eder
CI içinde Apidog CLI ile kayıtlı test senaryolarını çalıştırabilirsiniz:
npm install -g apidog-cli
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-t <senaryoVeyaSüitId> \
-e <ortamId> \
-r cli,html,junit
Bayraklar:
-
-t: senaryo, klasör veya süit kimliği -
-e: ortam kimliği -
-r: raporlayıcılar (cli,html,json,junit)
Daha ayrıntılı kurulum için şu rehberlere bakabilirsiniz:
Pratik bir pipeline şu şekilde ayrılabilir:
- Her push’ta Apidog ile fonksiyonel ve sözleşme testleri çalıştırın.
- Release öncesi
autocannonile yük testi çalıştırın. - p95/p99 gecikme ve 2xx olmayan yanıt sayısına göre build’i geçirin veya durdurun.
Kısaca:
- Apidog: “Doğru çalışıyor mu?”
- autocannon: “Yük altında dayanıyor mu?”
Sıkça Sorulan Sorular
autocannon üretim yük testleri için uygun mu?
Evet, HTTP/1.1 uç noktaları için işlem hacmi ve gecikme ölçmekte uygundur. Ancak doğru sonuç için testi doğru ortamda çalıştırmanız gerekir.
Dikkat edin:
- Dizüstü bilgisayardaki local geliştirme sunucusu yerine üretime benzeyen staging ortamı kullanın.
- Test istemcisini sunucuya ağ olarak yakın konumlandırın.
- Ağ gecikmesinin sonuçları domine etmediğinden emin olun.
- Hedef endpoint’i doyuracak kadar bağlantı kullanın.
-
non2xx,errorsvetimeoutsdeğerlerini mutlaka kontrol edin.
autocannon HTTP/2 veya WebSocket destekliyor mu?
Hayır. autocannon HTTP/1.1 test eder.
HTTP/2 veya WebSocket yük testleri için farklı bir araç kullanmanız gerekir.
Kaç bağlantı kullanmalıyım?
10 bağlantı ile başlayın:
autocannon -c 10 -d 30 http://localhost:3000
Sonra kademeli artırın:
autocannon -c 50 -d 30 http://localhost:3000
autocannon -c 100 -d 30 http://localhost:3000
autocannon -c 200 -d 30 http://localhost:3000
Şu noktayı arayın:
- RPS artmayı bırakıyor
- p95/p99 gecikme hızlı yükseliyor
- Hata veya timeout oluşmaya başlıyor
Bu nokta, kabaca sistem kapasitenizi gösterir.
autocannon CI içinde çalıştırılabilir mi?
Evet. Programatik API bunun için uygundur.
Örnek strateji:
-
result.latency.p99değerini okuyun -
result.non2xxdeğerini kontrol edin - Bütçe aşılırsa
process.exit(1)çağırın
Bu, performans testini CI içinde geçiş/kalma kapısına dönüştürür.
-a ve -d arasındaki fark nedir?
-d, testi belirli süre çalıştırır:
autocannon -d 30 http://localhost:3000
Bu komut 30 saniye çalışır.
-a, belirli sayıda istek tamamlanana kadar çalışır:
autocannon -a 10000 http://localhost:3000
Bu komut 10.000 istek tamamlanınca durur.
Genel kural:
- Sabit süreli yük testi için
-d - Tam istek sayısı gereken testler için
-akullanın.

Top comments (0)