Mengukur Performa Backend dengan Benar

Salah satu kebiasaan yang paling sering saya temui di tim engineering — dan pernah saya lakukan sendiri — adalah mengukur performa backend hanya dari sisi server. Kita buka htop, lihat CPU dan memory adem-adem saja, response time di log aplikasi kelihatan cepat, lalu kita simpulkan "aplikasi sudah cepat". Padahal apa yang dirasakan pengguna di ujung lain koneksi bisa jauh berbeda. Ini bukan soal alat ukur yang salah, tapi soal apa yang diukur — dan di titik mana pengukuran itu dilakukan.

Server sehat bukan jaminan pengguna senang

Ketika kita mengukur response time langsung di server (misalnya lewat log Laravel atau APM yang terpasang di aplikasi), angka yang keluar hanya mencerminkan waktu dari saat request diterima sampai response dikirim dari server. Yang tidak terekam di situ adalah: waktu DNS resolution, TCP handshake, TLS negotiation, waktu request melintasi jaringan menuju server, waktu response melintasi jaringan kembali ke klien, dan waktu browser atau aplikasi klien memproses response itu jadi tampilan yang bisa dipakai.

Di lingkungan klinik atau rumah sakit tempat saya banyak bekerja, ini kelihatan nyata: koneksi internet fasilitas kesehatan sering jauh dari ideal — dari serat optik stabil sampai koneksi seluler yang naik turun. Server bisa merespons dalam hitungan puluhan milidetik, tapi pengguna di ujung sana tetap merasa aplikasi lambat karena mayoritas waktu justru habis di jaringan, bukan di server.

Rata-rata itu menipu, gunakan persentil

Masalah kedua yang sering luput adalah cara meringkas angka. Rata-rata (mean) response time gampang dihitung tapi gampang juga menyembunyikan masalah. Sebagai ilustrasi, katakanlah dari seratus request, sembilan puluh lima di antaranya selesai dalam waktu singkat, tapi lima request nyangkut lama karena lock database, N+1 query, atau cold start. Rata-ratanya bisa tetap terlihat "baik-baik saja", padahal sebagian pengguna — biasanya justru yang sedang mengakses data besar atau di jam sibuk — mengalami pengalaman yang buruk.

Karena itu saya lebih percaya pada metrik persentil seperti p95 atau p99 dibanding rata-rata. p95 misalnya memberi tahu: dari seratus request, sembilan puluh lima di antaranya selesai lebih cepat dari angka ini — sisanya lebih lambat. Angka seperti ini jauh lebih jujur menggambarkan pengalaman pengguna yang sedang bernasib kurang beruntung, dan itu biasanya justru pengguna yang paling vokal komplain.

Mengukur dari sudut pandang pengguna, bukan hanya server

Untuk mendapatkan gambaran yang lebih utuh, ada beberapa pendekatan yang saling melengkapi:

Real User Monitoring (RUM) — menaruh sedikit skrip pengukuran di sisi klien (browser atau aplikasi) yang mencatat waktu nyata yang dirasakan pengguna sesungguhnya, lengkap dengan variasi lokasi, jaringan, dan perangkat mereka.
Synthetic monitoring — menjalankan pengukuran otomatis dari beberapa lokasi geografis berbeda secara berkala, untuk mendapat gambaran konsisten tanpa bergantung pada trafik pengguna asli.
Application Performance Monitoring (APM) — tetap penting untuk melihat bagian mana dari request yang lambat (query database, pemanggilan API eksternal, rendering), tapi perlu dipadukan dengan dua pendekatan di atas, bukan berdiri sendiri.

Ketiganya menjawab pertanyaan berbeda. APM menjawab "di mana waktu dihabiskan di dalam sistem saya", sementara RUM dan synthetic monitoring menjawab "apa yang sebenarnya dirasakan pengguna". Keduanya perlu dibaca bersama.

Takeaway

Mengukur performa backend hanya dari server itu perlu, tapi tidak cukup. Jaringan, lokasi pengguna, dan variasi kondisi nyata di lapangan bisa membuat "angka bagus di dashboard" terasa sangat berbeda di layar pengguna. Kalau tim saya sedang menilai apakah sebuah optimisasi berhasil, saya selalu mengecek tiga hal: apakah metrik server membaik, apakah persentil tinggi (bukan cuma rata-rata) ikut membaik, dan — kalau memungkinkan — apakah ada sinyal dari sisi klien yang menunjukkan pengalaman pengguna benar-benar terasa lebih cepat. Ketiganya baru memberi gambaran yang bisa dipercaya.