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

ApacheBench (ab) ile bir API'ye nasıl yük testi yapacağınızı öğrenin: kurun, -n ve -c testlerini çalıştırın, -p ve -T ile POST isteği gönderin ve saniyedeki istekleri (requests/sec) ve yüzdelik çıktıyı okuyun.

INEZA Felin-Michel

INEZA Felin-Michel

6 July 2026

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

Kurumsal İçin Apidog

Şirket İçi (On-Premises) Dağıtım

SSO ve RBAC

SOC 2 Uyumlu

Apidog Enterprise'ı Keşfedin

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.

button

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.

İş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:

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.

API Tasarım-Öncelikli Yaklaşımı Apidog'da Uygulayın

API'leri oluşturmanın ve kullanmanın daha kolay yolunu keşfedin