DEV Community

Cover image for ApacheBench (ab): Terminalden API Yük Testi Nasıl Yapılır
Tobias Hoffmann
Tobias Hoffmann

Posted on • Originally published at apidog.com

ApacheBench (ab): Terminalden API Yük Testi Nasıl Yapılır

Bir uç nokta gönderdiniz. Postman'de doğru JSON'ı döndürüyor. Peki 200 istemci aynı anda vurduğunda ne olur? Saniyede 500 isteği kaldırır mı, yoksa 50 eşzamanlı istekte gecikme süresi yükselmeye mi başlar? ApacheBench bu soruya tek komutla hızlı bir ilk yanıt verir.

Apidog'u bugün deneyin

ab olarak çağrılan ApacheBench, tek bir URL'ye belirlediğiniz 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, hızlı çalışır ve bir uç noktanın yük altında nasıl davrandığını görmek için pratik bir başlangıç noktasıdır.

Bu rehberde ab kurulumunu, GET ve POST testlerini, başlık eklemeyi, çıktıyı yorumlamayı ve ab yerine daha kapsamlı bir araç kullanmanız gereken durumları uygulamalı olarak göreceksiniz. Buradaki komutlar, resmi Apache ab referansında belgelenen seçeneklere dayanır.

ApacheBench nedir ve nereden gelir?

ab, Apache HTTP Sunucusu ile birlikte gelen bir kıyaslama istemcisidir. Tek bir URL'ye bağlantılar açar, eşzamanlılık ayarınızın izin verdiği kadar hızlı istek gönderir, her yanıtı zamanlar ve test sonunda özet metrikler üretir.

ab özellikle şu sorular için kullanışlıdır:

  • Bu endpoint saniyede kaç istek işleyebiliyor?
  • Eşzamanlılık arttığında ortalama yanıt süresi nasıl değişiyor?
  • %95 ve %99 gecikme süreleri nerede bozuluyor?
  • Yük altında 5xx veya 4xx hataları oluşuyor mu?

Ancak kapsamı dardır. ab:

  • Yanıt gövdesinin doğru olup olmadığını doğrulamaz.
  • JSON şeması kontrol etmez.
  • Alan bazlı assertion çalıştırmaz.
  • Login → veri alma → güncelleme gibi çok adımlı akışları modellemez.
  • Aynı anda yalnızca tek URL test eder.

Bu yüzden ab'yi fonksiyonel test aracı değil, tek endpoint için hızlı yük probu olarak düşünün.

Daha geniş bağlam için API yük testinin ne olduğunu ve API yanıt süresinin neden önemli olduğunu inceleyebilirsiniz.

ab'yi kurmak

ab, Apache yardımcı araçlarıyla birlikte gelir. Kurulum komutu işletim sistemine göre değişir.

Debian ve Ubuntu 

sudo apt-get update
sudo apt-get install -y apache2-utils
Enter fullscreen mode Exit fullscreen mode

CentOS, RHEL ve Fedora 

# CentOS 7
sudo yum install -y httpd-tools

# Fedora ve CentOS 8+
sudo dnf install -y httpd-tools
Enter fullscreen mode Exit fullscreen mode

macOS

macOS genellikle Apache ile birlikte ab içerir. Kontrol edin:

ab -V
Enter fullscreen mode Exit fullscreen mode

Version 2.3 benzeri bir çıktı görüyorsanız hazırsınız.

Komut yoksa Homebrew ile Apache paketini kurabilirsiniz. Kurulumdan sonra tekrar doğrulayın:

ab -V
Enter fullscreen mode Exit fullscreen mode

Temel bir yük testi çalıştırma

ab ile en çok kullanacağınız iki seçenek şunlardır:

  • -n: Toplam istek sayısı
  • -c: Aynı anda çalışacak eşzamanlı istek sayısı

Örnek:

ab -n 1000 -c 50 https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Bu komut şunu yapar:

  • Toplam 1000 istek gönderir.
  • Aynı anda en fazla 50 isteği açık tutar.
  • Testi https://api.example.com/v1/users endpoint'ine uygular.

Not: ab tam URL ister. Sadece host vermek yerine path de ekleyin. Kök endpoint'i test edecekseniz sondaki / karakterini kullanın:

ab -n 1000 -c 50 https://api.example.com/
Enter fullscreen mode Exit fullscreen mode

KeepAlive ile daha gerçekçi test

Gerçek istemciler çoğu zaman her istek için yeni TCP bağlantısı açmaz; bağlantıları yeniden kullanır. Bunu -k ile simüle edebilirsiniz:

ab -n 1000 -c 50 -k https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

