ApacheBench (ab) ile Hızlı Yük Testi

Sunucunuz şu an kaç eşzamanlı isteği taşıyabiliyor? Bu soruya "bilmiyorum ama sanırım yeter" diye cevap veriyorsanız, kampanya gününde ya da bir haber sitesinden gelen ani trafikte öğreneceksiniz. ApacheBench, yani kısaca ab, bu soruya beş dakikada ilk cevabı veren en basit araçtır. Apache HTTP Server ile birlikte gelen tek dosyalık bir komut satırı programıdır, hiçbir bağımlılığı yoktur ve tek bir URL'ye belirlediğiniz eşzamanlılıkta istek yağdırıp size saniyede kaç isteği yanıtlayabildiğinizi söyler.

Bu rehberde ab komutunun kurulumunu, parametrelerin gerçekten ne anlama geldiğini, çıktının hangi satırının önemli olduğunu ve en kritik kısmı — çıkan sayının ne zaman güvenilir, ne zaman yanıltıcı olduğunu anlatacağım. Çünkü ab ile ölçüm yapmak kolaydır; yanlış ölçüm yapıp yanlış karar vermek daha da kolaydır. Yazının sonunda sadece komutu değil, sonucu okuma alışkanlığını da edinmiş olacaksınız.

ApacheBench Nedir ve Ne Zaman Yeterlidir#

ab, tek bir hedef URL'ye önceden belirlediğiniz sayıda HTTP isteği gönderir ve bunu istediğiniz kadar paralel bağlantıyla yapar. Karmaşık senaryo yazmaz, kullanıcı yolculuğu simüle etmez, oturum yönetmez. Yaptığı iş tam olarak şudur: "şu adrese N istek at, C tanesi aynı anda uçsun, ne kadar sürdüğünü ölç." Bu sadeliği hem en büyük gücü hem de en büyük sınırıdır.

ab şu durumlarda mükemmel bir araçtır: bir önbellek katmanı ekledikten önce ve sonra farkı ölçmek, PHP sürümünü yükselttiğinizde kazancı görmek, bir statik dosyanın sunucudan ne hızda çıktığını doğrulamak, iki farklı sunucu paketini aynı sayfa üzerinde kıyaslamak. Şu durumlarda ise yetersizdir: giriş yapıp sepete ürün ekleyen ve ödeme yapan bir kullanıcı akışını taklit etmek, farklı sayfalara ağırlıklı dağılım yapmak, kademeli olarak artan (ramp-up) yük uygulamak. Bu senaryolar için Siege ve Locust ile yük testi yazısındaki araçlara geçmeniz gerekir.

Kısacası ab'yi bir "ilk teşhis aracı" olarak düşünün. Doktorun ateş ölçmesi gibidir: hızlıdır, tek sayı verir, ciddi bir sorun varsa hemen gösterir ama teşhisi tek başına koymaz.

Kurulum ve İlk Test#

ab, Debian/Ubuntu tarafında apache2-utils, RHEL/AlmaLinux tarafında httpd-tools paketinin içinde gelir. Apache kurulu olmasına gerek yoktur; sadece araç paketini kurmanız yeterlidir:

# Debian / Ubuntu
sudo apt update && sudo apt install -y apache2-utils

# AlmaLinux / Rocky / RHEL
sudo dnf install -y httpd-tools

# Kurulumu doğrula
ab -V

Testi hedef sunucunun kendisinden değil, ayrı bir makineden çalıştırın. Aynı sunucuda koşarsanız ab'nin kendisi CPU yiyeceği için hem sunucunun kapasitesini hem de test aracının doğruluğunu bozarsınız. En temiz kurulum, aynı veri merkezinde ya da yakın bir lokasyonda duran ikinci bir sunucudan test etmektir.

İlk testiniz mütevazı olsun. Sisteminizi hemen dibine vurdurmak yerine düşük bir eşzamanlılıkla temel çizgiyi (baseline) çıkarın:

# 200 istek, 10'u aynı anda. URL'nin sonundaki / önemlidir.
ab -n 200 -c 10 https://firmaniz.com/

Buradaki en yaygın hata, URL'nin sonuna eğik çizgi koymamaktır. ab https://firmaniz.com komutu ab: invalid URL hatası verir çünkü araç bir yol (path) bekler. https://firmaniz.com/ doğru, https://firmaniz.com yanlıştır.

Parametreleri Doğru Seçmek#

