Siege ve Locust ile Yük Testi

Tek bir URL'ye istek yağdırıp "saniyede 800 istek kaldırıyorum" demek kolaydır. Sorun şu ki gerçek ziyaretçiler tek bir URL'ye girmez: ana sayfayı açar, kategoriye tıklar, arama yapar, sepete ürün ekler ve arada birkaç saniye düşünür. Bu davranışın hiçbiri düz bir benchmark komutunda yoktur. İşte yük testi araçlarında bir üst basamağa, yani Siege ve Locust'a geçmenizin sebebi budur: ikisi de tek URL yerine bir davranış senaryosu çalıştırır ve size sunucunuzun gerçek trafik altındaki halini gösterir.

Bu rehberde Siege'i komut satırından hızlı ve gerçekçi testler için, Locust'u ise Python ile yazdığınız senaryoları yüzlerce sanal kullanıcıya dağıtmak için nasıl kullanacağınızı anlatacağım. Kurulumdan çıktı okumaya, dağıtık teste kadar gerçek komutlarla ilerleyeceğiz. Ayrıca en kritik kısmı — hangi sonuçların güvenilir, hangilerinin kendi test makinenizin darboğazı olduğunu — ayırt etmeyi göstereceğim.

Neden ApacheBench Yetmiyor#

ApacheBench ile yük testi yazısında anlattığım gibi ab, tek bir adrese sabit eşzamanlılıkta istek gönderen tek dosyalık bir araçtır. Beş dakikada ilk fikri verir ve bu yüzden değerlidir. Ama üç ciddi sınırı vardır. Birincisi tek URL testi yapar; sitenizin en ağır sayfası test edilmemiş kalır. İkincisi bekleme süresi (think time) kavramı yoktur; sanal kullanıcılar insan gibi değil, makine gibi davranır. Üçüncüsü oturum yönetimi yoktur; giriş yapıp sepete ürün ekleyen bir akışı simüle edemezsiniz.

Siege ve Locust bu üç boşluğu farklı yollardan doldurur. Siege bir URL listesi dosyası okuyup rastgele sırayla gezinir, çerezleri saklar ve istekler arasına gecikme koyabilir; kurulumu birkaç saniyedir. Locust ise Python ile senaryo yazmanıza izin verir: koşullu akışlar, form gönderimi, token taşıma, ağırlıklı görev dağılımı — hepsi normal Python kodu olarak. Karşılaştırma tablosu şöyle:

Kural basit: hızlı bir sağlık kontrolü için ab, gerçekçi gezinme yükü için Siege, karmaşık iş akışları ve büyük ölçek için Locust.

Siege Kurulumu ve İlk Test#

Siege neredeyse tüm dağıtımların deposunda vardır. Kurulum tek satırdır:

# Debian / Ubuntu
sudo apt update && sudo apt install -y siege

# RHEL / AlmaLinux / Rocky (EPEL deposu gerekir)
sudo dnf install -y epel-release && sudo dnf install -y siege

# Sürümü doğrula
siege --version

En basit test, 25 eşzamanlı kullanıcı ile bir dakika boyunca tek adrese gitmektir:

# -c : eşzamanlı kullanıcı sayısı
# -t : test süresi (1M = 1 dakika, 30S = 30 saniye, 1H = 1 saat)
# -d : istekler arasında 0-1 saniye rastgele gecikme (think time)
siege -c 25 -t 1M -d 1 https://firmaniz.com/

Ama Siege'in asıl gücü URL listesidir. Sitenizin gerçekten ziyaret edilen sayfalarını bir dosyaya yazın:

cat > urls.txt <<'LISTE'
https://firmaniz.com/
https://firmaniz.com/urunler
https://firmaniz.com/urunler/kategori/ayakkabi
https://firmaniz.com/hakkimizda
https://firmaniz.com/iletisim
https://firmaniz.com/arama?q=canta
LISTE

# -f : URL dosyası, -i : listeden rastgele (internet modu) seç
siege -c 50 -t 2M -d 2 -i -f urls.txt

