Sesi 03 — Antrean Tidak Pernah Bohong

1. Bayangkan jika

Bayangkan kamu mengelola sebuah klinik kecil dengan satu dokter umum.
Pasien datang rata-rata 1 orang setiap 10 menit ( $\lambda = 6$ pasien/jam).
Dokter memeriksa 1 pasien dalam 8 menit ( $T_s = 8$ menit $\rightarrow \mu = 7.5$ pasien/jam).

Pertanyaannya sederhana: berapa lama pasien menunggu di ruang tunggu?

2. Apa yang sebenarnya terjadi

Kita hitung Utilisasi ( $U$ ):

U = \frac{\lambda}{\mu} = \frac{6}{7.5} = 0.8 = 80\%

Dengan formula Waktu Respons Rata-rata ( $T_r$ ) untuk sistem M/M/1:

T_r = \frac{T_s}{1 - U} = \frac{8}{1 - 0.8} = \frac{8}{0.2} = 40 \text{ menit}

Waktu melayani: 8 menit.
Waktu total di sistem: 40 menit.
Waktu menunggu (antrean): 32 menit.

80% utilisasi $\rightarrow$ pelanggan menghabiskan 80% waktu mereka hanya menunggu.

3. Bagaimana jika kita coba naikkan beban?

Misal kedatangan naik jadi 1 pasien tiap 9 menit ( $\lambda = 6.67$ , $U = 89\%$ ).

T_r = \frac{8}{1 - 0.89} = \frac{8}{0.11} \approx 73 \text{ menit}

Utilisasi naik 9 poin (80% → 89%), tapi waktu respons hampir dua kali lipat (40 → 73 menit).

Ini kurva eksponensial antrean. Semakin dekat ke 100%, kurva menembus ke atas tak terbatas.

4. Nama resminya

Istilah	Definisi
Utilisasi ( $U$ )	Porsi waktu server sibuk ( $U = \lambda / \mu$ ).
Saturation	Titik $U \approx 100\%$ ; antrean tak terbatas.
Queue Depth ( $L$ )	Rata-rata jumlah request di sistem (antre + diproses).
Hukum Little ( $L = \lambda W$ )	$L$ = throughput $\times$ waktu di sistem. Berlaku universal.
Knee Point	Utilisasi di mana latency mulai melonjak tajam (biasanya 70–80%).
Buckle Point	Titik throughput puncak sebelum thrash / collapse.

5. Di dunia kita (Software)

Klinik	Software
Dokter	CPU / Worker Thread / DB Connection
Pasien	Request / Query / Transaksi
Ruang tunggu	Socket Queue / Thread Pool Queue / Connection Pool Queue
Waktu periksa	Service Time ( $T_s$ )
Waktu total pasien	Response Time ( $R$ )

Contoh nyata:
DB Connection Pool = 100 koneksi (server).
Service Time query = 5 ms.
Throughput target = 15.000 req/s $\rightarrow$ butuh 75 koneksi simultan (Little's Law).

Kalau traffic spike naik jadi 20.000 req/s $\rightarrow$ butuh 100 koneksi (100% utilisasi).
Antrean meledak. Latency naik dari 5 ms → ratusan ms → timeout.

6. Lensa Performance Tester

Jangan percaya rata-rata. Cari Knee Point via step-load test (naikkan beban bertahap, catat latency p95/p99).
Target utilisasi aman: 60–70% untuk sistem interactive (API, web). 80%+ hanya untuk batch/throughput-oriented.
Hukum Little adalah alat diagnostik:
$L = \lambda \times R$ $\rightarrow$ kalau $R$ naik tapi $\lambda$ stagnan, artinya $L$ (antrean) membengkak.
Saturation ≠ Error. Sistem bisa healthy (HTTP 200) tapi unresponsive (latency 10× normal).

7. Pertanyaan untuk ronde berikutnya

Sesi 4: "Tiga Angka yang Sering Tertukar"
Kenapa tim sering bingung membedakan Concurrency, Throughput, dan Response Time?
Dan bagaimana Little's Law ( $N = X \times R$ ) mengikat ketiganya jadi satu kesatuan yang tidak bisa dipisah?