-k, HTTP KeepAlive kullanır. Bu sayede bağlantı kurma maliyeti azalır ve test, tarayıcı veya iyi yapılandırılmış API istemcilerine daha yakın davranır.

Karşılaştırma yapmak için iki testi ayrı ayrı çalıştırın:

# Her istekte yeni bağlantı
ab -n 1000 -c 50 https://api.example.com/v1/users

# KeepAlive ile bağlantı yeniden kullanımı
ab -n 1000 -c 50 -k https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Aradaki fark, gecikmenizin ne kadarının bağlantı kurulumundan kaynaklandığını gösterir.

Sabit süreli test çalıştırma

Toplam istek sayısı yerine testi belirli süre çalıştırmak istiyorsanız -t kullanın:

ab -t 30 -c 50 -k https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Bu komut:

  • Testi en fazla 30 saniye çalıştırır.
  • Eşzamanlılığı 50 olarak ayarlar.
  • KeepAlive kullanır.

-t, dahili olarak yüksek bir -n değeri kullanır ve süre dolunca testi durdurur. Kısa smoke testleri için kullanışlıdır.

Bir POST uç noktasını test etme

Çoğu API testi sadece GET değildir. POST endpoint test etmek için istek gövdesini bir dosyaya koymanız ve -p ile geçirmeniz gerekir. Ayrıca Content-Type başlığını -T ile açıkça belirtmelisiniz.

1. Payload dosyasını oluşturun 

cat > payload.json <<'EOF'
{"name": "Ada Lovelace", "email": "ada@example.com"}
EOF
Enter fullscreen mode Exit fullscreen mode

2. POST yük testi çalıştırın 

ab -n 500 -c 25 -k \
  -p payload.json \
  -T application/json \
  https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Burada:

  • -p payload.json: POST body olarak kullanılacak dosyayı belirtir.
  • -T application/json: Content-Type başlığını ayarlar.
  • -n 500: Toplam 500 istek gönderir.
  • -c 25: Aynı anda 25 istek çalıştırır.
  • -k: KeepAlive kullanır.

-T belirtmezseniz varsayılan içerik türü text/plain olur. JSON API testlerinde genellikle açıkça şunu kullanmalısınız:

-T application/json
Enter fullscreen mode Exit fullscreen mode

Authorization header ekleme

Endpoint token gerektiriyorsa -H kullanın:

ab -n 500 -c 25 -k \
  -p payload.json \
  -T application/json \
  -H "Authorization: Bearer YOUR_TOKEN" \
  https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Birden fazla header gerekiyorsa -H bayrağını tekrar edin:

ab -n 500 -c 25 -k \
  -p payload.json \
  -T application/json \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "X-Request-Source: load-test" \
  https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

JSON gövdeleri hazırlama konusunda pratik bir hatırlatma için curl ile JSON verileri nasıl POST edilir başlıklı yazıya bakabilirsiniz. Aynı JSON dosyası ab payload'ı olarak da kullanılabilir.

Çıktıyı okuma

Örnek bir ab çıktısı şöyle görünür:

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)
Enter fullscreen mode Exit fullscreen mode

İlk olarak şu alanlara bakın.

Requests per second 

Requests per second:    237.42 [#/sec] (mean)
Enter fullscreen mode Exit fullscreen mode

Bu, endpoint'in ortalama verimidir. Toplam istek sayısının toplam süreye bölünmesiyle hesaplanır.

Tek başına yeterli değildir. Yüksek RPS iyi görünür, ancak hata oranı artıyorsa sonuç güvenilir değildir.

Failed requests ve Non-2xx responses 

Failed requests:        0
Non-2xx responses:      0
Enter fullscreen mode Exit fullscreen mode

Bunları RPS'ten önce kontrol edin.

  • Failed requests: ab tarafından başarısız sayılan isteklerdir.
  • Non-2xx responses: 2xx dışında dönen HTTP yanıtlarıdır.

Eğer yanıtların önemli bir kısmı 500, 502, 503 veya 429 ise yüksek RPS değeri gerçek başarıyı temsil etmez.

Dinamik JSON yanıtlarında gövde uzunluğu değişiyorsa ab, bazı istekleri başarısız sayabilir. Bu durumda uzunluk farklılıklarını hata olarak saymamak için -l kullanabilirsiniz:

ab -n 1000 -c 50 -l https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Yine de Non-2xx responses satırını kontrol etmeye devam edin.

Time per request

Çıktıda iki farklı Time per request satırı vardır:

Time per request:       210.598 [ms] (mean)
Time per request:       4.212 [ms] (mean, across all concurrent requests)
Enter fullscreen mode Exit fullscreen mode

İlk satır, bir kullanıcının ortalama bekleme süresine daha yakındır. Kullanıcı deneyimi açısından öncelikle bunu takip edin.

İkinci satır, tüm eşzamanlı istekler üzerinden tamamlanma aralığını gösterir. Verim hesaplaması için faydalıdır, ancak kullanıcı gecikmesi olarak okunmamalıdır.

Percentile tablosu

En önemli bölüm genellikle burasıdır:

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)
Enter fullscreen mode Exit fullscreen mode

