Performans testi nasıl yapılır: sorudan rapora 8 adım

Albiferro Yazılım ve Sistem Limited Şirketi · Yayın 1 Kasım 2026

Ayrıntılı dokümantasyon →

Performans testi, bir sistemin beklenen (ve beklenenden fazla) yük altında ne kadar hızlı ve ne kadar hatasız çalıştığını ölçmektir. Testi koşturmak işin küçük kısmıdır: neyi soracağınızı, nerede ölçeceğinizi, hangi sonuca "geçti" diyeceğinizi önceden yazmazsanız grafikler bir şey söylemez. Bu rehber işi baştan sona sırasıyla anlatır; her adımda daha derine inen rehbere bağlantı vardır.

1. Soruyu ve hedefi yazın

"Sistem hızlı mı?" ölçülebilir bir soru değildir. İyi bir soru bir akışı, bir yükü ve bir sınırı söyler: sipariş akışı saniyede 300 istekte p95 800 ms'nin altında ve hata %1'in altında kalıyor mu? Yükün kaynağı tahmin değil veri olmalı: canlıdaki en yoğun saatin istek/sn'si, bir kampanya için beklenen çarpan. Ortalama yerine yüzdelik kullanın; ortalama, yavaş isteklerin çoğunu saklar (p95 ve p99 nedir).

Soru:    Kampanya günü sipariş akışı dayanır mı?
Hedef:   300 istek/sn, p95 < 800 ms, hata oranı < %1
Ortam:   staging (canlıyla aynı sürüm, aynı veri hacmi)
Akış:    giriş → ürün ara → sepete ekle → sipariş ver
Süre:    1 dk ısınma + 15 dk hedef yük

2. Ortamı seçin

Sonuç ancak ölçtüğünüz ortam kadar doğrudur. Test ortamı canlıyla aynı sürümü koşmalı, veritabanında benzer hacimde veri olmalı (on satırlık bir tablo her sorguyu hızlı gösterir) ve aynı önbellek, kuyruk ve dış servis ayarlarına sahip olmalıdır. Daha küçük bir ortamda ölçüyorsanız sonucu canlıya oranlamayın; o ortamın kendi sınırını bulduğunuzu bilin. Canlıda test yapacaksanız düşük trafikli bir saat seçin, ilgili ekiplere haber verin ve yalnızca veri değiştirmeyen istekleri kullanın.

3. Senaryoyu kurun

Senaryo gerçek kullanıcıların yaptığını yapmalıdır: yalnızca ana sayfayı çağıran bir test, sipariş akışındaki yavaş sorguyu hiç görmez. Akışı kurmanın üç kısa yolu var: API'niz için bir OpenAPI dosyası ya da Postman koleksiyonu varsa onu içe aktarın (Swagger/OpenAPI ve Postman'dan yük testi), akışı tarayıcıda bir kez yapıp HAR olarak kaydedin (HAR dosyasından yük testi) ya da adımları editörde kod yazmadan ekleyin (kod yazmadan yük testi).

• Test verisi: her VU aynı kullanıcıyla aynı ürünü ararsa önbellek her şeyi yanıtlar. Kullanıcıları ve arama terimlerini bir CSV dosyasından dağıtın.
• Korelasyon: girişin döndürdüğü token ya da oluşan siparişin id'si sonraki isteklere değişken olarak geçmelidir; sabit bir değer tekrarlanırsa sunucu tek bir oturumu ölçer.
• Kontroller: her adıma yanıtın doğru olduğunu söyleyen bir kontrol (check) ekleyin: durum kodu 200, gövdede beklenen alan. Hızlı dönen bir hata sayfası iyi bir yanıt süresi değildir.

4. Yük modelini seçin

Yükü iki şekilde verebilirsiniz. VU sayısıyla (kapalı model): N sanal kullanıcı akışı tekrar tekrar yapar; sistem yavaşlarsa istek hızı da düşer. İstek hızıyla (açık model): saniyede N iterasyon başlar; sistem yavaşlasa da gelen trafik azalmaz, tıpkı gerçek kullanıcılar gibi. Hedefiniz "saniyede 300 istek" ise istek hızıyla ölçün; aksi halde sistem yavaşladıkça test kendini hafifletir ve sonuç olduğundan iyi görünür (coordinated omission).