ab'nin onlarca bayrağı vardır ama günlük kullanımda işinize yarayacak olanlar bir avuçtur. Bunları ezberlemek yerine ne yaptıklarını anlamak daha kalıcıdır.

En sık gözden kaçan bayrak -k'dır. Keep-alive olmadan ab her istek için yeni bir TCP bağlantısı ve yeni bir TLS el sıkışması yapar; gerçek tarayıcılar ise bir bağlantıyı onlarca istek boyunca yeniden kullanır. -k olmadan ölçtüğünüz sayı, HTTPS sitelerde gerçeğin çok altında çıkar ve siz sunucunun yavaş olduğunu sanırsınız. Aradaki farkı kendiniz görün:

# Keep-alive kapalı (her istek yeni TLS el sıkışması)
ab -n 1000 -c 20 https://firmaniz.com/

# Keep-alive açık (bağlantı yeniden kullanılıyor)
ab -n 1000 -c 20 -k https://firmaniz.com/

Sıkıştırmayı da unutmayın. Tarayıcılar Accept-Encoding: gzip gönderir, ab göndermez. Sıkıştırmanın etkisini ölçmek istiyorsanız başlığı elle eklemeniz gerekir:

ab -n 1000 -c 20 -k -H "Accept-Encoding: gzip, deflate" https://firmaniz.com/

Süre tabanlı test genellikle daha kullanışlıdır, çünkü sunucu yavaşladıkça -n ile verdiğiniz istek sayısı dakikalarca sürebilir:

# 30 saniye boyunca 50 eşzamanlı istek gönder
ab -t 30 -c 50 -k https://firmaniz.com/

Not: -t kullandığınızda ab varsayılan olarak 50000 istek üst sınırı koyar; daha fazlasını istiyorsanız -n ile büyük bir sayı da vermeniz gerekir.

Çıktıyı Satır Satır Okumak#

Testin sonunda karşınıza yirmi küsur satırlık bir rapor çıkar. Çoğu kişi sadece "Requests per second" satırına bakıp geçer; oysa asıl bilgi altta gizlidir. Tipik bir çıktının önemli kısımları şöyledir:

