Yük testi, stres testi, spike ve soak testi: farkları ve ne zaman hangisi

Algebran Yazılım & Danışmanlık · Yayın 5 Ekim 2026

"Performans testi" tek bir test değil, farklı sorulara cevap veren bir test ailesidir. Beklenen trafiği taşıyor muyuz? Nerede kırılıyoruz? Ani bir kampanya trafiğinden sonra toparlanıyor muyuz? Saatlerce çalışınca bellek sızıntısı var mı? Her soru farklı bir yük şekli ister. Bu rehber dört temel türü, hangi soruya cevap verdiklerini ve nasıl kurulduklarını anlatıyor.

Önce iki kavram: VU ve istek hızı

Yükü iki şekilde tarif edebilirsiniz. Sanal kullanıcı (VU) modelinde belirli sayıda kullanıcı senaryoyu döngüyle koşturur; sistem yavaşlarsa her kullanıcı daha az istek gönderir, yani yük kendiliğinden azalır (kapalı model). İstek hızı modelinde saniyede kaç iterasyon başlayacağını siz belirlersiniz; sistem yavaşlasa da yeni istekler aynı hızda gelmeye devam eder (açık model). Gerçek dünyada kullanıcılar sistemin yavaşladığını bilmeden gelmeye devam ettiği için, kapasite sorularında istek hızı modeli genellikle daha dürüst bir sonuç verir. Kullanıcı yolculuğu ve oturum davranışı önemliyse VU modeli daha doğaldır.

Spitfire'da bunlar yürütücü (executor) tipleriyle seçilir: constant-vus ve ramping-vus VU modeli, constant-arrival-rate ve ramping-arrival-rate istek hızı modelidir.

Yük testi (load test): beklenen trafiği taşıyor mu?

Yük testi sistemi beklediğiniz normal ya da yoğun saat trafiğiyle çalıştırır ve sonucun hedeflerinizi karşılayıp karşılamadığına bakar. Soru "kaç kullanıcıda kırılır" değil, "beklediğimiz yükte p95 500 ms'nin altında ve hata oranı %1'in altında mı" sorusudur. En sık koşturulan test budur: sürüm öncesi, CI'da, gece zamanlanmış koşularda.

Tipik şekil: birkaç dakikalık ısınma (ramp-up), hedef yükte yeterince uzun bir bekleme (hold) ve iniş. Isınma önemlidir: bağlantı havuzları, önbellekler ve JIT derlemesi ilk dakikalarda farklı davranır; ilk saniyeleri ölçüme katmak sonucu bozar. Hedef yükte en az 10–20 dakika kalmak, kısa süreli dalgalanmaları sonuçtan ayırmaya yeter.

"executor": { "type": "ramping-vus",
  "stages": [
    { "duration": "5m",  "target": 300 },
    { "duration": "20m", "target": 300 },
    { "duration": "5m",  "target": 0 }
  ] }

Başarıyı eşiklerle tanımlayın: p(95)<500 ve rate<0.01 gibi. Eşik olmadan yük testi bir grafik üretir, karar üretmez. Yüzdeliklerin nasıl okunduğu: p95 ve p99 rehberi.

Stres testi: beklenenin ötesinde ne olur?

Stres testi yükü beklenen seviyenin üstüne çıkarır ve sistemin zor durumda nasıl davrandığına bakar. İki şey öğrenirsiniz: sistemin sınırı nerede ve sınırı aşınca nasıl bozuluyor. İyi bir sistem zarifçe bozulur: yanıt süresi uzar, bazı isteklere 429 ya da 503 döner, yük azalınca toparlanır. Kötü bir sistem ise zincirleme çöker: zaman aşımları yeniden denemeleri tetikler, kuyruklar dolar, yük kalksa bile servis kendine gelmez.

Stres testinin özel ve ölçülebilir bir biçimi kırılma noktası (breakpoint) testidir: yük basamak basamak artar, her basamak ölçütlere göre değerlendirilir ve ilk geçemeyen basamakta durulur. Sonuç tek bir sayıdır: sistemin ölçütleri karşıladığı en yüksek hız. Ayrıntı: kırılma noktası testi rehberi.

Spike testi: ani yükte ne olur?

