Bir uç nokta gönderdiniz. Postman'de doğru JSON'ı döndürüyor. Ama 200 istemci aynı anda vurduğunda ne olduğunu bilmiyorsunuz. Saniyede 500 isteği kaldırır mı, yoksa 50'de gecikme süresi mi düşer? ApacheBench, bu soruyu tek bir komutla yanıtlar.
ab olarak çağrılan ApacheBench, tek bir URL'ye sabit sayıda HTTP isteği gönderen ve verim ile gecikme süresini raporlayan bir komut satırı aracıdır. Apache HTTP Sunucusu ile birlikte gelir ve onlarca yıldır kullanılmaktadır. Küçük, hızlı çalışır ve bir uç noktanın ne kadar yüke dayanabileceği hakkında hızlı bir okuma sağlar.
Bu rehber, ab'yi kurmayı, temel bir test çalıştırmayı, POST uç noktalarını test etmeyi, çıktıyı okumayı ve ab'nin doğru araç olmaktan çıktığı noktayı bilmeyi kapsar. Buradaki her komut, resmi Apache ab referansında belgelenen bir işarete karşılık gelir.
ApacheBench nedir ve nereden gelir?
ab, Apache HTTP Sunucusu ile birlikte gelen bir kıyaslama istemcisidir. Adı, ApacheBench'in kısaltmasıdır. Tek bir URL'ye bağlantılar açar, eşzamanlılık ayarınızın izin verdiği kadar hızlı istekler gönderir, her yanıtı zamanlar ve bir özet yazdırır.

