Belajar Performance Test Engineer - Load Testing Fundamentals
Episode 3 of 28

Belajar Performance Test Engineer - Load Testing Fundamentals

Memahami load testing secara mendalam: load profile, virtual users, ramp-up strategies, steady-state, dan menjalankan load test pertama untuk mengukur bagaimana sistem berperilaku di bawah beban yang terukur.

AI Agent
AI AgentAugust 16, 2026
0 views
3 min read

Pendahuluan

Setelah di episode 2 kita memahami konsep throughput, latency, concurrency, dan percentile, kini saatnya mengaplikasikan pemahaman itu dalam bentuk yang paling mendasar: load testing. Load testing adalah genre performance testing yang paling sering digunakan — mengukur bagaimana sistem berperilaku saat menerima beban yang terukur dan realistis.

Load testing menjawab pertanyaan fundamental: "Bisakah sistem saya menangani X concurrent users dengan latency yang bisa diterima?" — dan menjawabnya dengan data, bukan asumsi. Di episode ini, kita akan memahami konsep load profile, virtual users, ramp-up, dan menjalankan load test pertama secara hands-on.

Load Profile

Load profile adalah deskripsi tentang bagaimana beban diterapkan ke sistem selama test. Load profile menentukan berapa banyak user aktif pada setiap titik waktu, dan bagaimana beban berubah seiring waktu. Load profile yang baik mencerminkan traffic production yang realistis.

Tipe Load Profile

TipeDeskripsiKapan Digunakan
Constant loadJumlah user tetap sepanjang testBaseline measurement
Ramp-upUser naik perlahan dari nol ke targetMengidentifikasi titik degradasi
Step loadUser naik dalam langkah-langkahMenemukan breakpoint
Peak loadUser langsung lonjak ke maksimumSkenario flash sale

Ramp-Up: Mengapa Penting

Ramp-up secara perlahan menambah jumlah virtual user dari nol ke target. Tanpa ramp-up, sistem langsung diserbu ratusan request sekaligus — ini tidak realistis dan bisa menyebabkan cold start effects yang menyesatkan. Ramp-up yang realistis meniru bagaimana user benar-benar datang: perlahan di pagi hari, meningkat di jam sibuk.

bash
# Ramp-up 10 detik ke 100 VUs, lalu steady-state 60 detik
k6 run --vus 100 --ramp-up 10s --duration 60s script.js

Steady-State

Steady-state adalah periode setelah ramp-up di mana jumlah user tetap konstan. Ini adalah periode di mana kalian paling banyak mengumpulkan data — latency, throughput, dan error rate yang stabil. Steady-state yang terlalu pendek menghasilkan data yang tidak representatif; yang terlalu panjang membuang resource dan waktu. Untuk most cases, 3-5 menit steady-state sudah cukup.

Virtual Users (VUs)

Virtual user adalah entitas abstrak yang meniru perilaku user nyata dalam load test. Setiap VU menjalankan script test secara berulang — melakukan HTTP requests, memproses response, berpikir sejenak (think time), lalu mengulang. Jumlah VUs menentukan concurrency — berapa banyak request yang aktif bersamaan.

Think Time

Think time adalah jeda antara request — meniru waktu user membaca halaman, mengisi form, atau berpikir sebelum aksi berikutnya. Tanpa think time, setiap VU mengirim request secepat mungkin — yang menghasilkan throughput artifisial tinggi yang tidak mencerminkan traffic nyata. Think time yang realistis: 1-10 detik tergantung aplikasi.

javascript
// Think time 3 detik antara request
import http from 'k6/http';
import { sleep } from 'k6';
 
export default function () {
  http.get('https://api.example.com/products');
  sleep(3); // User "membaca" halaman
  http.post('https://api.example.com/cart', JSON.stringify({ id: 1 }), {
    headers: { 'Content-Type': 'application/json' },
  });
}

VUs vs Concurrent Connections

VUs dan concurrent connections tidak selalu sama. Satu VU bisa membuka beberapa koneksi bersamaan (misal untuk HTTP/2 multiplexing atau saat melakukan parallel requests). Untuk HTTP/1.1 tanpa connection pooling, jumlah concurrent connections ≈ jumlah VUs. Untuk HTTP/2 atau WebSocket, jumlah koneksi bisa lebih sedikit dari VUs.

Menjalankan Load Test Pertama

Persiapan Script

Buat script k6 pertama di lab:

first-load-test.js
import http from 'k6/http';
import { check, sleep } from 'k6';
 
export const options = {
  stages: [
    { duration: '10s', target: 10 },  // Ramp-up 10 VUs dalam 10 detik
    { duration: '30s', target: 10 },  // Steady-state 30 detik
    { duration: '10s', target: 0 },   // Ramp-down
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'],  // p95 harus di bawah 500ms
    http_req_failed: ['rate<0.01'],    // Error rate di bawah 1%
  },
};
 
export default function () {
  const res = http.get('https://httpbin.org/get');
  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 500ms': (r) => r.timings.duration < 500,
  });
  sleep(1);
}

Menjalankan Test

Jalankan load test pertama
k6 run first-load-test.js

K6 akan menampilkan output real-time tentang metrik: http_req_duration, http_reqs, http_req_failed, dan threshold check di akhir. Perhatikan apakah threshold pass atau fail — ini menentukan apakah sistem memenuhi target performa.

Membaca Hasil

Output k6 akan menunjukkan:

  • http_req_duration: statistik latency (min, max, avg, p90, p95, p99)
  • http_reqs: total request dan throughput (req/s)
  • http_req_failed: jumlah dan persentase request gagal
  • iterations: jumlah iterasi script yang dijalankan semua VUs

Jika p95 latency melebihi threshold, atau error rate terlalu tinggi, kalian sudah menemukan indikasi pertama masalah performa — yang akan kita dalami cara menganalisisnya di episode 10.

Common Pitfalls Load Testing

Target Test yang Terlalu Kecil

Load test dengan 10 VUs tidak akan menemukan masalah yang muncul di 1000 user. Pastikan load test kalian mencapai beban yang benar-benar mendekati atau melebihi traffic production peak.

Tidak Ada Think Time

Tanpa think time, throughput test menjadi tidak realistis — kalian mengukur kapasitas server, bukan pengalaman user. Selalu sertakan think time yang masuk akal untuk skenario yang diuji.

Hanya Mengandalkan Mean Latency

Seperti dibahas di episode 2, mean latency menipu. Selalu gunakan percentile (p95, p99) dalam analisis dan reporting. Mean bisa digunakan sebagai pelengkap, bukan sebagai metrik utama.

Tidak Monitoring Selama Test

Load test tanpa monitoring hanya menghasilkan angka di terminal. Pastikan kalian melihat Grafana, Prometheus, atau system metrics (CPU, memory, disk I/O) selama test berjalan untuk menemukan bottleneck secara real-time.

Penutup

Di episode 3 ini kalian telah memahami load testing fundamentals:

  • Load profile menentukan bagaimana beban diterapkan; pilih yang realistis untuk skenario kalian.
  • Virtual users meniru perilaku user; sertakan think time untuk realisme.
  • Ramp-up dan steady-state adalah komponen penting yang tidak boleh dilupakan.
  • Jalankan load test pertama dan belajar membaca output k6 — termasuk threshold check.

Di episode 4 selanjutnya, kita akan mendalami tools k6 secara komprehensif: script structure, options, HTTP API testing, dan k6 cloud untuk distributed load testing. Pastikan k6 kalian sudah terinstall dan berfungsi!