Jelaskan tail latency

Pertanyaan

Kenapa sebagian kecil request jauh lebih lambat dari sisanya, dan kenapa fan-out membuat bagian kecil itu menjadi masalah banyak user?

Setelah baca ini, kamu bisa menguraikan latensi menjadi komponen, menghitung peluang user terkena request lambat pada fan-out, dan membedakan throughput dari konkurensi dan latensi.

Prasyarat dan contoh

Kamu sudah bisa memakai percentile sebagai target (M01.03), menelusuri tahap request (M02.01), dan memahami antrean serta pool (M02.03 dan M02.05).

Sebuah service punya rata-rata 30 ms, p50 20 ms, p99 400 ms. Tim bilang "30 ms, sehat". Halaman beranda memanggil service itu 20 kali untuk satu render. Berapa persen halaman yang terkena setidaknya satu panggilan lambat? Rata-rata tidak bisa menjawab. p99 bisa.

Mekanisme

Komponen latensi. Waktu yang diamati klien adalah jumlah dari: DNS dan handshake (kalau koneksi baru), waktu antre di load balancer atau pool, waktu layanan di aplikasi, waktu menunggu downstream (database, service lain), waktu jaringan, dan transfer body. Bedakan waktu layanan (mengerjakan) dari waktu antre (menunggu giliran). Saat utilisasi tinggi, antrean mendominasi, dan di situlah ekor panjang terbentuk.

Distribusi, bukan rata-rata. Latensi hampir selalu berekor panjang: kebanyakan cepat, sedikit sangat lambat. Rata-rata ikut tertarik ekor tapi tidak memberi tahu seberapa buruk. Laporkan p50, p95, p99, dan maksimum. Jangan merata-ratakan percentile antar instance. p99 gabungan harus dihitung dari histogram atau sampel gabungan.

Penyebab ekor. Antrean sesaat, GC pause, cache miss atau cold start, retransmisi paket (kena timeout 200 ms sampai 1 detik), kontensi lock, query yang kebetulan lambat, dan tetangga berisik di mesin yang sama.

Fan-out memperbesar ekor. Kalau satu request menunggu N panggilan paralel dan masing-masing lambat dengan peluang p, peluang setidaknya satu lambat adalah 1 − (1 − p)^N.

| Fan-out N | Peluang terkena p99 (p = 1%) | | --------- | ----------------------------- | | 1 | 1,0% | | 10 | 9,6% | | 20 | 18,2% | | 100 | 63,4% |

Jadi pada fan-out 100, p99 komponen menjadi median-an pengalaman user. Latensi respons gabungan ditentukan oleh yang paling lambat, bukan yang rata-rata. Contoh di awal: fan-out 20 berarti sekitar 18 persen halaman melewati 400 ms.

Mengurangi ekor. Kurangi fan-out (gabungkan panggilan, cache). Batasi waktu dengan deadline sehingga satu panggilan lambat tidak menahan semuanya (M03). Hedged request: kirim ulang ke replika lain jika belum ada jawaban setelah p95, ambil yang pertama datang. Biayanya sekitar 5 persen beban tambahan, tapi hanya aman untuk operasi baca yang idempoten. Jaga utilisasi tidak mendekati batas karena antrean tumbuh tajam. Isolasi beban berat dari jalur interaktif.

Throughput, konkurensi, latensi. Tiga ukuran berbeda yang terhubung lewat L = λ × W. Throughput (λ) adalah request selesai per detik. Konkurensi (L) adalah request yang sedang berjalan. Latensi (W) adalah waktu satu request. Throughput tinggi tidak menjamin latensi rendah: sistem batch bisa 10.000 request/detik dengan tiap request menunggu 2 detik di antrean. Menambah konkurensi menaikkan throughput hanya sampai sumber daya jenuh. Sesudah itu, konkurensi tambahan cuma menambah antrean, yaitu latensi.

Kenapa percentile tidak bisa dijumlahkan. p99 dari A ditambah p99 dari B tidak sama dengan p99 jalur A lalu B. Kalau ekor kebetulan tidak bersamaan, hasilnya lebih kecil. Kalau keduanya dipicu oleh penyebab yang sama (mis. satu antrean bersama), bisa lebih buruk. Ukur end-to-end dengan trace.