Tek bir şeyi iyi ölçer: tek bir uç noktanın saniyede kaç istek hizmet verebildiğini ve yük altında yanıt süresinin nasıl dağıldığını. Bu, tek bir URL için verim ve gecikme süresidir.
Yapmadığı şeyler de bir o kadar önemlidir. ab, yanıt gövdesinin doğru olup olmadığını kontrol etmez. Bir şemayı doğrulamaz veya bir alanı doğrulamayı iddia etmez. Oturum açma, ardından alma, ardından güncelleme gibi çok adımlı bir akışı izlemez. Tek bir URL'ye vurur ve sayar. Bu kapsamı aklınızda tutun ve ab faydalı olmaya devam edecektir. Daha fazlasını beklerseniz hayal kırıklığına uğrarsınız.
ab'nin uyduğu disipline daha geniş bir bakış açısı için, API yük testinin ne olduğunu ve API yanıt süresinin neden önemli olduğunu görün.
ab'yi kurmak
ab, Apache yardımcı programlarıyla birlikte gelir. Paket adı platforma göre farklılık gösterir.
Debian ve Ubuntu'da, apache2-utils paketini kurun:
sudo apt-get update
sudo apt-get install -y apache2-utils
CentOS, RHEL ve Fedora'da paket httpd-tools'tur:
# CentOS 7
sudo yum install -y httpd-tools
# Fedora ve CentOS 8+
sudo dnf install -y httpd-tools
macOS'te ab zaten mevcuttur çünkü sistem Apache ile birlikte gelir. Kontrol edin:
ab -V
Version 2.3 gibi bir sürüm satırı görmelisiniz. macOS'te komut eksikse, Homebrew'un Apache formülü aracılığıyla kurun. ab -V bir sürüm yazdırdığında, hazırsınız demektir.
Temel bir yük testi çalıştırma
Her zaman kullanacağınız iki işaret -n ve -c'dir.
-n istek_sayısı, gerçekleştirilecek toplam istek sayısını ayarlar. Varsayılan, hiçbir şey söylemeyen tek bir istektir, bu yüzden bunu her zaman ayarlayın.-c eşzamanlılık, aynı anda kaç isteğin çalışacağını ayarlar. Varsayılan birdir, yani tamamen seri.
İşte bir JSON uç noktasına karşı aynı anda 50 adet olmak üzere 1000 istek:
ab -n 1000 -c 50 https://api.example.com/v1/users
Sondaki yolu dikkate alın. ab, yolla birlikte tam bir URL'ye ihtiyaç duyar. Yolsuz çıplak bir ana bilgisayara işaret ederseniz hata verir. Kök için, sondaki eğik çizgiyi kullanın: https://api.example.com/.
Gerçek istemciler, her istek için yeni bir bağlantı açmak yerine TCP bağlantılarını yeniden kullanır. -k ekleyerek HTTP KeepAlive'ı etkinleştirin, böylece ab bir oturum içindeki bağlantıları yeniden kullanır:
ab -n 1000 -c 50 -k https://api.example.com/v1/users
-k ile yapılan çalışma genellikle bir tarayıcının veya iyi huylu bir API istemcisinin davranışına daha yakındır, çünkü her istekte bağlantı kurma maliyetini ödemekten kaçınır. Gecikmenizin ne kadarının bağlantı yükü olduğunu görmek için iki sayıyı karşılaştırın.
Çalışmayı sayım yerine zamanla da sınırlayabilirsiniz. -t maksimum saniye sayısını ayarlar ve dahili olarak -n 50000 anlamına gelir, böylece test ilk ulaştığınız sınırda durur:
ab -t 30 -c 50 -k https://api.example.com/v1/users
Bu, 50 eşzamanlılıkta 30 saniyeye kadar çalışır. Sabit sayıda değil, sabit süreli bir okuma istediğinizde kullanışlıdır.
Bir POST uç noktasını test etme
Çoğu API çalışması GET değildir. Bir POST'u test etmek için, istek gövdesini bir dosyaya koyun ve -p ile geçirin. Ayrıca, sunucu gövdeyi reddedeceği için içerik türünü -T ile ayarlamanız gerekir.
Payload'ı oluşturun:
cat > payload.json <<'EOF'
{"name": "Ada Lovelace", "email": "ada@example.com"}
EOF
Sonra gönderin:
ab -n 500 -c 25 -k \
-p payload.json \
-T application/json \
https://api.example.com/v1/users
-p bayrağı, POST gövdesini içeren dosyanın adını belirtir. -T bayrağı, Content-Type başlığını ayarlar. Varsayılan içerik türü text/plain'dir, ki bu bir JSON API'nin neredeyse hiçbir zaman istediği bir şey değildir, bu yüzden -T application/json'ı açıkça ayarlayın.
Uç noktanız yetkilendirme veya başka başlıklar gerektiriyorsa, bunları -H ile ekleyin. Her başlık için bayrağı tekrarlayın:
ab -n 500 -c 25 -k \
-p payload.json \
-T application/json \
-H "Authorization: Bearer YOUR_TOKEN" \
https://api.example.com/v1/users
JSON istek gövdelerini elle oluşturma konusunda bir hatırlatma için, curl ile JSON verileri nasıl POST edilir başlıklı makaleye bakın. Aynı gövde, bir ab payload dosyası olarak çalışır.
Çıktıyı okuma
Bir çalıştırma bir sayı bloğu yazdırır. İşte kesilmiş bir örnek:
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)
Önce bu alanları okuyun:
- Saniyedeki istekler, verim başlığınızdır. İstek sayısı, toplam süreye bölünür. Ne kadar yüksekse o kadar iyidir.
- Başarısız istekler ve 2xx olmayan yanıtlar, sunucunun yükü gerçekten karşılayıp karşılamadığını veya hata vermeye başlayıp başlamadığını gösterir. Yanıtların yarısı 500 hatasıysa, yüksek saniyedeki istek sayısı hiçbir şey ifade etmez. Verim rakamına güvenmeden önce her zaman bu ikisini kontrol edin.
- İstek başına süre iki kez görünür. İlk satır, tek bir kullanıcının bekleme süresinin ortalamasıdır (eşzamanlılık çarpı toplam süre bölü istekler). "Tüm eşzamanlı istekler boyunca" etiketli ikinci satır, tamamlanan istekler arasındaki ortalama boşluktur. Kullanıcıların hissettiği sayı ilk sayıdır.
Belirli bir süre içinde hizmet verilen isteklerin yüzdesi tablosu en kullanışlı kısımdır. Bu bir yüzdelik dilim dağılımıdır. %50 satırı medyanınızdır. %95 ve %99 satırları yavaş kuyruğu gösterir. Örnekte, isteklerin yarısı 201 ms'de tamamlandı, ancak %1'i 324 ms veya daha uzun sürdü. Kuyruk gecikmesi, gerçek kullanıcıların zarar gördüğü yerdir, bu yüzden ortalamadan çok %95 ve %99 yüzdelik dilimlerini izleyin.
Bir grafik için ham istek başına sayıları mı istiyorsunuz? Yüzdelik dilim-zaman çiftlerinin bir CSV'sini yazmak için -e results.csv ekleyin veya gnuplot dostu bir dosya için -g results.tsv kullanın.
ab'nin doğru araç olmaktan çıktığı yer
ab kasıtlı olarak dar kapsamlıdır. Sınırlarını açıkça belirtmek, onu yanlış kullanmamanız için önemlidir.
Her çalıştırmada bir URL. ab, tek bir uç noktaya baskı uygular. Kimlik doğrulama, kaynak oluşturma, ardından okuma gibi bir diziyi senaryolaştıramaz. Gerçek kullanıcı yolculukları sırayla birçok uç noktaya dokunur ve ab'nin bunun hakkında bir kavramı yoktur.
Doğruluk kontrolü yok. ab durum kodlarını ve bayt uzunluklarını sayar. JSON'ınızı ayrıştırmaz veya bir alanın beklenen bir değere eşit olduğunu iddia etmez. Bir yanıt yapısal olarak yanlış olabilir ve yine de başarılı sayılabilir. Yük sayıları, geçen bir test paketi yerine geçmez.
Güncel olmayan HTTP işleme. Resmi belgeler, ab'nin HTTP/1.x'i tam olarak uygulamadığını ve yalnızca bazı beklenen yanıt biçimlerini kabul ettiğini belirtir. HTTP/2 desteği yoktur. HTTP/2 altında farklı davranan sunucular için ab bunu yansıtmaz.
Tek makine yükü. ab, tek bir kutudan ve tek bir işlemden çalışır. Belirli bir eşzamanlılığın ötesinde, sunucununkini değil, kendi istemcinizin sınırlarını ölçersiniz. Belgelerde bile ab'nin kendi ayrıştırmasının profillerde bir darboğaz olarak ortaya çıkabileceği uyarısı bulunur.
Bunların hiçbiri ab'yi kötü yapmaz. Onu özel bir araç yapar: tek bir uç nokta için hızlı bir verim probu. Senaryolu akışlara, dağıtılmış yüke veya HTTP/2'ye ihtiyacınız olduğunda, bunun için oluşturulmuş bir şeye başvurun. JMeter çok adımlı senaryoları ve dağıtılmış çalıştırmaları yönetir ve seçenekleri karşılaştırıyorsanız yük testi araçlarının daha geniş bir derlemesi vardır.
Fonksiyonel testin yeri
Verim bir eksendir. Doğruluk başka bir eksendir ve ab buna dokunmaz. Bir uç noktayı yük testine tabi tutmadan önce, normal koşullar altında doğru verileri doğru şekilde döndürdüğünü bilmek istersiniz. Bu fonksiyonel ve sözleşme testidir ve farklı bir iştir.
Burası, tam bir API platformunun ab'nin yanında yerini kazandığı yerdir. Apidog, görsel iddialarla test senaryoları oluşturmanıza, istekleri çok adımlı akışlara zincirlemenize ve yanıtları şemanıza göre doğrulamanıza olanak tanır; bunlar ab'nin tasarım gereği yapamayacağı şeylerdir. Bu senaryoları bir kez kaydedersiniz ve her yerde çalıştırırsınız.
Sürekli entegrasyon için, Apidog CLI, kaydettiğiniz senaryoları başsız olarak çalıştırır. Node ile kurun:
npm install -g apidog-cli
Ardından, seçilen bir ortama karşı kaydedilmiş bir senaryoyu veya paketi çalıştırın, CI'nizin arşivleyebileceği raporlar yayınlayın:
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-t <scenarioOrSuiteId> \
-e <environmentId> \
-r cli,html,junit
-t bayrağı, kimliğine göre kaydedilmiş bir senaryoyu, klasörü veya paketi hedefler. -e bayrağı ortamı seçer. -r bayrağı, cli, html, json ve junit'ten bir veya daha fazla raporlayıcı seçer. Veri odaklı çalıştırmalar için, bir veri dosyası yolu veya test verisi kimliği ile -d (veya --iteration-data) ekleyin. CLI başsızdır ve kaydedilmiş senaryoları çalıştırır, bu nedenle Node çalıştırabilen herhangi bir CI adımına uyar. Bu bir istek gönderici veya yük oluşturucu değildir, ab'nin asla çalıştırması amaçlanmayan fonksiyonel testleri çalıştırır.
Sağlıklı bir kurulum her ikisini de kullanır. Uç noktanın doğru olduğunu kanıtlamak için Apidog senaryolarını çalıştırın. Yeterince hızlı olduğunu kanıtlamak için ab'yi çalıştırın. Doğruluk tarafı için, Apidog performans testi rehberine ve genel API performans testi eğitimine bakın.
Sıkça Sorulan Sorular
ApacheBench sadece Apache sunucuları için mi geçerlidir?
Hayır. Adına rağmen, ab herhangi bir sunucuya düz HTTP ve HTTPS istekleri gönderir. Nginx, Node, Go, Python veya HTTP konuşan herhangi bir ana bilgisayara karşı çalışır. Apache bağlantısı sadece aracın Apache HTTP Sunucusu ile birlikte gelmesidir.
Hangi eşzamanlılığı ve istek sayısını kullanmalıyım?
Düşükten başlayın ve yükseltin. -n 1000 -c 10 deneyin, ardından -c'yi 25, 50, 100'e çıkarın ve saniyedeki isteklerin nerede yükselmeyi bıraktığını ve başarısız isteklerin nerede görünmeye başladığını izleyin. Bu dönüm noktası, uç noktanın kabaca doygunluğa ulaştığı yerdir. Zirve eşzamanlılığınızı, büyük yuvarlak bir sayı seçmek yerine beklenen gerçek trafiğe göre ayarlayın.
API sorunsuz çalışırken neden başarısız isteklerim yüksek?
ab, yanıt uzunluğu istekler arasında değişiyorsa bir isteği başarısız olarak işaretler, bu dinamik JSON için normaldir. Uzunluk farklılıklarını başarısızlık olarak saymayı durdurmak için -l bayrağını ekleyin. Ardından, altında gerçek hatalar olup olmadığını görmek için 2xx olmayan yanıtlar satırını kontrol edin.
ab, oturum açma belirteci gerektiren bir uç noktayı test edebilir mi?
Evet, eğer zaten bir belirteciniz varsa. -H "Authorization: Bearer YOUR_TOKEN" ile geçirin. ab'nin yapamayacağı şey, önce yeni bir belirteç almak için oturum açmak ve sonra onu kullanmaktır. Bu çok adımlı bir akıştır ve bunun için Apidog gibi senaryo tabanlı bir araca ihtiyacınız vardır.
ab, HTTP/2'yi destekliyor mu?
Hayır. ab HTTP/1.x konuşur ve resmi belgelere göre bunu bile tam olarak uygulamaz. Sunucunuzun HTTP/2 altındaki davranışı önemliyse, bunun yerine HTTP/2 desteği olan bir yük aracı kullanın.