Buradaki -i bayrağı önemlidir: listeyi sırayla değil rastgele gezer, yani gerçek kullanıcı dağılımına benzer. Listeye girecek sayfaları tahminle değil, erişim loglarınızdan seçin. Nginx için en çok istenen 20 yol:

awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Kalıcı ayarları her seferinde yazmak yerine ~/.siegerc dosyasına koyabilirsiniz; siege.config komutu bu dosyayı varsayılanlarla oluşturur. Orada connection = keep-alive, concurrent = 25, failures = 1024 gibi değerleri kalıcı hale getirirsiniz.

Siege Çıktısını Doğru Okumak#

Test bitince Siege şuna benzer bir özet basar:

Transactions:                   14238 hits
Availability:                   99.87 %
Elapsed time:                  119.42 secs
Data transferred:              186.44 MB
Response time:                   0.31 secs
Transaction rate:              119.23 trans/sec
Throughput:                      1.56 MB/sec
Concurrency:                    36.94
Successful transactions:        14219
Failed transactions:               19
Longest transaction:             4.87
Shortest transaction:            0.04

Bu satırların hepsi eşit derecede önemli değil. Öncelik sırasıyla bakmanız gerekenler şunlardır:

1. Availability — Başarılı isteklerin yüzdesi. %100 olmayan her değer bir sorundur. %99.87 kulağa iyi geliyor ama bu, her 1000 ziyaretçiden birinin hata sayfası gördüğü anlamına gelir.
2. Failed transactions — Kaç istek düştü. Sıfır değilse önce sunucu hata loglarına bakın; genellikle PHP-FPM havuzu ya da veritabanı bağlantı limiti doludur.
3. Response time — Ortalama yanıt süresi. Ortalama yanıltıcıdır; Longest transaction ile birlikte okuyun. Ortalama 0.31 iken en uzun 4.87 ise kullanıcıların bir kısmı beş saniye beklemiştir.
4. Concurrency — Siege'in hesapladığı gerçekleşen eşzamanlılık. Bu sayı -c ile verdiğiniz değere yakınsa sunucu yükü zamanında karşılıyor; çok üstündeyse istekler kuyrukta birikmiş demektir.
5. Transaction rate — Saniyedeki işlem sayısı. Kapasite planlaması için ham veridir; nasıl kullanılacağını eşzamanlı kullanıcı kapasitesi hesaplama yazısında adım adım anlattım.

Concurrency değerinin -c değerini aşması Siege'in en öğretici sinyalidir. 50 kullanıcı verdiğinizde Concurrency 130 çıkıyorsa, sunucu yanıt veremediği için istekler üst üste binmiştir; o noktada bulduğunuz "işlem/saniye" değeri kapasiteniz değil, tıkanma noktanızdır.

Locust ile Senaryo Tabanlı Test#

Locust bir Python paketidir ve senaryonuzu düz Python olarak yazarsınız. Kurulum için izole bir sanal ortam kullanın:

python3 -m venv ~/loadtest && source ~/loadtest/bin/activate
pip install locust
locust --version

Senaryo dosyası geleneksel olarak locustfile.py adını taşır. Aşağıdaki örnek, ağırlıklı görevlerle gerçekçi bir e-ticaret gezintisi kurar:

from locust import HttpUser, task, between

class Ziyaretci(HttpUser):
    # Her istek arasında 1-5 saniye "düşünme" süresi
    wait_time = between(1, 5)

    def on_start(self):
        # Oturum başında bir kez çalışır; giriş gerekiyorsa buraya
        self.client.get("/")

    @task(10)  # En sık yapılan iş: ana sayfa
    def ana_sayfa(self):
        self.client.get("/")

    @task(6)
    def kategori(self):
        self.client.get("/urunler/kategori/ayakkabi", name="/urunler/kategori/[isim]")

    @task(3)
    def arama(self):
        self.client.get("/arama?q=canta", name="/arama")

    @task(1)  # En nadir ama en ağır iş
    def sepete_ekle(self):
        self.client.post("/sepet/ekle", json={"urun_id": 1042, "adet": 1})

