UNDER PRESSURE

Level 0 · Membaca Tekanan

Sesi 4: Tiga Angka yang Sering Tertukar

Sesi 4 / 346 menit baca

1. Bayangkan jika

Bayangkan kamu mengamati sebuah jalan tol tiga lajur.

Di pintu masuk tol, ada 1.000 mobil yang mengantre masuk dalam waktu bersamaan. Manajer operasional tol berdiri di sampingmu dan berkata dengan bangga: "Lihat, kita punya 1.000 kendaraan bersamaan di tol kita!"

Tetapi saat kamu menghitung mobil yang berhasil melewati gerbang keluar di ujung tol, angkanya tetap konsisten: tepat 10 mobil per detik.

Satu jam kemudian, 1.000 mobil tambahan memaksa masuk. Sekarang ada 2.000 mobil yang berada di dalam jalan tol. Jalan tol macet total, mobil merayap bumper-to-bumper.

Kamu menghitung kembali gerbang keluar. Angkanya justru turun menjadi 4 mobil per detik.

Manajer tol bingung: "Bagaimana mungkin kendaraan yang masuk dua kali lipat lebih banyak, tapi kendaraan yang selesai keluar justru lebih sedikit?"

Di dunia pengujian performa, kesalahan memahami tiga angka ini adalah jebakan nomor satu yang paling sering menghancurkan hasil analisis uji beban.

Orang sering menukar berapa orang yang sedang mencoba (Virtual User / Concurrency) dengan berapa transaksi yang benar-benar selesai (Throughput / TPS).

2. Apa yang sebenarnya terjadi

Dalam ilmu rekayasa performa, ada tiga metrik utama yang saling terikat erat dalam hubungan segitiga:

                  [ CONCURRENCY (N) ]
                   /               \
                  /                 \
                 /                   \
    [ THROUGHPUT (X) ] ────────── [ RESPONSE TIME (R) ]

Mari kita bedah definisi persis dari ketiganya:

1. Throughput (TPS / RPS)

Throughput adalah jumlah pekerjaan yang selesai diproses per satuan waktu (biasanya Transaction Per Second / TPS, atau Request Per Second / RPS). Ini adalah kecepatan aliran air yang benar-benar keluar dari keran.

Jika sistemmu menghasilkan 500 TPS, artinya ada 500 transaksi yang berhasil diselesaikan dari awal sampai akhir dalam satu detik.

2. Concurrency (N / Concurrently Active Users)

Concurrency adalah jumlah request atau pengguna yang sedang diproses secara bersamaan di dalam sistem pada satu titik waktu. Ini adalah jumlah mobil yang saat ini sedang berada di dalam badan jalan tol.

3. Response Time (R / Latency)

Response Time adalah durasi waktu yang dibutuhkan satu transaksi dari masuk hingga selesai. Ini adalah berapa menit satu mobil berada di jalan tol dari pintu masuk ke pintu keluar.

