Belajar Performance Test Engineer - Konsep & Metodologi Performa

#Pendahuluan

Setelah di episode 1 kita memahami peran Performance Test Engineer dan konteks 2026, kini saatnya menanamkan fondasi konseptual yang paling krusial: apa yang sebenarnya kita ukur saat berbicara tentang performa? Tanpa memahami metrik ini secara mendalam, kalian hanya akan menghasilkan angka tanpa interpretasi yang berguna.

Performance testing yang efektif dimulai dari kemampuan mendefinisikan "apa artinya performa yang baik?" secara spesifik dan terukur. Episode ini membekali kalian dengan vocabulary dan framework untuk berpikir tentang performa secara sistematis — yang akan dipakai di seluruh episode berikutnya.

#Throughput

Throughput adalah jumlah request yang berhasil diproses sistem per satuan waktu — biasanya diukur dalam requests per second (RPS) atau transactions per second (TPS). Ini adalah metrik utama untuk mengukur kapasitas sistem.

#Cara Mengukur Throughput

Throughput tidak selalu linear. Sebuah sistem mungkin mampu melayani 1000 RPS saat 100 user aktif, tetapi hanya 800 RPS saat 500 user aktif — karena konteks, lock contention, dan resource exhaustion. Karena itu, throughput selalu harus dilaporkan bersama beban (jumlah concurrent users atau arrival rate).

bash

# Contoh mengukur throughput dengan k6
k6 run --vus 100 --duration 60s script.js 2>&1 | grep http_reqs

#Throughput vs Bandwidth

Jangan bingung throughput dengan bandwidth. Bandwidth adalah kapasitas jaringan mentah (misal 1 Gbps), sedangkan throughput adalah jumlah request sukses yang benar-benar diproses oleh aplikasi. Sebuah sistem bisa punya bandwidth 1 Gbps tetapi throughput hanya 200 RPS jika aplikasi-nya CPU-bound.

#Latency

Latency adalah waktu yang dibutuhkan sistem untuk merespons satu request — dari saat request dikirim sampai response diterima sepenuhnya. Latency adalah cerminan user experience secara langsung: latency tinggi = user menunggu lama.

#Latency Components

Latency total sebuah request terdiri dari beberapa komponen:

Komponen	Deskripsi
Network latency	Waktu data menempuh jaringan dari client ke server
Processing latency	Waktu server memproses request (CPU, I/O)
Queue latency	Waktu request menunggu di queue sebelum diproses
Serialization latency	Waktu mengubah data ke format transmisi (JSON, protobuf)

Untuk mengoptimasi latency, kalian harus tahu komponen mana yang paling besar — inilah mengapa observability (distributed tracing) sangat penting di performance engineering modern.

#Latency vs Response Time

Istilah ini sering dipakai bergantian, tetapi ada perbedaan teknis. Response time = total waktu dari client perspective (termasuk network round-trip). Latency bisa merujuk pada waktu server-side saja (tanpa network). Dalam practice, k6 melaporkan http_req_duration yang mencakup seluruh lifecycle request — lebih tepat disebut response time, tetapi sering disebut latency dalam diskusi performance.

#Concurrency

Concurrency adalah jumlah request yang diproses secara bersamaan oleh sistem — atau lebih tepat, jumlah virtual users atau active connections yang sedang aktif dalam test. Concurrency adalah variabel independen yang kalian kontrol dalam load test; throughput dan latency adalah dependen yang kalian ukur.

#Concurrency vs Parallelism

Concurrency = banyak task yang berjalan dalam satu periode waktu (bisa bergantian). Parallelism = banyak task yang benar-benar dieksekusi secara simultan di banyak CPU core. Untuk performance testing, yang penting adalah concurrency — berapa banyak user yang aktif bersamaan, terlepas dari apakah server memprosesnya paralel atau bergantian.

#Amdahl's Law

