Jangan menebak — ukur terlebih dahulu. Kelambatan dapat berasal dari klien, jaringan, server, atau database. Pendekatan metodis menemukan di mana waktu hilang, kemudian memperbaiki kontributor terbesar daripada mengoptimalkan secara acak.
Jangan menebak — ukur terlebih dahulu. Kelambatan dapat berasal dari klien, jaringan, server, atau database. Pendekatan metodis menemukan di mana waktu hilang, kemudian memperbaiki kontributor terbesar daripada mengoptimalkan secara acak.
1. MEASURE → where is the time spent? client render, network, server, DB?
2. REPRODUCE → confirm it reliably (same endpoint, payload, user)
3. TRACE → use APM/distributed traces to find the slow span
4. CHECK RECENT CHANGES → deploys, config, traffic, data growth
5. ISOLATE → layer by layer, narrow to one component
6. FIX the biggest contributor → re-measure to confirm
Gunakan tab Network/Performance browser dan timing server untuk membagi total. Rincian yang berguna:
Total 1200ms =
DNS/connect 20ms
server TTFB 900ms ← the bottleneck is server-side
download 80ms
client render 200ms
Perhatikan percentil, bukan rata-rata: p50 (pengguna tipikal) vs p99 (kasus terburuk). P50 yang cepat dengan p99 yang lambat menunjukkan masalah sesekali — lock contention, cold caches, DB replica yang lambat, atau GC pauses — bukan masalah yang seragam.
Alat APM (traces) menunjukkan dengan tepat di mana waktu hilang dalam permintaan:
GET /orders 950ms
├─ auth check 10ms
├─ SELECT orders 30ms
└─ loop: SELECT user per order 900ms ← N+1 query, the real cause
Trace menunjuk langsung ke panggilan yang bermasalah. Kemudian periksa perubahan terbaru — sebuah deploy, indeks yang hilang, atau pertumbuhan data 10x sering menjelaskan regresi mendadak.
Menebak membuang-buang jam mengoptimalkan layer yang salah. Mengukur terlebih dahulu, melacak span yang lambat, dan melihat p50 vs p99 mengubah "itu lambat" yang samar menjadi penyebab spesifik yang dapat diperbaiki — dan pengukuran ulang membuktikan bahwa perbaikan benar-benar berhasil.