belajarmenolak ngantor
M01.0220 menit bacamateri 2 dari 6

Jelaskan beban kerja

Membedakan pengguna, sesi, request, konkurensi, trafik puncak, dan rasio baca/tulis — lalu mengubahnya menjadi angka yang bisa dipakai.

Progres cuma disimpan di browser ini.

Pertanyaan

Berapa banyak pekerjaan yang harus dilayani sistem, dan kapan pekerjaan itu datang?

Hasil yang bisa diamati: kamu bisa menulis satu tabel beban kerja dengan satuan yang benar, dan menjelaskan mengapa angka rata-rata harian saja menyesatkan.

Prasyarat dan contoh

Kamu sudah bisa menulis batasan masalah dan kebutuhan nonfungsional dengan angka (M01.01). Kamu juga sudah paham bahwa satu request HTTP punya durasi.

Dua sistem bisa punya jumlah pengguna yang sama tetapi beban yang sangat berbeda. Aplikasi absensi dipakai 5 menit setiap pagi oleh 2.000 karyawan. Aplikasi chat dipakai sepanjang hari oleh 200 orang. Yang pertama punya puncak tajam; yang kedua punya beban rata yang lebih tinggi. Menyebut "2.000 pengguna" tidak membantu memilih apa pun.

Mekanisme

Turunkan beban kerja berlapis, dari perilaku manusia ke tekanan teknis.

Pengguna → sesi → request. Pengguna adalah orang. Sesi adalah periode aktif. Request adalah satuan kerja teknis. Rantai ini penting karena angka pemasaran biasanya berhenti di pengguna, sedangkan kapasitas diukur dalam request per detik.

Rata-rata bukan puncak. Beban harian harus dipecah menjadi rata-rata dan puncak. Jika 50.000 request tersebar rata sehari:

rpsRataRata = 50.000 / 86.400 ≈ 0,58 request/detik
rpsPuncak   = 0,58 × 3 ≈ 1,74 request/detik

Pengali puncak 3 berarti trafik jam sibuk tiga kali rata-rata. Untuk acara peluncuran, pengali 8 atau 20 lebih realistis. Kapasitas harus direncanakan pada puncak, bukan rata-rata.

Konkurensi berbeda dari throughput. Throughput adalah berapa request selesai per detik. Konkurensi adalah berapa request sedang diproses pada satu waktu. Hubungannya dinyatakan hukum Little:

konkurensi ≈ laju kedatangan × waktu tinggal di sistem

Dengan 100 request/detik dan waktu layanan 50 ms, rata-rata ada 5 request bersamaan. Jika waktu layanan naik menjadi 500 ms pada beban yang sama, konkurensi menjadi 50. Kapasitas yang tampak cukup di throughput bisa habis di konkurensi.

Rasio baca/tulis mengubah segalanya. Sistem dengan 98% baca bisa diskalakan dengan replika baca dan cache. Sistem dengan 60% tulis tidak. Nyatakan rasio ini, bukan hanya total request.

Campuran request. Tidak semua request sama. Redirect adalah satu pembacaan kunci. Halaman dasbor mungkin enam query. Rata-ratakan biaya per jenis request, bukan per request.

Saat rancangan ini gagal

  • Memakai pengguna terdaftar sebagai beban. Sebagian besar pengguna terdaftar tidak aktif. Beban ditentukan oleh sesi aktif dan perilakunya, bukan ukuran basis data pengguna.
  • Merata-ratakan puncak. Tim menghitung 1,7 request/detik lalu terkejut saat peluncuran menghasilkan 40 request/detik. Kapasitas yang dirancang untuk rata-rata selalu gagal pada puncak pertama.
  • Mengabaikan fan-out. Satu request pengguna yang memanggil lima layanan menciptakan lima unit kerja downstream. Beban diukur di setiap batas, bukan hanya di pintu masuk.
  • Menganggap trafik manusia. Bot, crawler, dan retry klien bisa mendominasi. Retry yang agresif bahkan menggandakan beban tepat ketika sistem sedang lambat.

Contoh tandingan: sebuah endpoint terlihat ringan — 20 request/detik. Tetapi setiap request memanggil pencarian yang memindai 12 shard. Beban efektifnya 240 operasi/detik. Angka pintu masuk tidak pernah cukup untuk menjelaskan biaya sebenarnya.

Latihan

Sebuah layanan menerima 2 juta request per hari. Pengali puncak 8. Waktu layanan rata-rata 120 ms, dan 95% request adalah baca.

Hitung:

  1. request rata-rata per detik,
  2. request puncak per detik,
  3. konkurensi pada puncak,
  4. 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 perlu dibaca dari hasil ini: 185 request/detik puncak masih sederhana untuk satu server, tetapi konkurensi 22 berarti setiap request yang tertahan 120 ms menahan slot. Jika ada endpoint yang memanggil tiga layanan secara berurutan dan masing-masing 100 ms, konkurensi naik tiga kali untuk endpoint itu.

Jawaban yang baik menyebut satuan dan menyatakan asumsi: distribusi trafik seragam di dalam jam sibuk, dan waktu layanan tidak berubah saat beban naik. Keduanya belum tentu benar di produksi.

Terkait

Catatan

  • Asumsi contoh: trafik tersebar merata di dalam periode sibuk; waktu layanan konstan.
  • Yang tidak dibahas: distribusi statistik waktu layanan, model antrean, dan pola trafik musiman.
  • Hukum Little adalah identitas dasar teori antrean: L = λ × W.
  • Terakhir ditinjau: 25 Oktober 2026.