Yük testi sonucunu okuma ve darboğazı daraltma

Sonucu okumadan önce: test geçerli miydi?

Analiz, testin güvenilir olup olmadığını sorgulayarak başlar. Yük üretici makinenin işlemcisi ya da ağı dolduysa gördüğünüz yavaşlık sistemin değil ölçüm düzeneğinin eseridir. Ortamın üretimden çok farklı olması, test verisinin tüm kullanıcılar için aynı olması, ısınma döneminin hesaba katılmaması ve bekleme süresi olmadan gerçek dışı yoğun yük uygulanması sonucu geçersiz kılar.

İlk kontrol listesi şöyledir: • Yük üretici kaynakları test boyunca sınıra yaklaştı mı? • Hata cevapları başarılı sayıldı mı; doğrulama var mıydı? • Test süresi, sistemin kararlı hâle gelmesine yetti mi? • Koşu boyunca başka bir yük (yedekleme, zamanlanmış iş) çalıştı mı? • Önceki koşuyla karşılaştırma için aynı koşullar sağlandı mı?

Bu soruların yanıtı olumsuzsa, sonuçları yorumlamak yerine testi düzeltip yeniden koşmak daha doğrudur. Güvenilmez veriden çıkarılan ayrıntılı bir yorum, yanlış bir optimizasyona yol açabilir.

Yanıt süresi: ortalamaya değil dağılıma bakın

Ortalama yanıt süresi tek başına yanıltıcıdır, çünkü çok hızlı çoğunluk, birkaç çok yavaş isteği gizleyebilir. Yüzdelik dilimler (p95, p99 gibi) isteklerin belirli bir oranının hangi süreden hızlı tamamlandığını söyler. Yüksek yüzdelik dilimlerin ortalamadan belirgin uzaklaşması, bazı isteklerin ciddi biçimde beklediğini, yani kuyruk oluştuğunu gösterir.

Dağılım okumanın pratik adımları: • Zaman içinde yüzdelik dilim eğrisini çizin; yük arttıkça nerede kıvrıldığını bulun • İstek tipine göre ayırın: arama, listeleme ve ödeme aynı ortalamayı paylaşmaz • En yavaş uç noktaları sıralayın ve her birinin yük altında nasıl değiştiğine bakın • Başarılı ve başarısız yanıtların sürelerini ayrı değerlendirin; hızlı dönen hata, ortalamayı iyi gösterir

Kıvrılma noktası, sistemin kapasitesinin pratik sınırıdır. Yük arttığı hâlde işlem hacmi (saniyedeki tamamlanan istek) artmayı bırakıyor ve yanıt süresi hızla büyüyorsa sistem doygunluğa ulaşmıştır. Bu noktadan sonra eklenen yük yalnızca kuyruğu uzatır.

Hata türleri neyi işaret eder?

Hata oranı da türüne göre okunmalıdır. Zaman aşımı, sunucunun yanıtı süresi içinde veremediğini gösterir ve çoğunlukla kapasite ya da kilitlenme sorunudur. Bağlantı reddedildi hataları, sunucu ya da önündeki bileşenin bağlantı limitine ulaştığını düşündürür. Sunucu tarafı uygulama hataları (5xx sınıfı) kodun, bağımlı servisin ya da veritabanının yük altında bozulduğunu gösterir. İstemci hataları ise (4xx sınıfı) çoğunlukla test senaryosunun hatalı kurulduğuna işaret eder: süresi dolmuş oturum, tekrarlanan kayıt, eksik parametre.

Hataların zamanlaması da ipucu verir. Hatalar yük arttıkça kademeli büyüyorsa kaynak yetersizliği, belirli bir anda patlıyorsa bir havuzun dolması ya da bir zamanlanmış işin başlaması olabilir. Hata sıklığını isteğin türüyle çaprazlamak, tüm sistemin mi yoksa belirli bir uç noktanın mı etkilendiğini ayırır.

Grafana k6 kullanıyorsanız yerleşik metrikler süreyi bölerek verir: bekleme süresi sunucu işleme süresini, bağlantı kurma süresi ağ ve bağlantı sorununu işaret eder. Gatling gibi diğer araçların raporlarında da benzer ayrımlar vardır.

Darboğazı daraltma yöntemi

Darboğaz, sistemin işlem hacmini sınırlayan en yavaş halkadır. Bulmak için tahmin yerine sistematik daraltma yapılır: • Belirtiyi tanımlayın: hangi yük seviyesinde, hangi isteklerde yavaşlama başlıyor? • Katmanı belirleyin: istemci, ağ, uygulama sunucusu, önbellek, veritabanı, dış servis • Aynı zaman aralığında kaynak göstergelerini (işlemci, bellek, disk, ağ, bağlantı havuzları) bu eğriye yerleştirin • Tek değişken değiştirerek varsayımı sınayın ve tekrar ölçün