Spitfire'da yük modeli editörün Yük modeli bölümündedir: Sabit VU, Kademeli VU, Sabit istek hızı, Kademeli istek hızı ve iterasyon modelleri (Toplam iterasyon, VU başına iterasyon). Kademeli modellerde her aşamanın süresi ve hedefi bir plan grafiğinde görünür; bir VU'nun iterasyonlarını sabit aralıklarla başlatmak için pacing kullanılır.

5. Geçti/kaldı ölçütünü teste yazın

1. adımdaki hedef raporu okuyan kişinin yorumuna kalmamalı; teste threshold olarak yazılmalı. Spitfire'da editörün Eşikler ve koruma sekmesinde metrik, ifade ve kapsam seçilir; koşu bittiğinde her threshold geçti ya da kaldı olarak işaretlenir ve CI'da koşunun sonucu buna göre belirlenir:

"thresholds": [
  { "metric": "req_duration", "expr": "p(95)<800" },
  { "metric": "req_failed", "expr": "rate<0.01" }
]

Testin ilk dakikası çoğu zaman temsil etmez: bağlantı havuzları dolar, önbellek ısınır, JIT derlenir. Seçenekler → Isınma süresi bu süreyi "ısınma sonrası" bölümünün dışında bırakır ve threshold'lar ısınma sonrasının değerleriyle değerlendirilir. Hedefe geçilip geçilmediğini tek sayıda görmek için Apdex puanı da rapordadır.

6. Küçükten büyüğe koşturun

1. Smoke test: 1–2 VU ile birkaç iterasyon. Akış çalışıyor mu, kontroller geçiyor mu, test verisi doğru mu? Burada hata varsa yük testi yalnızca hatayı çoğaltır.
2. Load test: beklenen yükte, ısınma ile birlikte 10–30 dakika. Sorunuzun cevabı bu koşudur.
3. Stress ya da kırılma noktası: yükü basamak basamak artırıp sistemin nerede bozulduğunu bulun; kapasitenin ne kadar üstünde olduğunuzu bu gösterir (kırılma noktası testi).
4. Spike ve soak: ani bir trafik sıçraması ve saatler süren sabit yük; bellek sızıntısı ve dolan disk ancak uzun koşuda görünür (yük, stres, spike ve soak testi).

Yük üreten makinenin kendisi darboğaz olmamalı: runner'ın işlemcisi doluysa ölçtüğünüz şey hedef değil, runner'dır. Yükü birden çok runner'a ve gerekirse lokasyona bölün. Hedef beklenmedik şekilde zorlanırsa editördeki koruma (guard) yükü kendi p95'ine ve hata oranına bakarak yavaşlatır ya da durdurur.

7. Sonuçları okuyun ve darboğazı bulun

• Önce hatalar: hata oranı yüksekse yanıt süreleri anlamını yitirir. Hataları durum koduna ve mesaja göre gruplayın; 5xx sunucuyu, zaman aşımı kuyruğu ya da bağlantı havuzunu gösterir.
• İstek hızı ile p95'i birlikte okuyun: yük artarken istek/sn yatay giderken p95 yükseliyorsa sistem doymuştur; o noktadaki yük kapasitenizdir. Spitfire'da koşunun grafiklerinde fare bir grafiğin üstünde gezerken bütün grafikler aynı saniyeyi gösterir.
• Adım adım bakın: akışın ortalaması tek bir yavaş adımı gizler. Adımlar tablosu her isteğin p95'ini ayrı gösterir; kademeli yükte aşama tablosu her basamağın sonucunu verir.
• Sunucu tarafını ekleyin: yanıt süresi neyin yavaş olduğunu söylemez. İşlemci, bellek, veritabanı bağlantıları ve trace'ler aynı zaman ekseninde görünürse darboğaz çoğu zaman tek bakışta bulunur (OpenTelemetry ile kök nedene yaklaşma).

Bir şeyi değiştirdikten sonra (indeks, havuz boyutu, önbellek) aynı testi aynı yükle yeniden koşturun ve iki koşuyu karşılaştırın. Aynı anda birden çok şeyi değiştirirseniz hangisinin işe yaradığını bilemezsiniz.

8. Tekrarlanabilir yapın

Tek seferlik bir performans testi, bir sonraki sürüme kadar geçerlidir. İyi bir koşuyu Baseline yap ile referans alın; sonraki koşular ona göre karşılaştırılır ve gerileme bir bulgu olarak görünür. Testi CI/CD hattına koyun ki her sürüm aynı ölçütle ölçülsün (CI/CD'de performans testi) ve canlıdaki kritik uçları sürümler arasında da sentetik izleme ile takip edin (sentetik izleme).

Sık sorulan sorular