Spitfire

p95 nedir? p95, p99 ve yüzdelik gecikme nasıl okunur

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

Performans testi sonuçlarında en çok görülen sayı p95'tir: "p95 420 ms". Bu, isteklerin %95'inin 420 ms ya da daha kısa sürede yanıtlandığı, %5'inin daha uzun sürdüğü anlamına gelir. Bu rehber yüzdeliklerin ne olduğunu, ortalamanın neden yanılttığını, p99'un neden önemli olduğunu ve eşiklerin nasıl yazılacağını anlatıyor.

Yüzdelik (percentile) ne demek?

Bir koşudaki bütün yanıt sürelerini küçükten büyüğe sıraladığınızı düşünün. p50 (medyan) tam ortadaki değerdir: isteklerin yarısı bundan hızlı, yarısı yavaştır. p90 ilk %90'ın sonundaki, p95 ilk %95'in sonundaki, p99 ilk %99'un sonundaki değerdir. Yani p99 = 1200 ms ise her yüz istekten biri 1,2 saniyeden uzun sürmüştür.

Yüzdelikler "tipik kullanıcı ne yaşadı" (p50) ile "kötü şansa denk gelen kullanıcı ne yaşadı" (p95, p99) sorularını ayrı ayrı cevaplar. Gecikme dağılımları neredeyse hiçbir zaman simetrik değildir: çoğu istek hızlıdır, küçük bir kısmı çok yavaştır. Bu uzun kuyruğa (tail latency) bakmadan sistemin kullanıcıya nasıl hissettirdiğini anlayamazsınız.

Ortalama neden yanıltır?

Örnek

On isteğin yanıt süresi (ms), sıralı: 80 · 85 · 90 · 92 · 95 · 98 · 100 · 105 · 900 · 2400

Ortalama 405 ms, medyan (p50) 96,5 ms, en yavaş 2400 ms. Ortalama ne tipik isteği ne de yavaş olanları anlatıyor: on kullanıcıdan sekizi 100 ms civarında yanıt alırken ikisi saniyeler bekledi.

Ortalama birkaç çok yavaş istek yüzünden yukarı çekilir ama yine de kaç kişinin yavaş yanıt aldığını söylemez. Tersine, çok sayıda hızlı istek (örneğin önbellekten dönen yanıtlar ya da hızlıca dönen hatalar) ortalamayı aşağı çekip gerçek bir sorunu gizleyebilir. Bu yüzden performans hedefleri ortalamayla değil, yüzdeliklerle yazılır.

p95 mi, p99 mu?

İkisi farklı şeyler söyler. p95 çoğu kullanıcının deneyimini kapsayan, kararlı bir ölçüdür; az sayıda örnekle de anlamlı olur ve gürültüye az tepki verir. Sürüm karşılaştırmaları ve CI eşikleri için iyi bir başlangıçtır. p99 kuyruğu gösterir: GC duraklamaları, kilit beklemeleri, connection pool'da sıra, zaman aşımına yaklaşan çağrılar. Kuyruktaki sorunlar genellikle yük arttıkça ilk görünen belirtilerdir.

p99'u küçümsemeyin: bir sayfa ya da bir API çağrısı arkada birçok servise gidiyorsa, kullanıcının en az bir yavaş çağrıya denk gelme olasılığı hızla artar. Birbirinden bağımsız 20 çağrının her biri için p99 aşılma olasılığı %1 ise, en az birinin aşılma olasılığı 1 − 0,99²⁰ ≈ %18'dir. Yani arka uçtaki p99, kullanıcı tarafında neredeyse p80 gibi hissedilir.

Pratik bir kural: hedefi p95 ile koyun, p99'a da gevşek bir üst sınır koyun. p99'u yorumlarken örnek sayısına dikkat edin: 200 istekte p99, en yavaş iki isteğin belirlediği bir sayıdır.

Yüzdelikleri okurken dört tuzak

  • Yüzdeliklerin ortalaması alınmaz. İki runner'ın ya da iki zaman diliminin p95'ini toplayıp ikiye bölmek bir p95 vermez. Doğru p95 bütün örneklerden (ya da birleştirilebilen histogramlardan) hesaplanır.
  • Toplam p95 adımları gizler. Hızlı bir listeleme isteği çok, yavaş bir ödeme isteği azsa genel p95 iyi görünür. Kritik adımlara ayrı bakın ve ayrı eşik koyun.
  • Hatalar hızlı olabilir. Hemen dönen 500'ler p95'i iyileştirir. Gecikmeyi her zaman hata oranıyla birlikte okuyun.
  • Kapalı model kuyruğu gizleyebilir. VU modelinde sistem yavaşlayınca kullanıcılar daha seyrek istek gönderir; sıradaki istekler hiç gönderilmediği için ölçülmez. Kapasite sorularında istek hızı (arrival-rate) modeli bu etkiyi azaltır.

Eşik nasıl yazılır?

Bir eşik, yüzdeliği bir karara çevirir: "p95 500 ms'nin altında ve hata oranı %1'in altındaysa geçti". Hedefi kullanıcı deneyiminden ve iş gereksiniminden türetin, mevcut sonuçtan değil; mevcut sonuca göre yazılan eşik yalnız kötüleşmeyi yakalar. Sonra bunu bir referans koşuyla karşılaştırmayla tamamlayın: eşik kırılmasa bile p95'in %20 artması bir sinyaldir.

Her endpoint'e aynı hedefi koymak da doğru değildir. Kullanıcının beklediği bir arama ile arka planda çalışan bir rapor üretimi farklı sınırlar ister; ödeme gibi kritik bir adım genellikle en sıkı hedefi alır.

Örnek

Ürün listeleme: p95 < 300 ms · Arama: p95 < 500 ms · Ödeme: p95 < 800 ms, p99 < 2 sn · Tüm istekler: hata oranı < %1. Bu değerler bir başlangıç örneğidir; kendi kullanıcı deneyimi hedeflerinizden türetin.

Spitfire ile

Spitfire koşu sırasında p50, p90, p95 ve p99'u saniye saniye canlı gösterir; adım ve lokasyon kırılımlarıyla. Eşikler test tanımında durur ve bir koşuyu geçti/kaldı sonucuna çevirir; bir adıma, senaryoya ya da lokasyona daraltılabilir:

"thresholds": [
  { "metric": "req_duration", "expr": "p(95)<500" },
  { "metric": "req_duration", "expr": "p(99)<1500" },
  { "metric": "req_duration", "filter": { "step": "checkout" }, "expr": "p(95)<300" },
  { "metric": "req_failed", "expr": "rate<0.01" }
]

Biten koşunun bulguları en yavaş adımı ve uzun gecikme kuyruğunu rakamlarıyla yazar; bir koşuyu referans seçerseniz sonrakiler p95, p99, hata oranı ve istek hızıyla onunla karşılaştırılır. Aynı eşikler CI'da çıkış koduna dönüşür: CI/CD'de performans testi. Sistemin hangi yükte p95 hedefini kaçırdığını bulmak için: kırılma noktası testi.

Spitfire tek komutla Docker'a ya da Kubernetes'e kurulur; ücretsiz sürümde bütün test özellikleri ve protokoller açıktır.

Kurulum rehberiÜcretsiz anahtar al