<

Yük Testi Raporunu Okumak: p95, Hata Oranı ve Doyma Noktası

Yük testi raporlarının çoğu okunmadan dosyalanıyor. Sebebi de anlaşılır: rapor yirmi metrikle açılıyor, hiçbiri "sistem yeterli mi" sorusunu doğrudan cevaplamıyor. 16 yıldır yaptığımız iş şu: raporu üç soruya indirgemek.

Birinci soru: ortalama değil, p95

Ortalama yanıt süresi neredeyse hiçbir şey anlatmaz. 100 isteğin 95'i 80 ms, beşi 9 saniye sürüyorsa ortalama 500 ms civarı çıkar ve rapor "iyi" görünür. Oysa o beş istek, muhtemelen sepeti dolu olan beş kullanıcıdır.

Bizim kabul kriterimiz genelde şöyle kurulur: okuma uçlarında p95 < 300 ms, yazma uçlarında p95 < 800 ms, p99 ise p95'in en fazla üç katı. Son madde önemli, çünkü p99'un p95'ten kopması neredeyse her zaman bir kaynak çekişmesine — bağlantı havuzu, kilit veya çöp toplama — işaret eder.

Ortalama yanıt süresi ile p95 ve p99 ölçümlerinin karşılaştırması ve kabul kriterleri.
Ortalama neredeyse hiçbir şey anlatmaz.

İkinci soru: hata oranı ne zaman kırıldı

Raporda aramanız gereken şey en yüksek başarılı istek sayısı değil, hata oranının %1'i geçtiği eşzamanlı kullanıcı sayısı. Buna doyma noktası diyoruz. Doyma noktasının altında sistem lineer davranır; üstünde gecikme hızla tırmanır ve kuyruklar dolmaya başlar.

Pratik kural: üretim kapasitenizi doyma noktasının %60–70'ine göre planlayın. Çünkü gerçek trafik testteki gibi düzgün dağılmaz; kampanya, bildirim veya bir haber tek dakikada tepe yapar.

Üçüncü soru: darboğaz nerede

Test sırasında uygulama sunucusu, veritabanı ve önbelleğin CPU/bellek grafiklerini yan yana koymadan rapor tamamlanmış sayılmaz. Tipik olarak şu üç resimden birini görürsünüz:

  • Uygulama CPU'su %90, veritabanı rahat. Genelde serileştirme veya N+1 sorgu değil, gereksiz hesaplama. Profil çıkarın.
  • Veritabanı CPU'su yüksek, uygulama boş. Eksik indeks veya N+1 sorgu. Yavaş sorgu kaydını açıp en üstteki beş sorguya bakın; genellikle sorunun %80'i oradadır.
  • İkisi de rahat, gecikme yüksek. Bağlantı havuzu, dış servis çağrısı veya kilit bekleme. En çok atlanan ve en pahalı senaryo bu.
Yük testinde görülen üç tipik darboğaz resmi ve olası nedenleri.
Grafikleri yan yana koymadan rapor tamamlanmış sayılmaz.

Testi gerçekçi kurmak

Bir yük testi ancak senaryosu kadar değerli. Tek bir uca 10 bin istek atmak kapasite ölçmez, önbellek ölçer. Bizim kurduğumuz senaryolar üç şeyi içerir: gerçek kullanıcı akışı (giriş → liste → detay → işlem), kullanıcılar arasında farklılaşan veri (aynı ID'yi çekmek önbelleği yapay olarak ısıtır) ve adım adım artan yük profili. Isınma süresi olmadan başlayan testler, ilk saniyelerdeki soğuk önbellek yüzünden gereksiz alarm üretir.

Bir de şunu not edelim: testi üretim veritabanının bir kopyası üzerinde çalıştırın. Bin satırlık geliştirme veritabanında her sorgu hızlıdır; sorun iki milyon satırda başlar.

Rapordan çıkan tek sayfa

Müşteriye teslim ettiğimiz özet hep aynı biçimde: mevcut doyma noktası, önerilen üretim kapasitesi, bulunan üç darboğaz ve her biri için tahmini iş yükü. Yirmi sayfalık grafik ekte durur; kararı veren bu tek sayfa olur.

Sık yapılan üç ölçüm hatası

  • Test aracını yetersiz makinede çalıştırmak. Yük üreten taraf doyuma ulaştığında ölçtüğünüz şey sisteminiz değil, test makinenizin ağ yığını olur. Test sırasında istemci tarafı CPU'sunu da izleyin.
  • Üretim ile aynı olmayan ortamda test etmek. Farklı örnek boyutu, farklı disk türü veya önbellek katmanının olmaması, sonucu ölçüm değil tahmin haline getirir. Ortam farklıysa bunu rapora yazın.
  • Sadece tepe yükü ölçmek. Sistemin uzun süreli yükte nasıl davrandığı ayrı bir sorudur. Bellek sızıntısı ve bağlantı birikmesi otuz dakikalık testlerde görünmez; sekiz saatlik dayanıklılık testinde görünür.

Testten sonra ne yapılır

Yük testinin değeri, bulguların düzeltilip testin tekrarlanmasıyla ortaya çıkıyor. Tek turluk testler bir fotoğraf verir; karşılaştırmalı turlar ise iyileştirmenin işe yarayıp yaramadığını gösterir. Bizim akışımız şu: temel ölçümü al, en yüksek etkili tek darboğazı düzelt, aynı senaryoyu tekrar çalıştır. Aynı anda üç şeyi düzeltirseniz hangisinin işe yaradığını bilemezsiniz — ve bir sonraki sefer aynı kararı yeniden vermek zorunda kalırsınız.

Son olarak, kabul kriterlerini teslim tarihinden önce yazılı hale getirin. "Sistem hızlı olacak" bir kriter değil; "500 eşzamanlı kullanıcıda okuma p95 < 300 ms, hata oranı < %0,5" bir kriterdir ve tartışmayı bitirir.

Kampanya, sezon açılışı veya yeni bir entegrasyon öncesinde sisteminizin nereye kadar dayandığını bilmek istiyorsanız, iletişim sayfamızdan bize ulaşın. Yük testi, sürprizi ücretsiz hale getiren en ucuz yatırımlardan biri.

📅 Yayınlanma:  ·  Yakup Zengin