Buradaki name parametresi kritiktir: dinamik URL'leri tek bir satırda toplar, yoksa rapor binlerce ayrı satıra bölünür ve okunamaz hale gelir. @task içindeki sayı ağırlıktır; yukarıdaki dağılımda ana sayfa, sepete ekleme işleminden on kat daha sık çağrılır.

Testi arayüzsüz (headless) çalıştırmak, sonucu CSV olarak almanın en temiz yoludur:

# -u : toplam sanal kullanıcı, -r : saniyede kaç kullanıcı doğsun (ramp-up)
# -t : süre, --csv : sonuçları dosyaya yaz
locust -f locustfile.py --host https://firmaniz.com \
       --headless -u 200 -r 10 -t 5m --csv=sonuc

Bu komut 200 kullanıcıya 20 saniyede kademeli olarak çıkar, beş dakika koşar ve sonuc_stats.csv ile sonuc_failures.csv dosyalarını üretir. Kademeli çıkış (ramp-up) şart: 200 kullanıcıyı bir anda başlatmak, gerçek trafiğin değil bir DDoS dalgasının simülasyonudur.

Locust Web Arayüzü ve Dağıtık Test#

--headless bayrağını kaldırıp çalıştırırsanız Locust http://localhost:8089 adresinde bir web arayüzü açar. Buradan kullanıcı sayısını test devam ederken artırabilirsiniz ve bu, kırılma noktasını bulmanın en pratik yoludur: 50'de başlayın, yanıt süresi grafiğine bakarak 100, 200, 400 diye tırmanın. Yanıt süresi eğrisinin dikleştiği ve hata oranının sıfırdan ayrıldığı nokta sunucunuzun gerçek tavanıdır.

Tek bir test makinesi genellikle 500-1000 sanal kullanıcıdan sonra kendi CPU'sunu tüketir. O noktadan sonra ölçtüğünüz şey sunucunuz değil, kendi laptopunuzdur. Locust bunu master/worker mimarisiyle çözer:

# Koordinatör makinede (sonuçları toplar, arayüzü sunar)
locust -f locustfile.py --master --host https://firmaniz.com

# Her yük üreten makinede (birkaç tane çalıştırabilirsiniz)
locust -f locustfile.py --worker --master-host 185.12.34.56

Aynı fiziksel makinede birden fazla worker açmak da işe yarar, çünkü her Locust süreci tek bir CPU çekirdeği kullanır; dört çekirdekli bir makinede dört worker başlatmak üretebileceğiniz yükü kabaca dörde katlar. Yük üreteci makineleri, test ettiğiniz sunucudan farklı bir ağda olsun; aynı sunucuda test koşturmak hem CPU'yu paylaşır hem de ağ katmanını hiç ölçmez.

Sık Yapılan Hatalar ve Yanıltıcı Sonuçlar#

Yük testinde yanlış sonuç almak, hiç test etmemekten daha tehlikelidir; çünkü size sahte bir güven verir. En sık gördüğüm tuzaklar şunlar:

Kendi makinenizi ölçmek. Test sırasında yük üreten makinenin CPU'suna top ile bakın; %90 üstündeyse rakamlarınız çöptür. Ev internetinizden test yapıyorsanız yükleme kanalınız 400 eşzamanlı kullanıcıyı zaten taşıyamaz.

CDN'i ya da tam sayfa önbelleği unutmak. Cloudflare arkasındaki bir siteye test yaparsanız isteklerin çoğu kenar sunucudan döner, sunucunuza hiç ulaşmaz. Sonuç muhteşem görünür, kaynak sunucunuz hakkında hiçbir şey öğrenmezsiniz. Kaynak sunucuyu doğrudan test etmek için Host başlığını elle verin:

# DNS'i atlayıp doğrudan kaynak IP'ye, doğru Host başlığıyla git
siege -c 30 -t 1M "http://185.12.34.56/ Host: firmaniz.com"

