Kenapa P95 Lebih Penting Dari Average Latency

Pas pertama kali belajar benchmarking API, biasanya orang fokus ke angka ini:

Average Response Time

Kelihatannya masuk akal.

Kalau average API:

120ms
200ms
300ms

Berarti API cepat kan?

Belum tentu 😭

Karena average sering banget “bohong”.

Dan di dunia backend/performance engineering, biasanya orang lebih peduli sama:

Terutama:

P95 latency

Masalah Dengan Average

Misalnya ada 100 request.

99 request:

100ms

1 request:

10 detik

Average-nya jadi:

199ms

Kelihatannya masih bagus.

Padahal ada user yang nunggu:

10 DETIK 😭

Dan itu biasanya:

checkout gagal
user refresh
mobile timeout
rage click
complain “webnya lemot”

Average gak nunjukin penderitaan user paling apes.

Apa Itu P95?

P95 artinya:

95% request selesai lebih cepat dari angka tersebut.

Contoh:

P95 = 800ms

Artinya:

95% request selesai di bawah 800ms
5% sisanya lebih lambat

Nah ini jauh lebih representatif buat real-world experience.

Kenapa P95 Penting

Karena user gak peduli average.

User cuma peduli:

“pas gw buka tadi lemot apa gak?”

Dan biasanya problem production muncul di:

tail latency
request random lambat
query spike
lock database
cache miss
GC pause
external API lambat

Hal-hal beginian sering gak kelihatan di average.

Contoh Benchmark Bohong

Misalnya hasil load test:

MetricResultAverage220msP50140msP952.4sP995.8s

Kalau cuma lihat average:

“wah cepat nih”

Padahal:

banyak user kena 2–5 detik
UX sebenarnya jelek
API gak stabil

Ini sering kejadian 😭

P50, P95, P99 Itu Apa?

P50

Median.

50% request lebih cepat dari angka ini.

Biasanya nunjukin “normal case”.

P95

Tail latency ringan.

Biasanya dipakai buat:

SLO
production target
monitoring

Karena cukup representatif buat mayoritas user.

P99

Extreme worst-case.

Bagus buat:

infra analysis
spike analysis
debugging aneh
reliability engineering

Tapi biasanya terlalu sensitif buat KPI utama.

Kenapa Tail Latency Bahaya

Yang bikin sistem terasa lemot sering bukan average.

Tapi:

spike random

Misalnya:

query PostgreSQL kena sequential scan
Redis miss
external API timeout
serializer nested terlalu dalam
cold cache
CPU spike
lock database

99 request mungkin cepat.

Tapi beberapa request random bisa:

3 detik
5 detik
timeout

Dan itu cukup bikin UX terasa jelek.

Analogi Jalan Tol

Bayangin jalan tol.

90 mobil lancar:

80 km/h

10 mobil kena macet total:

5 km/h

Average kecepatan masih lumayan.

Tapi buat orang yang kena macet?

perjalanan tetep nyiksa 😭

Itulah kenapa tail latency penting.

Di Dunia Nyata, P95 Biasanya Jadi Target

Contoh target production:

MetricTargetP95 API< 500msP99 API< 1sError Rate< 1%

Karena ini lebih dekat ke pengalaman user nyata.

Kenapa P95 Bisa Naik?

Biasanya karena:

query database lambat
N+1 query
external API
lock contention
cache miss
payload terlalu besar
pagination buruk
garbage collection
CPU throttling
disk I/O

Makanya pas benchmarking:

jangan cuma lihat average 😭

Tools Buat Lihat P95

wrk

wrk -t4 -c50 -d30s https://api.example.com

Biasanya keluar:

50% 120ms 75% 220ms 90% 500ms 95% 800ms 99% 1.4s

k6

k6 juga bagus banget.

Contoh:

export const options = { thresholds: { http_req_duration: [ "p(95)<500" ], }, };

Artinya:

P95 harus di bawah 500ms

Kalau gagal → test fail 🔥

Jadi Metric Mana Yang Harus Dipakai?

Menurut gw:

MetricBuat ApaAverageoverview cepatP50normal performanceP95real user experienceP99worst-case debugging

Kalau harus pilih satu:

pilih P95

Karena paling balance antara:

realism
stability
usability

Penutup

Average latency itu gampang menipu.

Kadang average kelihatan bagus:

200ms

Padahal banyak user kena:

3–5 detik

Makanya di production engineering, orang lebih sering fokus ke:

P95
P99
tail latency

Karena performa sistem bukan soal:

“berapa cepat request tercepat”