Kırılma noktası (breakpoint) testi: sistemin kapasitesini bulmak

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

"Sistemimiz ne kadar yük kaldırır?" sorusunun cevabı bir grafik değil, bir sayıdır: belirlediğiniz ölçütleri (örneğin p95 500 ms'nin altında, hata oranı %1'in altında) karşılayabildiği en yüksek istek hızı. Kırılma noktası testi bu sayıyı yükü basamaklarla artırarak bulur. Bu rehber testi nasıl kuracağınızı, sonucu nasıl okuyacağınızı ve kapasite planlamasına nasıl taşıyacağınızı anlatıyor.

Neden basamaklı yük?

Yükü sürekli ve doğrusal artırırsanız (rampa), grafikte bir yerde gecikmenin yükseldiğini görürsünüz ama hangi yükte olduğunu söylemek zordur: sistem her an değişen bir yük altındadır, kuyruklar ve önbellekler dengeye gelmeye fırsat bulamaz. Basamaklı yükte her basamak kısa bir geçiş ve ardından sabit bir bekleme (hold) içerir. Her basamak yalnız kendi beklemesindeki rakamlarla değerlendirilir; böylece "200/sn'de p95 290 ms" gibi kesin bir ifade kurabilirsiniz.

Testi kurarken

• Ölçütü önce yazın. Kırılma "sistem çöktü" demek değildir; "ölçütü kaçırdı" demektir. p95 hedefi ve hata oranı sınırı olmadan bulunan sayı yoruma açıktır. Yüzdelikler için: p95 ve p99 rehberi.
• İstek hızıyla artırın. VU sayısını artırmak yerine saniyedeki iterasyonu artırmak, sistem yavaşladığında yükün kendiliğinden düşmesini engeller; sonuç doğrudan "saniyede kaç işlem" olarak okunur.
• Başlangıç, artış ve üst sınırı makul seçin. Bildiğiniz rahat bir yükten başlayın; artışı, bulunan sayının işinize yarayacağı çözünürlükte tutun (çok küçük artış testi uzatır, çok büyük artış kapasiteyi kaba bulur).
• Tek senaryo, gerçekçi karışım. Kapasite karışıma bağlıdır: yalnız listeleme isteğiyle bulunan sayı ödeme ağırlıklı bir trafikte tutmaz. Senaryodaki adım oranlarını gerçek trafiğe yakın tutun.
• Yük üretecini sınır yapmayın. Yeterli VU ve runner ayırın; yoksa bulduğunuz sınır sistemin değil yük üretecinin sınırıdır.

Sonucu okumak

Kırılan basamakta neyin kırıldığına da bakın. Yalnız gecikme yükseldiyse sistem doymuş ve istekler sırada bekliyordur. Hatalar başladıysa hangi tür olduğu önemlidir: 429 bir hız sınırına, 503 bir yük dengeleyiciye ya da devre kesiciye, zaman aşımları dolan bir havuza işaret edebilir. İstek hızı yükü izlemeyi bıraktıysa (hedef 230/sn, gerçekleşen 205/sn) sistem gelen işi artık karşılayamıyordur.

Kırılma noktası dışarıdan ölçülen bir sayıdır; içeride hangi kaynağın doyduğunu söylemez. Bunun için sistemin kendi metriklerine bakmanız gerekir: CPU, bellek, connection pool, kuyruk derinliği. Testi farklı günlerde tekrarlamak da önemlidir: aynı ortamda iki koşu arasında birkaç yüzdelik fark normaldir, büyük farklar ortamın değiştiğini gösterir.

Ne zaman ve ne sıklıkla?

Kırılma noktası testi bir kez yapılıp unutulacak bir test değildir. Kapasiteyi değiştiren her şeyden sonra tekrarlayın: büyük bir sürüm, yeni bir bağımlılık, veritabanı şemasında ya da indekslerde değişiklik, altyapı boyutunda değişiklik, beklenen trafiği artıracak bir kampanya. Sonuçları tarihleriyle saklayın; kapasitenin sürümler boyunca nasıl değiştiğini görmek, tek bir ölçümden çok daha fazlasını söyler. Kampanya öncesinde hedef trafiğin en az birkaç basamak üstüne çıkın, tahminlerin şaşabileceğini hesaba katın.

Kapasiteden plana

Bulunan sayı bir ortam ve bir örnek (pod, sunucu) sayısı için geçerlidir. Hedef trafik için kaç örnek gerektiğini kestirmek mümkündür ama bu bir tahmindir ve varsayımlara dayanır: örneklerin kırılma noktasına kadar doğrusal ölçeklendiği ve paylaşılan bağımlılıkların (veritabanı, önbellek, kuyruklar, dış servisler) önce doymadığı. Gerçek kapasite geçen ve geçemeyen basamak arasında olduğundan tahmin de bir aralık olarak verilmelidir. Doğrusal ölçekleme ölçülmediği sürece, planı daha fazla örnekle yapılmış ikinci bir testle doğrulayın.

Spitfire ile

Spitfire'da ayrı bir test yazmanız gerekmez. Çalıştır penceresinde Kırılma noktasını bul'u seçin; bir senaryonun yükü başlangıç, artış ve en çok değerleriyle basamak basamak artar (her basamak 10 sn geçiş ve bir bekleme). Her basamak yalnız kendi rakamlarıyla, o basamağın p95'i ve hata oranıyla değerlendirilir. İlk geçemeyen basamak koşuyu durdurur ve koşu sayfası kapasiteyi basamak tablosu ve nedeniyle yazar: "200 iterasyon/sn'de ölçütleri karşıladı, 230'da karşılayamadı". Gecikme iyiyken sanal kullanıcı yetmediği için durduysa, bunun sistemin sınırı olmadığını söyler. Testin kendisi değişmez.

Biten kırılma noktası koşusunun sayfasındaki Kapasite planlama kartına koşu sırasında sistemi kaç örneğin karşıladığını ve planlanan eşzamanlı kullanıcı sayısını girersiniz; kart "≈ 18 örnek (aralık 15–18)" gibi bir cevap verir. Kart bunun ölçüm değil tahmin olduğunu ve dayandığı her varsayımı yanında yazar; güven düzeyi hiçbir zaman "orta"nın üstüne çıkmaz, çünkü doğrusal ölçekleme ölçülmemiştir.

Sisteminizin OpenTelemetry verisi bağlıysa, kırılan basamakta en çok sıçrayan kaynaklar (CPU, bellek, connection pool, kuyruk) bir önceki basamağa göre sıralanır ve bulguda "aynı anda" diye yazılır: OpenTelemetry ile kök nedene yaklaşma.