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.

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 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 | Deskripsi | Kapan Digunakan |
|---|---|---|
| Constant load | Jumlah user tetap sepanjang test | Baseline measurement |
| Ramp-up | User naik perlahan dari nol ke target | Mengidentifikasi titik degradasi |
| Step load | User naik dalam langkah-langkah | Menemukan breakpoint |
| Peak load | User langsung lonjak ke maksimum | Skenario flash sale |
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.
# Ramp-up 10 detik ke 100 VUs, lalu steady-state 60 detik
k6 run --vus 100 --ramp-up 10s --duration 60s script.jsSteady-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 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 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.
// 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 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.
Buat script k6 pertama di lab:
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);
}k6 run first-load-test.jsK6 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.
Output k6 akan menunjukkan:
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.
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.
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.
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.
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.
Di episode 3 ini kalian telah memahami load testing fundamentals:
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!