Terjemahkan jadi angka
Dari 'banyak yang pakai' jadi request per detik, traffic puncak, dan berapa request yang jalan barengan. Ini angka yang bikin keputusan teknikal masuk akal.
Pertanyaan
Sebenernya seberapa besar kerjaan yang harus dilayani sistem ini, dan kapan puncaknya?
Setelah baca ini, kamu bisa bikin tabel beban kerja dengan satuan yang benar, dan bisa jelasin kenapa angka rata-rata harian doang sering bikin salah hitung.
Prasyarat dan contoh
Kamu sudah bisa nentuin batas masalah dan nulis target yang ada angkanya (M01.01). Kamu juga tahu satu request HTTP itu butuh waktu, nggak instan.
Dua aplikasi bisa punya jumlah user yang sama tapi beban yang beda jauh. Aplikasi absensi dipakai 5 menit tiap pagi oleh 2.000 karyawan. Aplikasi chat dipakai seharian oleh 200 orang. Yang pertama puncaknya tajam banget; yang kedua rata-ratanya lebih tinggi. Kalau cuma bilang "2.000 user", kamu belum bisa milih apa-apa.
Mekanisme
Turunin beban kerja berlapis, dari perilaku manusia sampai tekanan ke mesin.
User, sesi, request. User itu orangnya. Sesi itu periode dia aktif. Request itu satuan kerja teknis. Rantai ini penting karena angka dari tim marketing biasanya berhenti di "user", sementara kapasitas diukur pakai request per detik.
Rata-rata bukan puncak. Pecah beban harian jadi rata-rata dan puncak. Kalau 50.000 request tersebar rata sehari:
rpsRataRata = 50.000 / 86.400 ≈ 0,58 request/detik
rpsPuncak = 0,58 × 3 ≈ 1,74 request/detik
Angka 3 itu pengali puncak: jam sibuk tiga kali lebih ramai dari rata-rata. Buat acara launch, pengali 8 atau 20 lebih realistis. Kapasitas mesti disiapkan buat puncak, bukan rata-rata.
Konkurensi beda dari throughput. Throughput itu berapa request yang selesai per detik. Konkurensi itu berapa request yang lagi diproses barengan. Hubungannya pakai hukum Little:
konkurensi ≈ laju kedatangan × waktu di dalam sistem
Kalau 100 request/detik dan tiap request butuh 50 ms, rata-rata ada 5 request jalan bareng. Tapi kalau waktu layanannya naik jadi 500 ms, konkurensinya jadi 50. Kapasitas yang kelihatan cukup di throughput bisa habis di konkurensi.
Rasio baca/tulis ngubah semuanya. Sistem dengan 98% baca bisa diselamatkan replika baca dan cache. Sistem dengan 60% tulis nggak bisa. Tulis rasio ini, jangan cuma total request.
Campuran request. Nggak semua request sama beratnya. Redirect itu cuma baca satu key. Halaman dashboard bisa enam query sekaligus. Rata-ratakan biaya per jenis request, bukan per request.
Saat rancangan ini gagal
- Pakai jumlah user terdaftar sebagai beban. Sebagian besar user terdaftar ya nggak aktif. Beban ditentukan sama sesi aktif dan kelakuannya, bukan jumlah baris di tabel user.
- Rata-ratain puncak. Tim ngitung 1,7 request/detik, terus kaget pas launch tembus 40 request/detik. Kapasitas yang dirancang buat rata-rata selalu jebol di puncak pertama.
- Lupa fan-out. Satu request user yang manggil lima service berarti lima unit kerja di belakang. Beban dihitung di tiap batas, bukan cuma di pintu masuk.
- Anggap semua trafik manusia. Bot, crawler, dan retry dari client bisa lebih banyak. Retry yang agresif malah nggandain beban pas sistemnya lagi lambat.
Contoh tandingan: satu endpoint kelihatan ringan, 20 request/detik. Tapi tiap request manggil pencarian yang nyisir 12 shard. Beban efektifnya 240 operasi/detik. Angka di pintu masuk nggak pernah cukup buat jelasin biaya sebenernya.
Latihan
Sebuah layanan nerima 2 juta request per hari. Pengali puncak 8. Waktu layanan rata-rata 120 ms, dan 95% request-nya baca.
Hitung:
- request rata-rata per detik,
- request puncak per detik,
- konkurensi pas puncak,
- jumlah tulisan per hari.
Lihat pembahasan
rpsRataRata = 2.000.000 / 86.400 ≈ 23,1 request/detik
rpsPuncak = 23,1 × 8 ≈ 185 request/detik
konkurensi = 185 × 0,120 ≈ 22,2 request bersamaan
tulisan/hari = 2.000.000 × 0,05 = 100.000 tulisan
Yang penting dari hasil ini: 185 request/detik puncak masih enteng buat satu server. Tapi konkurensi 22 artinya tiap request yang nyangkut 120 ms nahan satu slot. Kalau ada endpoint yang manggil tiga service berurutan dan masing-masing 100 ms, konkurensinya naik tiga kali buat endpoint itu.
Jawaban yang bagus nyebut satuan dan asumsinya: traffic dianggap rata di dalam jam sibuk, dan waktu layanan nggak berubah pas beban naik. Dua-duanya belum tentu benar di produksi.
Terkait
- M01.03 Hitung kebutuhan server pakai angka-angka ini buat ngitung kapasitas.
- Lab L01 bikin kamu bisa ngubah pengali puncak dan lihat komponen mana yang jenuh duluan.
- M02.06 Jelaskan tail latency bahas kenapa rata-rata waktu layanan bisa nyembunyiin ekor distribusi.
Catatan
- Asumsi contoh: traffic rata di dalam periode sibuk, waktu layanan konstan.
- Yang nggak dibahas: distribusi statistik waktu layanan, model antrean, dan pola musiman.
- Hukum Little itu identitas dasar teori antrean:
L = λ × W. - Terakhir ditinjau: 25 Oktober 2026.