Bu tablo gecikme dağılımını gösterir.

  • 50%: Medyan gecikme
  • 95%: İsteklerin %95'inin bu sürede veya daha kısa sürede tamamlandığı nokta
  • 99%: Yavaş kuyruk davranışını gösterir
  • 100%: En yavaş istek

Ortalama gecikme düşük olsa bile %95 veya %99 yükseliyorsa gerçek kullanıcılar yavaşlık yaşamaya başlar. Bu yüzden özellikle p95 ve p99 değerlerini izleyin.

CSV veya gnuplot çıktısı alma

Grafik çizmek için percentile verisini CSV olarak yazdırabilirsiniz:

ab -n 1000 -c 50 -e results.csv https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Gnuplot uyumlu çıktı için:

ab -n 1000 -c 50 -g results.tsv https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Pratik test stratejisi

Tek bir komutla karar vermek yerine eşzamanlılığı kademeli artırın.

Örneğin:

ab -n 1000 -c 10 -k https://api.example.com/v1/users
ab -n 1000 -c 25 -k https://api.example.com/v1/users
ab -n 1000 -c 50 -k https://api.example.com/v1/users
ab -n 1000 -c 100 -k https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Her çalıştırmada şunları kaydedin:

Eşzamanlılık RPS Ortalama süre p95 p99 Failed Non-2xx
10
25
50
100

Doygunluk noktasını şu sinyallerden anlarsınız:

  • RPS artık artmıyor.
  • p95 ve p99 hızlı yükseliyor.
  • Failed requests görünmeye başlıyor.
  • Non-2xx responses artıyor.
  • Sunucuda CPU, bellek, DB bağlantısı veya kuyruk metrikleri tavan yapıyor.

Bu noktada endpoint kapasitesine yaklaşmışsınızdır.

ab'nin doğru araç olmaktan çıktığı yer

ab basit ve hızlıdır, ancak bilinçli kullanılmalıdır.

Her çalıştırmada tek URL test eder

ab, tek endpoint'e yük uygular. Şu tür akışları modelleyemez:

  1. Login ol
  2. Token al
  3. Kaynak oluştur
  4. Kaynağı oku
  5. Kaynağı güncelle
  6. Logout ol

Gerçek kullanıcı yolculukları çoğu zaman birden fazla endpoint içerir. Böyle bir senaryo için ab uygun değildir.

Yanıt doğruluğunu kontrol etmez

ab, durum kodlarını ve yanıt boyutlarını sayar. Ancak:

  • JSON parse etmez.
  • Şema doğrulamaz.
  • Alan değerlerini kontrol etmez.
  • İş kuralı doğrulaması yapmaz.

Bir endpoint hızlı yanıt verebilir ama yanlış veri döndürebilir. ab bunu yakalamaz.

HTTP/2 desteklemez

Resmi dokümantasyona göre ab, HTTP/1.x davranışını bile tam olarak uygulamaz ve yalnızca beklenen bazı yanıt biçimlerini kabul eder. HTTP/2 desteği yoktur.

Sunucunuz HTTP/2 altında farklı davranıyorsa ab sonucu bunu yansıtmaz.

Tek makineden yük üretir

ab, tek makineden ve tek işlemden çalışır. Belirli bir eşzamanlılıktan sonra test ettiğiniz şey sunucu değil, yük üreten istemci makineniz olabilir.

Yük üreten makinede şunları izleyin:

  • CPU kullanımı
  • Açık dosya limiti
  • Ağ bant genişliği
  • Socket limitleri
  • DNS veya TLS overhead'i

Bunlar sınıra gelirse ab sonuçları sunucu kapasitesini doğru göstermez.

Bu sınırlamalar ab'yi kötü yapmaz. Onu belirli bir iş için iyi yapar: tek endpoint üzerinde hızlı verim ve gecikme ölçümü.

Senaryolu akışlara, dağıtılmış yüke veya HTTP/2 desteğine ihtiyacınız varsa farklı araçlara geçin. JMeter çok adımlı senaryoları ve dağıtılmış çalıştırmaları destekler. Alternatifleri değerlendirmek için yük testi araçlarının daha geniş derlemesine bakabilirsiniz.

