p95 ve p99 neden ortalama gecikmeden daha önemlidir?

Bir API’nin ortalama yanıt süresinin düşük olması çoğu zaman “her şey yolunda” algısı yaratır. Dashboard’ta ortalama latency yeşil görünür, SLA’ler kâğıt üzerinde sağlanır ve sistem sağlıklı kabul edilir. Ancak production ortamlarında yaşanan problemler neredeyse hiçbir zaman “ortalama kullanıcı” üzerinden ortaya çıkmaz.

Gerçek sorunlar her zaman uçlarda yaşanır.

Bu nedenle yüksek hacimli ve kritik sistemlerde performansı anlamak için ortalama (mean) yerine percentile latency kavramlarına bakmak gerekir. Özellikle p95 ve p99, sistemin gerçek davranışını anlamak için en kritik iki metriktir.

p95, isteklerin %95’inin bu sürenin altında tamamlandığını; p99 ise %99’unun bu sınırın altında kaldığını ifade eder. Yani p99, sistemin “en kötü ama hâlâ kabul edilen” davranışını temsil eder.

Production’da kullanıcı şikâyetleri, timeout’lar ve zincirleme hatalar tam olarak bu %1–5’lik dilimde ortaya çıkar.

Ortalama neden yanıltıcıdır?

Ortalama değerler uç değerleri maskeler. Bir API’nin 100 isteğinden 99’u 50 ms’de, 1’i 5 saniyede dönüyorsa:

Ortalama: ~100 ms
Gerçek deneyim: Bazı kullanıcılar için sistem “donuyor”

Bu senaryoda ortalama latency oldukça iyi görünürken p99 değeri 5 saniyeye fırlar. İşte bu fark, production sistemlerinde “dashboard yeşildi ama müşteri arıyor” anlarının temel sebebidir.

Özellikle API gateway, IAM, payment, scoring veya entegrasyon katmanlarında bu etki katlanarak büyür. Çünkü tek bir yavaş istek downstream sistemleri de bloke eder.

p95 mi, p99 mu? Hangisi ne zaman anlamlı?

p95 genellikle sistemin genel sağlığını ölçmek için kullanılır. Çoğu kullanıcı için deneyimin ne durumda olduğunu gösterir. Ancak kritik sistemlerde p95 tek başına yeterli değildir.

p99 ise daha az sayıda isteği kapsar ama operasyonel riskleri çok daha iyi yansıtır. Çünkü:

Timeout’lar
Circuit breaker tetiklenmeleri
Retry fırtınaları
Thread pool saturation

neredeyse her zaman p99 bandında başlar.

Finans, sigorta ve kamu sistemlerinde p99 değerinin kontrolsüz yükselmesi, zincirleme servis kesintilerine yol açabilir. Bu yüzden p99, özellikle API gateway ve edge katmanlarında erken uyarı sinyali olarak ele alınmalıdır.

API gateway perspektifinden p99

API gateway’ler genellikle performans sorunlarının ilk suçlandığı bileşendir. Ancak pratikte gateway çoğu zaman problemi yaratan değil, görünür kılan katmandır.

Gerçek hayatta sık gördüğümüz senaryolar şunlardır:

Downstream servislerden biri nadiren ama çok yavaş cevap verir
IAM veya token validation arada sırada external dependency’ye takılır
Cache miss oranı düşük görünür ama p99 cache miss’ler pahalıdır
Rate limit’e yaklaşan trafikte latency dramatik artar

Bu durumlarda ortalama değerler stabil kalırken p99 aniden bozulur. Gateway tarafında p99 metriğini izlemek, problemi application ekipleri fark etmeden önce görmeyi sağlar.

SLA ve SLO tanımlarken p99 nasıl kullanılmalı?

Gerçekçi SLA’ler ortalama üzerinden tanımlanmaz. Olgun organizasyonlar şu yaklaşımı benimser:

SLA: p95 veya p99 üzerinden
SLO: Daha sıkı percentile hedefleriyle
Error budget: p99 ihlalleri üzerinden

Örneğin:

“API yanıt süresi p99 < 800 ms”
“Aylık error budget p99 timeout’ları üzerinden hesaplanır”

Bu yaklaşım, performansın kâğıt üzerinde değil gerçek kullanıcı deneyimi üzerinden yönetilmesini sağlar.

Sonuç

p95 ve p99 metrikleri, sistemin ne kadar hızlı olduğunu değil, ne kadar güvenilir olduğunu gösterir. Ortalama latency yalnızca iyi giden anları anlatır; percentile’lar ise kötü günleri.

Eğer production’da çalışan, yüksek trafik alan ve zincirleme bağımlılıkları olan sistemler tasarlıyorsanız, p99 sizin için bir metrik değil, bir refleks olmalıdır.

Çünkü kullanıcılar ortalamayı yaşamaz. Sisteminizin en yavaş anını yaşarlar.

Sıkça sorulan sorular

p95 ve p99 latency neden ortalamadan daha önemlidir?

Ortalama latency, yüksek ve düşük değerleri birlikte hesapladığı için gerçek kullanıcı deneyimini maskeleyebilir. p95 ve p99, kullanıcıların %95 ve %99’unun yaşadığı en kötü süreyi gösterir. Özellikle e-ticaret ve finans gibi sektörlerde, en yavaş %1–5’lik dilim genellikle en değerli müşterileri (yüksek işlem hacmi, karmaşık sorgular) temsil eder.

p99 latency nasıl ölçülür?

p99 latency ölçümü için histogram tabanlı metrik toplama araçları kullanılır. Belirli bir zaman penceresi içindeki tüm isteklerin response süreleri sıralanır ve 99’uncu percentile değeri alınır. Doğru ölçüm için yeterli sample size, uygun bucket aralıkları ve client-side ile server-side ölçüm ayrımı önemlidir.

İdeal p99 latency değeri ne olmalıdır?

İdeal p99 değeri use case’e ve SLA gereksinimlerine bağlıdır. API gateway katmanı için genellikle 500 ms altı hedeflenir. Microservice’ler arasındaki iç çağrılar için 100 ms altı beklenir. Veritabanı sorguları için 50 ms altı idealdir. Önemli olan, mutlak değer kadar p50 ile p99 arasındaki farkın (tail latency amplification) kabul edilebilir seviyede olmasıdır.

Latency percentile’larını iyileştirmek için hangi teknikler kullanılır?

Tail latency iyileştirme teknikleri: connection pooling ile bağlantı overhead’ini azaltma, hedged request pattern ile yavaş backend’leri bypass etme, circuit breaker ile cascade failure’ı önleme, adaptive timeout’lar ile dinamik deadline yönetimi ve cache stratejileri ile hot path optimizasyonu. Ayrıca GC tuning ve JIT warmup gibi runtime optimizasyonları da p99’u önemli ölçüde etkiler.