Hubungan Segitiga (Little's Law Versi Sistem)

Ketiga angka ini diikat oleh rumus sederhana:

\text{Concurrency } (N) = \text{Throughput } (X) \times \text{Response Time } (R)

Atau jika memperhitungkan jeda waktu pengguna mengetik (Think Time Z):

N = X \times (R + Z) \quad \Rightarrow \quad X = \frac{N}{R + Z}

Tiga Fase Kurva Load Test

Ketika kamu menaikkan jumlah Virtual User (N) secara bertahap saat load test, grafik hasil pengujian akan selalu melewati 3 fase utama:

 Throughput
   (TPS)
    ▲             FASE 2: SATURATION (KNEE)
    │           ┌──────────────────────┐
    │          /                        \  FASE 3: BUCKLE (CRASH)
    │         /                          \
    │        /                            \
    │       /  FASE 1: LINEAR              \
    │      /
    └─────┴──────────────────────────────────► Virtual Users (VU)

  1. Fase 1 — Linear Phase:
    Beban masih ringan. Setiap kali kamu menambah 100 Virtual User, Throughput (TPS) naik sebanding secara garis lurus. Response Time tetap rendah dan konstan.

  2. Fase 2 — Saturation / Knee Phase:
    Sistem mencapai kapasitas pemrosesan maksimum (Max TPS). Ketika kamu menambah Virtual User lagi dari 500 ke 1.000, TPS tidak naik sama sekali (stagnan datar). Mengapa? Karena seluruh CPU/thread sudah terpakai 100%. Penambahan VU hanya memperpanjang waktu antre (Response Time membengkak).

  3. Fase 3 — Buckle Phase (System Collapse):
    Kamu terus memaksa menaikkan VU menjadi 2.000. Memori antrean meluap, CPU menghabiskan seluruh waktunya untuk context switching dan garbage collection, thread berebut kunci. Throughput (TPS) mendadak jatuh anjlok, sementara Response Time meroket ke langit. Sistem mengalami buckle (patah).

3. Bagaimana jika kita coba...

Bagaimana jika kita mengklaim: "Aplikasi kita mampu menahan 10.000 concurrent user"?

Kalimat di atas adalah klaim yang ambigu dan sering menyesatkan tanpa menyebutkan angka TPS dan Response Time.

10.000 concurrent user yang sebagian besar sedang diam membaca artikel (think time 30 detik) hanya membutuhkan daya proses 333 TPS.

Tetapi 10.000 concurrent user yang menekan tombol checkout bersamaan tanpa think time dengan response time 100ms membutuhkan daya proses 10.000 TPS!

Satu kalimat yang sama bisa berarti sistem yang sangat santai atau sistem raksasa berkelas dunia.

Bagaimana jika kita mengatur script JMeter dengan 1.000 Virtual User tanpa Think Time?

Script uji beban yang mengeksekusi request tanpa jeda (zero think time) bukanlah mensimulasikan 1.000 manusia. Itu adalah serangan Denial of Service (DoS) yang membombardir server secepat kodenya bisa berputar.

4. Nama resminya

Di laporan resmi pengujian performa, istilah-istilah ini ditulis dengan nama baku:

  • Throughput (TPS / RPS) — Jumlah transaksi bisnis atau request HTTP yang sukses diselesaikan per detik.
  • Concurrency / Concurrent Users — Jumlah sesi pengguna aktif yang sedang berinteraksi dengan aplikasi dalam satu jendela waktu.
  • Simultaneous Users — Jumlah pengguna yang menekan tombol pada milidetik yang persis sama (sub-himpunan kecil dari concurrent users).
  • Virtual User (VU) — Utas simulasi (thread/coroutine) di dalam alat uji beban (JMeter/K6) yang mengeksekusi langkah-langkah skenario uji.
  • Think Time (Z) — Jeda waktu simulasi saat pengguna membaca layar sebelum melakukan aksi berikutnya.
  • Pacing — Jeda waktu yang disengaja antara penyelesaian satu iterasi skenario dengan dimulainya iterasi berikutnya untuk menjaga kestabilan target TPS.
  • Buckle Point — Titik beban di mana pemrosesan sistem runtuh dan throughput mengalami penurunan drastis akibat overhead antrean ekstrim.

5. Di dunia kita

Bagaimana salah tafsir 3 angka ini memicu masalah di dunia nyata?

  1. Mitos "1 VU = 1 TPS":
    Banyak penguji pemula berasumsi jika mereka memasang 500 Virtual User di JMeter, maka server sedang diuji pada 500 TPS. Ini salah. Jika response time aplikasi adalah 2 detik, maka 500 VU dengan zero think time hanya menghasilkan 250 TPS (500 / 2).

  2. Insiden Tiketing / Flash Sale (Simultaneous Spike):
    Pada hari biasa, 50.000 concurrent user tersebar acak dengan think time 10 detik. TPS yang masuk hanya 5.000. Namun saat jam 12.00 tepat promo dibuka, 50.000 user tersebut berubah menjadi simultaneous users yang menekan tombol di detik yang sama. TPS melonjak 10x lipat secara instan, melemparkan sistem langsung dari Fase 1 ke Fase 3 (Buckle).

6. Lensa performance tester

Sebagai penguji kinerja (performance tester), Sesi 04 mengubah cara kita menyusun laporan hasil pengujian:

  1. Selalu Laporkan Trikotomi Lengkap:
    Jangan pernah melaporkan angka tunggal. Laporan pengujian wajib menyajikan tiga angka bersamaan: "Pada beban 1.000 VU (Concurrency), sistem mencapai puncak 450 TPS dengan p95 Response Time 1,2 detik."

  2. Bedakan Concurrency dari Throughput Target:
    Jika bisnis meminta "sistem harus kuat 2.000 TPS", gunakan rumus Little's Law untuk menghitung berapa VU yang dibutuhkan script pengujimu berdasarkan estimasi response time dan think time.

  3. Cari Titik Buckle untuk Mengetahui Batas Kehancuran:
    Pengujian Stress Test bertujuan sengaja mendorong sistem melewati Knee Phase hingga menemukan Buckle Point. Mengetahui di mana titik patah sistem memberi tahu tim operasi kapan rate limiting atau circuit breaker harus menyala.

7. Pertanyaan untuk ronde berikutnya

Kita sudah tahu bahwa ketika beban didorong melewati knee point, sistem memasuki fase saturation dan akhirnya mengalami buckle (TPS drop).

Namun ketika sistem patah dan mulai menolak request, apa yang sebenarnya habis di dalam server?

Apakah CPU-nya yang menyentuh 100%? Apakah memorinya habis terkena OutOfMemoryError? Atau ada lemari rahasia di dalam OS — seperti file descriptors atau socket backlog — yang kosong tanpa ada yang memantau?

Itu isi Sesi 5: Yang Sebenarnya Habis.

SYSTEM UNDER PRESSURE · Sesi 4 dari 34