Aynı şey uygulama içi önbellek için de geçerlidir: Nginx FastCGI cache ya da LiteSpeed Cache devredeyken ölçtüğünüz sayı, önbellek isabet oranınızın ne kadar iyi olduğudur — PHP'nizin ne kadar hızlı olduğu değil. İkisini de ayrı ayrı ölçün.

Bekleme süresi koymamak. -d ya da wait_time olmadan sanal kullanıcılar cevap alır almaz yeni istek atar. 100 böyle kullanıcı, gerçek dünyada 2000 ziyaretçiye denk gelir; kapasitenizi olduğundan kat kat düşük ölçersiniz.

Sadece ortalamaya bakmak. Ortalama yanıt süresi, kullanıcıların yarısının deneyimini gizler. Locust raporundaki 95% ve 99% yüzdelik sütunlarına bakın; SLA konuşmaları da bu değerler üzerinden yapılır. Basit bir çerçeve için şu eşikleri kullanabilirsiniz:

Canlı sistemde habersiz test yapmak. Canlı trafikle aynı anda yük testi çalıştırmak gerçek müşterilerinizi etkiler. Mümkünse aynı yapılandırmadaki bir kopya ortamda test edin; mecburen canlıda yapacaksanız trafiğin en düşük olduğu saati seçin ve hosting sağlayıcınıza haber verin. Test ettiğiniz sunucu size ait değilse bu doğrudan saldırı sayılır.

Test Sonrası: Rakamı Karara Dönüştürmek#

Yük testinin çıktısı bir rapor değil, bir karardır. Test bitti, p95 süreniz 2.4 saniye ve hata oranınız %0.4 çıktı diyelim. Sıradaki adım rastgele optimizasyon yapmak değil, darboğazın hangi katmanda olduğunu bulmaktır. Test sırasında sunucuda paralel olarak şu üç ölçümü açık tutun:

# 1) Genel yük ve CPU beklemesi (%wa yüksekse disk darboğazı)
vmstat 2

# 2) PHP-FPM havuz doygunluğu (listen queue dolu mu?)
watch -n2 'curl -s http://127.0.0.1/status?full | head -20'

# 3) Yavaş veritabanı sorguları
sudo tail -f /var/lib/mysql/slow-query.log

CPU tavan yapıyorsa çözüm daha fazla çekirdek ya da PHP kodunun kendisidir. %wa (I/O bekleme) yüksekse disk yavaştır. RAM dolup takas (swap) başladıysa hiçbir mikro optimizasyon işe yaramaz. Veritabanı yavaş sorgu logu doluyorsa önce indeks eksikliğine bakın; tek bir eksik indeks, 500 kullanıcıda çöken bir siteyi 5000 kullanıcıda çalışır hale getirebilir.

Katman katman ilerlemenin faydası şudur: her düzeltmeden sonra aynı testi aynı parametrelerle tekrar koşar ve iyileşmeyi rakamla görürsünüz. Komutu bir kabuk betiğine yazın, sonuçları tarih damgalı CSV olarak saklayın. Altı ay sonra "site yavaşladı" dendiğinde elinizde bir taban çizgisi olur.

Sıkça Sorulan Sorular#

Siege ile Locust arasında hangisini seçmeliyim#

Testinizin karmaşıklığına bakın. Sitenizde giriş gerektirmeyen, birkaç sayfadan oluşan bir gezinti simüle edeceksiniz ve sonucu beş dakika içinde istiyorsanız Siege yeterlidir; tek satır komut ve bir URL dosyası ile işiniz biter. Giriş yapma, form gönderme, token taşıma, koşullu akış ya da 1000 kullanıcı üstü dağıtık test gerekiyorsa Locust'a geçin. Pratikte çoğu ekip ikisini birlikte kullanır: günlük hızlı kontrol Siege, sürüm öncesi büyük test Locust.

Yük testi sunucuma zarar verir mi#