Saat rancangan ini gagal

• Rata-rata sebagai target. "Rata-rata di bawah 100 ms" tercapai sambil 2 persen user menunggu 5 detik.
• Merata-ratakan percentile. Rata-rata p99 dari 10 instance bisa menyembunyikan satu instance dengan p99 3 detik.
• Coordinated omission. Pengujian beban yang menunggu respons sebelum mengirim berikutnya berhenti mengirim saat sistem melambat, sehingga mengukur ekor jauh lebih kecil dari kenyataan. Kirim pada laju tetap yang independen dari respons.
• Hedging pada operasi tulis. Mengirim ganda request tulis yang tidak idempoten menggandakan efek.
• Hedging saat sudah jenuh. Menambah 5 persen beban pada sistem di 95 persen utilisasi mempercepat keruntuhan.
• Timeout tidak selaras. Timeout klien 1 detik, downstream 5 detik: pekerjaan berlanjut padahal klien sudah pergi.

Contoh tandingan: mengejar p99.9 untuk endpoint admin yang dipakai 3 orang tidak sepadan dengan biayanya. Pilih percentile sesuai jumlah dan dampak user.

Latihan

Halaman produk memanggil 12 service secara paralel. Tiap service punya p99 = 250 ms dan p50 = 15 ms. Target halaman: p95 di bawah 300 ms.

1. Berapa persen halaman yang terkena setidaknya satu panggilan lebih lambat dari p99 komponen?
2. Apakah target tercapai dengan asumsi ekor saling bebas? Apa yang perlu ditargetkan di tiap service?
3. Sebutkan dua perubahan untuk menurunkan ekor, dan satu risiko tiap perubahan.

Lihat pembahasan+

1. 1 − 0,99^12 = 1 − 0,886 = sekitar 11,4 persen.
2. Tidak aman. Sekitar 11 persen halaman memiliki setidaknya satu panggilan yang ≥ 250 ms, jadi p95 halaman (5 persen terburuk) pasti di atas 250 ms, sangat dekat atau melewati 300 ms begitu waktu render ditambahkan. Supaya hanya sekitar 5 persen halaman terkena ekor, kamu butuh peluang lambat per service p dengan 1 − (1 − p)^12 ≤ 5%, atau p ≈ 0,43 persen. Artinya, target tiap service harus kira-kira p99,5 sampai p99,6 di bawah 300 ms, bukan p99. Pakai target halaman lalu turunkan ke komponen.
3. (a) Kurangi fan-out: gabungkan atau cache beberapa panggilan sehingga N turun dari 12 ke 6. Peluang terkena turun ke 1 − 0,99^6 ≈ 5,9 persen. Risiko: data tergabung bisa kedaluwarsa (M06) dan service gabungan menjadi lebih besar. (b) Hedged request untuk panggilan baca setelah 50 sampai 100 ms. Risiko: beban tambahan sekitar 5 persen dan hanya aman untuk operasi idempoten. Alternatif: deadline per panggilan dengan fallback (data lama atau komponen kosong) agar satu panggilan lambat tidak menahan halaman. Risiko: halaman parsial yang perlu dirancang.

Terkait

• M01.03 Tentukan sasaran yang berguna menjelaskan memilih percentile sebagai target.
• M02.01 Telusuri request dari browser menunjukkan komponen latensi di sisi jaringan.
• M02.03 Telusuri request konkuren menjelaskan bagaimana antrean terbentuk.
• M02.05 Alihkan trafik dari server yang tidak sehat membahas instance lambat dan margin kapasitas.
• M03 Kontrak API dan retry yang aman membahas deadline dan retry.
• Lab L02 dan rancangan D02 belum tersedia.

Catatan

• Asumsi: ekor tiap panggilan saling bebas. Dalam praktik penyebab bersama (satu antrean, satu node) membuat ekor berkorelasi, dan hasil bisa lebih baik atau lebih buruk dari perhitungan.
• Angka p50, p99, dan beban hedging adalah contoh. Ukur di sistemmu.
• Yang tidak dibahas: estimasi percentile dengan sketch (M12), dan teori antrean lanjutan.
• Terakhir ditinjau: 26 Oktober 2026.