Örnek bir akış: ödeme isteğinin yanıtı yük arttıkça uzuyor, uygulama sunucusunun işlemcisi sınıra yaklaşmıyor ama veritabanı bağlantı havuzunun dolu olduğu görülüyor. Bu durumda uygulama koduna dokunmadan önce havuz boyutunu ve uzun süren sorguları incelersiniz. Uzun süren bir sorgu havuzdaki bağlantıları meşgul tutuyorsa asıl sorun sorgudur. Havuzu büyütmek geçici rahatlama sağlar, ancak veritabanına binen yükü artırabilir; bu yüzden önce sorgu planına ve indekslere bakılır.

Tek katmanı düzeltince darboğaz bir sonraki halkaya kayar. Bu doğaldır; amaç, hedef yük için yeterli kapasiteye ulaşana kadar bu döngüyü ölçerek tekrarlamaktır.

Sık görülen darboğaz kalıpları

Belirti ile olası neden ilişkisi çoğu zaman şu kalıplara oturur:

Belirti: İşlemci yüksek, yanıt süresi artıyor. Olası neden: Verimsiz kod yolu, aşırı serileştirme ya da şifreleme maliyeti.

Belirti: İşlemci boşta ama yanıt yavaş. Olası neden: Dış servis, veritabanı ya da kilit beklemesi; iş parçacıkları bekliyor.

Belirti: Bellek zamanla artıyor, belirli aralıklarla duraksamalar var. Olası neden: Bellek sızıntısı ya da çöp toplama baskısı.

Belirti: Yük arttıkça bağlantı hataları artıyor. Olası neden: Bağlantı havuzu ya da işletim sistemi limitleri.

Belirti: Yalnız belirli bir uç nokta yavaş. Olası neden: Eksik dizin, N+1 sorgu deseni ya da büyük yanıt boyutu.

Belirti: Test başında yavaş, sonra düzeliyor. Olası neden: Önbellek ya da havuz ısınması.

Bunlar tahmin listesidir, hüküm değildir. Her kalıp, ilgili izleme verisiyle doğrulanmadan çözüm uygulanmamalıdır. Uygulama izleme araçları ve veritabanı sorgu planları bu doğrulamada en değerli veri kaynaklarıdır.

Raporlama ve kapasite planlaması

Performans raporu karar veren kişiye hitap etmelidir. Rapor test amacını, ortamı, senaryoyu, yükü, ölçülen sonuçları, bulunan darboğazı ve önerilen aksiyonu içerir. Sonuç cümlesi 'sistem belirtilen yükü hedef yanıt süresi içinde taşıdı' ya da 'şu noktada bozuldu, nedeni şudur' gibi doğrudan olmalıdır.

Kapasite planlaması, test bulgusundan gelecek büyümeye geçiştir. Sistemin bozulma noktası ile beklenen kullanıcı hacmini karşılaştırarak hangi dönemde ek kaynak ya da iyileştirme gerekeceğini öngörürsünüz. Kampanya, sezon ve yeni ürün çıkışı gibi öngörülebilir zirveler önceden senaryolaştırılmalıdır. Tek seferlik rapor yerine, her önemli sürüm için aynı senaryoyu tekrarlayıp eğilimi izlemek performans gerilemesini erken yakalar.

Bulgu kayıtlarını paylaşılabilir tutun: hangi koşuda ne bulundu, ne düzeltildi, düzeltme etkili oldu mu. Bu kayıt, bir sonraki ekibin aynı tuzağa düşmesini önler.

Mindset programlarında bu beceriyi nerede çalışırsınız?

Mindset kataloğundaki Performance Testing (JMeter, k6) programının sonuç analizi ve darboğaz tespiti ile performans raporu ve kapasite planlaması modülleri, bu sayfadaki yöntemi uygulamalı ele alır. Yük ve Stres Testi (Gatling) programı ise metriklerin yorumlanması, darboğaz analizi ve iyileştirme ile sürekli performans testi modüllerini içerir.

Bu programlar da performans mühendisleri, test otomasyon uzmanları ve sistem kapasitesinden sorumlu geliştirme ekipleri için uygundur. Kurumsal ekipler açısından değeri, ortak bir rapor formatı ve darboğaz daraltma yöntemi kazandırmasıdır; ekip içi değerlendirmeler tahminden ölçüme taşınır.