Concurrency Level:      20
Time taken for tests:   8.412 seconds
Complete requests:      1000
Failed requests:        0
Non-2xx responses:      0
Total transferred:      14520000 bytes
Requests per second:    118.88 [#/sec] (mean)
Time per request:       168.24 [ms] (mean)
Time per request:       8.412 [ms] (mean, across all concurrent requests)
Transfer rate:          1685.44 [Kbytes/sec] received

Percentage of the requests served within a certain time (ms)
  50%    142
  66%    159
  75%    171
  80%    182
  90%    241
  95%    318
  98%    502
  99%    690
 100%   1204 (longest request)

Bu tablodan çıkarmanız gereken dersler şunlar:

1. Failed requests sıfırdan büyükse test geçersizdir. Sunucu yükün altında hata döndürmüş demektir; önce hatanın sebebini bulun, sonra ölçün.
2. Non-2xx responses satırı sinsi bir tuzaktır. Sunucunuz 502 ya da 429 dönerken bunu çok hızlı yapar; "Requests per second" fırlar ve siz sistemin harika olduğunu sanırsınız. Her testte bu satırın sıfır olduğunu doğrulayın.
3. İki farklı Time per request satırı vardır. İlki bir kullanıcının beklediği süredir (bu sizi ilgilendirir), ikincisi sunucunun bir isteği çıkarma aralığıdır. Karıştırmayın.
4. Yüzdelik dilim tablosu ortalamadan daha değerlidir. Yukarıdaki örnekte ortalama 168 ms ama %99'luk dilim 690 ms. Yani her yüz kullanıcıdan biri neredeyse yedi kat daha uzun bekliyor. Ortalama bunu saklar, yüzdelik dilim gösterir.

Ölçüm alırken tek bir koşuya güvenmeyin. Aynı komutu üç kez çalıştırın; sonuçlar birbirine yakınsa değer güvenilirdir, %30'un üzerinde oynuyorsa ya sunucuda başka bir iş çalışıyordur ya da ağ tarafında bir dalgalanma vardır.

POST İsteği ve Oturum Gerektiren Sayfaları Test Etmek#

ab yalnızca GET yapmakla sınırlı değildir. Bir API uç noktasını ya da form gönderimini test etmek için gövdeyi bir dosyaya yazıp -p ile verirsiniz:

# JSON gövdesini dosyaya yaz
cat > /tmp/payload.json <<'JSON'
{"urun_id": 1042, "adet": 2}
JSON

# POST testi: -p gövde dosyası, -T içerik tipi
ab -n 500 -c 10 -k \
   -p /tmp/payload.json \
   -T "application/json" \
   -H "Authorization: Bearer ORNEK_TOKEN" \
   https://firmaniz.com/api/sepet

Oturum gerektiren bir sayfayı test etmek için çerezi elle taşımanız gerekir. Önce tarayıcının geliştirici araçlarından ya da curl ile oturum çerezini alın, sonra -C bayrağıyla gönderin:

# Tek bir çerez
ab -n 300 -c 10 -k -C "PHPSESSID=ornek0oturum0degeri" https://firmaniz.com/panel/

# Birden fazla çerez için -C bayrağını tekrarlayın
ab -n 300 -c 10 -k \
   -C "PHPSESSID=ornek0oturum0degeri" \
   -C "dil=tr" \
   https://firmaniz.com/panel/

Burada dikkat edilmesi gereken nokta şudur: oturumlu sayfaları test ederken hepsi aynı kullanıcı olarak gider. Gerçek hayatta her kullanıcının kendi oturum verisi, kendi sepeti, kendi sorgusu olur ve önbellek isabet oranı çok daha düşüktür. ab ile aldığınız sonuç bu yüzden iyimser tarafta kalır. Gerçekçi bir eşzamanlılık tahmini için eşzamanlı kullanıcı kapasitesi hesaplama yazısındaki yöntemi kullanın.

ab'nin Sınırları ve Sık Yapılan Hatalar#

En sık gördüğüm hata, testin kendi makinesinde tıkanması. ab tek iş parçacıklıdır (single-threaded); modern bir sunucu 5000 istek/saniye çıkarabiliyorsa ab bunu üretemeden kendisi %100 CPU'ya oturur ve siz sunucunun sınırını değil test aracının sınırını ölçersiniz. Test sırasında ikinci bir terminalde top açıp ab sürecinin CPU kullanımına bakın; tek çekirdeği doldurmuşsa sonuç geçersizdir ve wrk gibi çok iş parçacıklı bir araca geçmeniz gerekir.

İkinci klasik hata CDN veya önbellek katmanını ölçmek. Alan adınız Cloudflare gibi bir katmanın arkasındaysa ab isteklerinizi büyük ihtimalle sunucunuz değil kenar düğüm yanıtlar; ölçtüğünüz şey kendi altyapınız olmaz. Origin'i ölçmek istiyorsanız --resolve benzeri bir seçenek ab'de olmadığı için ya doğrudan sunucu IP'sine -H "Host: firmaniz.com" ile gidin ya da test için ayrı bir alt alan adı kullanın:

# CDN'i atlayıp doğrudan origin'i ölç
ab -n 500 -c 20 -k -H "Host: firmaniz.com" http://185.12.34.56/

Üçüncü hata rate limit ve WAF kurallarını unutmak. Aynı IP'den saniyede yüzlerce istek gönderdiğinizde güvenlik katmanınız sizi haklı olarak saldırgan sanar; 429 ya da 403 döner. Testten önce kendi test IP'nizi geçici olarak beyaz listeye almanız gerekir. Aynı şekilde fail2ban gibi bir araç kendi IP'nizi banlayabilir ve testten sonra sunucuya SSH ile bağlanamayabilirsiniz.

Dördüncü hata üretim ortamında habersiz test yapmak. Yük testi tanım gereği hizmeti bozmaya çalışır. Mümkünse birebir kopya bir hazırlık (staging) ortamında, mümkün değilse en düşük trafikli saatte ve ekibi haberdar ederek çalıştırın. Sonuçları anlamlı kılmak için de her testten önce ortamı aynı hale getirin: aynı önbellek durumu, aynı arka plan görevleri, aynı veri hacmi.

Son olarak, ölçtüğünüz sayının bant genişliğine takılıp takılmadığını kontrol edin. Çıktıdaki Transfer rate değeri hattınızın kapasitesine yaklaşıyorsa CPU'nuz değil ağınız doludur. Kabaca bir hesap için bant genişliği hesaplayıcı aracını kullanabilir, sonuçları düşürüyorsa sıkıştırma ve önbellek tarafına yönelebilirsiniz. Statik içerikte ciddi kazanç için Nginx FastCGI cache yapılandırması iyi bir başlangıçtır.

Sıkça Sorulan Sorular#

ApacheBench ücretsiz mi ve ayrıca lisans gerekir mi#

Evet, tamamen ücretsizdir. ApacheBench, Apache HTTP Server projesinin bir parçasıdır ve Apache 2.0 lisansıyla dağıtılır; ticari kullanımda dahil hiçbir ücret ödemezsiniz. Debian/Ubuntu'da apache2-utils, RHEL ailesinde httpd-tools paketiyle kurulur ve Apache'nin kendisini kurmanıza gerek kalmaz.

ab testinde kaç istek ve kaç eşzamanlılık kullanmalıyım#

Tek bir doğru sayı yoktur ama sağlıklı bir başlangıç -n 1000 -c 10 şeklindedir. Sonra eşzamanlılığı 20, 50, 100 diye kademeli artırıp yanıt süresinin nerede bozulmaya başladığını arayın. Toplam istek sayısını en az 500-1000 tutun; daha azı istatistiksel olarak gürültülü olur ve yüzdelik dilim tablosu anlamsızlaşır.

ApacheBench sonuçları neden her seferinde farklı çıkıyor#

Çünkü ölçüm birçok değişkenden etkilenir: ağ gecikmesi, sunucudaki diğer süreçler, veritabanı önbelleğinin sıcak olup olmaması, opcode önbelleğinin dolu olması. Bu yüzden tek bir koşuya bakmayın; aynı testi üç kez çalıştırıp değerlerin birbirine yakın olduğunu doğrulayın. Karşılaştırma yaparken de "önce" ve "sonra" ölçümlerini mümkün olduğunca aynı koşullarda alın.

ab yerine hangi araçları kullanmalıyım#

Senaryo tabanlı test gerekiyorsa Locust ya da k6, çok iş parçacıklı yüksek hacimli test gerekiyorsa wrk, basit URL listesiyle sürekli yük için siege iyi seçeneklerdir. ab'yi terk etmeniz gerekmez; hızlı bir ilk ölçüm için hâlâ en pratik araçtır. Genellikle ab ile başlayıp ihtiyaç büyüdükçe daha yetenekli bir araca geçmek en verimli yoldur.

Failed requests sıfırdan büyük çıkıyor, ne anlama geliyor#

ab bir isteği yanıt uzunluğu, bağlantı ya da başlıklar bakımından tutarsız bulduğunda başarısız sayar. En sık sebep sunucunun yük altında hata sayfası döndürmesi ya da yanıt gövdesinin dinamik olarak farklı uzunlukta olmasıdır. İkinci durum yanıltıcıdır: sayfada rastgele bir içerik varsa uzunluk her seferinde değişir ve ab bunları "length" hatası olarak sayar. Bu yüzden testi mümkünse sabit içerikli bir sayfa üzerinde yapın.

Yük testini üretim sunucusunda yapmak güvenli mi#

Tavsiye edilmez. Yük testi hizmetin sınırını zorlar; gerçek kullanıcılar aynı anda sitedeyse onların deneyimini bozarsınız, en kötü ihtimalle veritabanı bağlantı havuzunu doldurup siteyi düşürürsünüz. Mümkünse birebir kopya bir hazırlık ortamı kullanın. Zorunluysa en düşük trafikli saatte, düşük eşzamanlılıkla başlayın ve Non-2xx responses satırını izleyerek kademeli ilerleyin.

Kapanış#

ApacheBench, performans çalışmasının ilk adımıdır ve bu adımı doğru atmak sonraki her şeyi kolaylaştırır. Aklınızda kalması gereken dört alışkanlık şunlar: testi hedef sunucudan değil ayrı bir makineden çalıştırın, HTTPS ölçümlerinde -k bayrağını atlamayın, Failed requests ve Non-2xx responses satırları sıfır değilse sonucu çöpe atın, ortalama yerine yüzdelik dilim tablosuna bakın. Bir de her ölçümden önce "ben tam olarak neyi ölçüyorum" diye sorun; CDN'i mi, origin'i mi, önbelleği mi?

Ölçüm sonunda darboğazın sunucu kaynağı olduğu ortaya çıkarsa, esnek şekilde büyütebileceğiniz VDS ve bulut sunucu paketlerimiz bu tür kapasite artışları için uygundur. Testi ve sonrasındaki ayarlamayı kendiniz üstlenmek istemiyorsanız sunucu yönetimi hizmetimiz yük testi, önbellek yapılandırması ve izleme kurulumunu sizin adınıza yapar; trafiğin bir kısmını uygulama katmanından önce süzmek isterseniz WAF çözümümüz de aynı çerçevenin parçasıdır.