Spike testi yükü birkaç saniye içinde çok yükseğe çıkarır, kısa süre orada tutar ve geri indirir. Kampanya başlangıcı, bir push bildiriminin ardından gelen trafik, maç arası ya da bir haber sonrası ani ziyaret bu testin sorusudur. Bakılacak şeyler: autoscaling yeterince hızlı devreye giriyor mu, bağlantı havuzu ve kuyruklar taşıyor mu, spike bittikten sonra yanıt süresi normale ne kadar sürede dönüyor?

Spike için istek hızı modeli daha uygundur, çünkü VU modelinde sistem yavaşlayınca yük de kendiliğinden düşer ve spike'ı yumuşatır. Spike'tan önce ve sonra normal yükte bir süre bırakın; toparlanmayı ancak böyle görürsünüz.

"executor": { "type": "ramping-arrival-rate", "startRate": 100, "timeUnit": "1s",
  "preAllocatedVUs": 100, "maxVUs": 1000,
  "stages": [
    { "duration": "5m",  "target": 100 },
    { "duration": "30s", "target": 1000 },
    { "duration": "3m",  "target": 1000 },
    { "duration": "30s", "target": 100 },
    { "duration": "10m", "target": 100 }
  ] }

Soak testi: saatler sonra ne olur?

Soak (dayanıklılık) testi normal ya da biraz üstü yükü uzun süre, saatlerce tutar. Kısa testlerin göremediği sorunları yakalar: bellek sızıntısı, dolup taşan disk ya da log, kapanmayan bağlantılar, büyüyen tablolar ve indeksler, zamanla bozulan önbellek davranışı, saatlik ya da günlük çalışan batch işlerinin canlı trafikle çakışması. Belirti genellikle yavaş bir eğimdir: p95 ilk saatte 180 ms, dördüncü saatte 260 ms.

Soak testinde yalnız yük tarafına değil sistemin kaynaklarına da bakın: bellek, bağlantı sayısı, disk ve kuyruk derinliği. Sonuçta toplam p95'ten çok, p95'in zaman içindeki eğilimi önemlidir. Koşu süresi lisansa bağlıdır: ücretsiz sürümde 15 dk, Growth planlarında 4 saat, Scale'de 8 saat, Enterprise'da sınırsız.

Hangisi, ne zaman?

Pratikte sıra genellikle şöyledir: önce beklenen yükte bir yük testi (temel çizgi), sonra kırılma noktası testiyle sınırın nerede olduğu, ardından kampanya ya da lansman öncesi spike testi ve büyük sürümlerden önce bir soak testi. Yük testini CI'a ya da gece zamanlamasına alırsanız gerilemeler kullanıcıdan önce size ulaşır: CI/CD'de performans testi.

Hangi türde olursa olsun: dört pratik kural

• Test ortamını tanıyın. Canlıdan küçük bir ortamda alınan sonuç canlının kapasitesi değildir; farkı (pod sayısı, veritabanı boyutu, önbellek) sonuçla birlikte yazın.
• Gerçekçi veri kullanın. Hep aynı kullanıcı ve aynı ürünle yapılan test önbellekten döner. CSV'den farklı kullanıcılar ve rastgele id'ler kullanın.
• Yük üretecini izleyin. Runner'ın CPU'su doluysa ölçtüğünüz gecikme sisteminizin değil yük üretecinin gecikmesidir.
• Bir seferde bir şey değiştirin. İki koşu arasında hem kodu hem yapılandırmayı değiştirirseniz farkın nereden geldiğini bilemezsiniz.

Spitfire ile

Spitfire'da bu dört türün hepsi aynı test tanımıyla kurulur; yalnız yük modeli değişir. Web editöründe senaryo için yürütücüyü (ramping-vus, ramping-arrival-rate…) ve aşamaları seçersiniz, adımlar ve eşikler aynı kalır. Birden çok senaryo yan yana koşabilir: örneğin sabit bir arka plan yükü ve dördüncü dakikada başlayan bir spike senaryosu (startTime). Örnek testler sayfasındaki "Sabit istek hızı ve ani yük" dosyası tam olarak budur.

Koşu penceresi aynı testi farklı bir ölçekte (%50 = VU ve hızların yarısı) ya da farklı bir ortama karşı koşturur; stres için ayrı bir test yazmanız gerekmez. Kırılma noktasını bul bir senaryonun yükünü basamaklarla artırıp kapasiteyi yazar. Biten koşunun bulguları en yavaş adımı, hata türlerini ve yükü izlemeyen istek hızını rakamlarıyla listeler; referans koşuya göre kötüleşme varsa onu da söyler.