Hukum Amdahl memberikan batas teoritis pada seberapa cepat sistem bisa dipercepat dengan menambah resource: jika 20% dari kode tidak bisa diparalelkan (serial), maka kecepatan maksimum adalah 5x dari single-core — terlepas dari berapa banyak core yang ditambahkan. Ini menjelaskan mengapa menambah server tidak selalu menyelesaikan masalah performa — ada bottleneck serial yang harus diidentifikasi dan dieliminasi.

#Percentile (p50, p95, p99)

Percentile adalah cara paling adil untuk melaporkan latency — lebih informatif daripada rata-rata (mean) yang menipu.

#Cara Kerja Percentile

p50 (median): 50% request selesai di bawah nilai ini — ini "experience typical user".
p95: 95% request selesai di bawah ini — ini "experience kebanyakan user".
p99: 99% request selesai di bawah ini — ini "experience user yang paling sial".
p999: 1 dari 1000 request — menunjukkan tail latency.

#Mengapa Mean Menipu

Bayangkan 100 request: 99 request diselesaikan dalam 10ms, tetapi 1 request mengalami timeout 30 detik. Mean latency = (99 × 10 + 30000) / 100 = 309.9ms — yang terlihat sangat buruk. Tetapi p99 = 10ms — menunjukkan bahwa 99% user mengalami performa excellent. Mean menipu karena outlier satu request menyeret seluruh rata-rata.

#Threshold di k6

Di k6, kalian menentukan threshold berdasarkan percentile:

bash

# Contoh threshold k6
k6 run --vus 100 --duration 60s \
  --threshold "http_req_duration{p(95)<500}" \
  --threshold "http_req_failed<0.01" \
  script.js

Artinya: test PASS jika p95 latency di bawah 500ms dan error rate di bawah 1%. Jika salah satu gagal, test dianggap gagal.

#Error Budget dan SLO

Service Level Objective (SLO) adalah target performa yang disepakati organisasi — misal "99% request harus diselesaikan di bawah 500ms". Error budget adalah ruang toleransi: jika SLO = 99.9% success rate, maka error budget = 0.1% — sistem boleh mengalami 0.1% kegagalan sebelum ada konsekuensi (misal freeze deployment).

Error budget adalah alat governance yang powerful: ia menghubungkan performa teknis dengan keputusan bisnis. Jika error budget habis, tim harus fokus reliability dulu sebelum menambah fitur baru. Konsep ini akan kita dalami lebih jauh di episode 20.

#Mendefinisikan Performance Objectives

#Langkah-langkah

Identifikasi flow kritis: halaman utama, checkout, search — flow yang paling banyak dipakai user.
Tentukan metrik target: latency (p95 < 300ms), throughput (1000 RPS), error rate (< 0.1%).
Tentukan beban: berapa concurrent users yang harus dilayani (misal 500 untuk peak).
Validasi dengan data: gunakan data production (APM, analytics) sebagai baseline.
Dokumentasikan: buat SLO document yang bisa dirujuk semua tim.

#Contoh Performance Objective

plaintext

Sistem e-commerce harus melayani:
- 2000 concurrent users during flash sale
- p95 latency ≤ 500ms for product search
- p99 latency ≤ 2000ms for checkout flow
- Error rate ≤ 0.5% during peak load
- Throughput ≥ 500 RPS for API endpoints

#Penutup

Pada episode 2 ini, kalian telah memahami konsep-konsep inti performance engineering:

Throughput = jumlah request sukses per detik; harus dilaporkan bersama beban.
Latency = waktu respons dari server; terdiri dari network, processing, queue, dan serialization.
Concurrency = jumlah user aktif bersamaan; independent variable di load test.
Percentile (p95, p99) lebih informatif dari mean; gunakan di threshold k6.
SLO & Error Budget menghubungkan performa teknis dengan keputusan bisnis.

Di episode 3 selanjutnya, kita akan masuk ke Load Testing Fundamentals — memahami load profile, virtual users, ramp-up strategies, dan menjalankan load test pertama kalian secara praktis. Siapkan lab kalian!