Doğru yapıldığında kalıcı bir zarar vermez, ancak test süresince site gerçekten yavaşlar ya da hata verir; bu zaten testin amacıdır. Riskler daha çok yan etkilerdedir: veritabanına gerçek kayıt yazan senaryolar test verisi biriktirir, e-posta gönderen akışlar yüzlerce mail atabilir ve ödeme adımı gerçek işlem deneyebilir. Bu yüzden yazma işlemi yapan senaryoları ya kopya ortamda çalıştırın ya da test kullanıcısı ve test ürünüyle sınırlayın.

Kaç eşzamanlı kullanıcı ile test yapmalıyım#

Beklediğiniz zirve trafiğin en az iki katıyla başlayın. Analytics verinizden en yoğun saatteki eşzamanlı ziyaretçi sayısını bulun, ikiyle çarpın ve testin başlangıç hedefi bu olsun. Asıl faydalı yaklaşım tek bir sayıyı test etmek değil, kademeli tırmanmaktır: 50, 100, 200, 400 diye çıkıp yanıt süresinin dikleştiği ve hataların başladığı noktayı bulun. O nokta sizin gerçek kapasitenizdir.

Locust testi kendi bilgisayarımdan çalıştırabilir miyim#

Küçük testler için evet, ama sınırlarını bilin. Tek bir Locust süreci tek çekirdek kullanır ve ortalama bir dizüstü bilgisayar 300-800 sanal kullanıcıdan sonra kendi CPU'sunu tüketmeye başlar. Ayrıca ev bağlantınızın yükleme hızı ve NAT arkasındaki port limitleri sizi erkenden sınırlar. Ciddi testler için sunucuya yakın bir veri merkezinde geçici bir sanal sunucu kiralayıp testi oradan koşturmak hem daha doğru hem de daha ucuzdur.

Test sonuçlarındaki hata oranı neden sıfırdan büyük çıkıyor#

En yaygın üç sebep vardır. Birincisi PHP-FPM ya da uygulama sunucusu havuzunun dolması; bu durumda 502/504 hataları görürsünüz. İkincisi veritabanı bağlantı limitine dayanmak; log dosyasında "too many connections" satırı bulursunuz. Üçüncüsü ise sunucudaki hız sınırlama veya güvenlik duvarı kurallarının kendi test trafiğinizi saldırı sanıp engellemesidir. Hangisi olduğunu anlamak için test sırasında sunucunun hata loglarını canlı izleyin.

Yük testini ne sıklıkla tekrarlamalıyım#

En azından her büyük sürümden önce ve altyapı değişikliklerinden sonra tekrarlayın. Sunucu paketi değiştirdiğinizde, PHP sürümü yükselttiğinizde, yeni bir eklenti eklediğinizde ya da veritabanı yapısında değişiklik yaptığınızda aynı testi aynı parametrelerle koşup önceki sonuçla karşılaştırın. Yılda bir kez de trafik zirvesi öncesinde (kampanya dönemi, sezon başı) planlı bir test yapmak, sürprizleri kampanya gününden önce görmenizi sağlar.

Kapanış#

Siege ve Locust arasındaki fark aslında bir olgunluk basamağıdır: Siege size gerçekçi bir gezinti yükü kurmanın en hızlı yolunu verir, Locust ise senaryonuzu koda dökerek istediğiniz karmaşıklıkta ve ölçekte tekrarlanabilir hale getirir. Aklınızda kalması gereken dört alışkanlık şunlar: bekleme süresi koymadan test etmeyin, ortalama yerine p95 ve p99 değerlerine bakın, test sırasında sunucunun CPU ve I/O metriklerini paralel izleyin ve her testi aynı parametrelerle tekrarlanabilir bir betik haline getirin.

Testin sonunda darboğazın sunucu kaynağı olduğunu görürseniz bir sonraki adım donanımdır. Ölçtüğünüz yükü rahatça taşıyacak NVMe diskli VDS ve bulut sunucu paketlerimizle tam root erişimiyle kendi test ortamınızı kurabilir, kaynak planlaması ve ayar tarafını bize bırakmak isterseniz sunucu yönetimi hizmetimizden yararlanabilirsiniz. Yüksek trafikli projeler için dedicated sunucu seçenekleri de kaynakları hiç paylaşmadan çalışmanızı sağlar.