Fonksiyonel testin yeri

Performans tek eksendir. Doğruluk başka bir eksendir. ab, doğruluk tarafını test etmez.

Bir endpoint'i yük testine sokmadan önce şu sorulara yanıt vermelisiniz:

  • Doğru durum kodunu dönüyor mu?
  • Yanıt şemaya uyuyor mu?
  • Zorunlu alanlar var mı?
  • Değerler beklenen formatta mı?
  • Hata senaryoları doğru çalışıyor mu?
  • Çok adımlı API akışı doğru tamamlanıyor mu?

Bunlar fonksiyonel test ve sözleşme testi kapsamındadır.

Apidog, görsel assertion'larla test senaryoları oluşturmanıza, istekleri çok adımlı akışlara bağlamanıza ve yanıtları şemanıza göre doğrulamanıza olanak tanır. Bunlar ab'nin tasarım gereği yapmadığı işlerdir.

CI içinde çalıştırmak için Apidog CLI kullanabilirsiniz.

Önce CLI'ı kurun:

npm install -g apidog-cli
Enter fullscreen mode Exit fullscreen mode

Ardından kaydedilmiş bir senaryoyu veya paketi seçilen ortama karşı çalıştırın:

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

Parametreler:

  • -t: Senaryo, klasör veya paket kimliği
  • -e: Ortam kimliği
  • -r: Raporlayıcılar (cli, html, json, junit)
  • -d veya --iteration-data: Veri odaklı testler için veri dosyası yolu veya test verisi kimliği

Sağlıklı bir test akışı şöyle olabilir:

  1. Apidog ile fonksiyonel senaryoları çalıştırın.
  2. Yanıtların doğru olduğunu doğrulayın.
  3. Aynı endpoint için ab ile yük testi çalıştırın.
  4. RPS, p95, p99 ve hata oranını kaydedin.
  5. Sonuçları CI raporları ve izleme metrikleriyle birlikte değerlendirin.

Doğruluk ve performans tarafını birlikte düşünmek için Apidog performans testi rehberine ve genel API performans testi eğitimine bakabilirsiniz.

Sıkça Sorulan Sorular

ApacheBench sadece Apache sunucuları için mi geçerlidir?

Hayır. Adına rağmen ab, herhangi bir HTTP veya HTTPS sunucusuna istek gönderebilir. Nginx, Node.js, Go, Python veya başka bir stack ile çalışan API'leri test edebilirsiniz. Apache bağlantısı, aracın Apache HTTP Sunucusu ile birlikte gelmesinden kaynaklanır.

Hangi eşzamanlılığı ve istek sayısını kullanmalıyım?

Düşükten başlayıp kademeli artırın.

Örneğin:

ab -n 1000 -c 10 -k https://api.example.com/v1/users
ab -n 1000 -c 25 -k https://api.example.com/v1/users
ab -n 1000 -c 50 -k https://api.example.com/v1/users
ab -n 1000 -c 100 -k https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

RPS'in nerede artmayı bıraktığını, p95/p99 değerlerinin nerede yükseldiğini ve hataların nerede başladığını izleyin. Test eşzamanlılığını rastgele büyük bir sayı yerine beklenen gerçek trafiğe göre seçin.

API sorunsuz çalışırken neden başarısız isteklerim yüksek?

Dinamik JSON yanıtlarında gövde uzunluğu istekler arasında değişebilir. ab, varsayılan davranışında bu uzunluk farklarını başarısızlık olarak sayabilir.

Bunu engellemek için -l kullanın:

ab -n 1000 -c 50 -l https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Ardından gerçek hata olup olmadığını görmek için Non-2xx responses satırını kontrol edin.

ab, oturum açma belirteci gerektiren bir uç noktayı test edebilir mi?

Evet, elinizde hazır bir token varsa header olarak geçebilirsiniz:

ab -n 500 -c 25 -k \
  -H "Authorization: Bearer YOUR_TOKEN" \
  https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Ancak ab önce login olup token alma, sonra bu token ile başka endpoint çağırma akışını otomatikleştiremez. Bu çok adımlı bir senaryodur ve Apidog gibi senaryo tabanlı bir araç gerektirir.

ab, HTTP/2'yi destekliyor mu?

Hayır. ab, HTTP/1.x konuşur ve resmi dokümantasyona göre HTTP/1.x davranışını bile tam olarak uygulamaz. Sunucunuzun HTTP/2 altındaki performansı önemliyse HTTP/2 destekleyen bir yük testi aracı kullanın.

Top comments (0)