Aplikasi Anda berfungsi sempurna dengan sepuluh pengguna. Apa yang terjadi pada hari penjualan, dengan sepuluh ribu? Pengujian beban vs pengujian stres menjelaskan dua cara berbeda untuk menjawab hal tersebut, dan menggabungkan keduanya akan menghasilkan pengujian yang tidak membuktikan apa yang menurut Anda dapat dilakukan.

Panduan ini menjelaskan apa yang ditunjukkan masing-masing tes, jenis tes terkait, dan cara membaca hasilnya. Kami menjalankan penghitungan persentil kecil di bawah ini pada Python 3.13, dengan angka simulasi. Skrip k6 adalah contoh ilustratif yang tidak kami jalankan, dan jumlah serta target pengguna dibuat-buat, jadi gantilah dengan skrip Anda sendiri. Jalankan pengujian ini hanya pada sistem yang Anda miliki atau punya izin untuk mengujinya, karena lalu lintas padat dapat terlihat seperti serangan dan menyebabkan gangguan nyata.

Jawaban singkatnya

uji beban menanyakan: dapatkah kami menangani lalu lintas yang kami harapkan, dan memenuhi target saat melakukannya? Sebuah stress test menanyakan: berapa banyak yang dapat kita ambil sebelum kita gagal, bagaimana kita gagal, dan seberapa cepat kita pulih?

Bayangkan sebuah jembatan. Uji beban menentukan jumlah truk yang diharapkan dan memastikan bahwa semuanya baik-baik saja. Tes stres terus menambah bobot untuk mengetahui batasnya, dan apakah tes tersebut memberikan peringatan terlebih dahulu. Untungnya, perangkat lunak lebih murah untuk dipecahkan daripada jembatan.

Pengujian beban vs pengujian stres secara berdampingan

Apa itu pengujian beban?

Pengujian beban menyimulasikan lalu lintas realistis yang Anda harapkan, dan mengukur perilaku sistem. Diperlukan target untuk diuji, misalnya: “pada 500 pengguna secara bersamaan, 95% permintaan checkout selesai dalam waktu 800 ms, dengan kesalahan di bawah 1%.”

Berikut tampilannya sebagai skrip k6. tes k6 ditulis dalam JavaScript, dan thresholds mengubah target Anda menjadi hasil lulus atau gagal:

import http from "k6/http";
import { sleep } from "k6";

export const options = {
  stages: [
    { duration: "5m", target: 500 },   // ramp up
    { duration: "20m", target: 500 },  // hold at expected peak
    { duration: "2m", target: 0 },     // ramp down
  ],
  thresholds: {
    http_req_duration: ["p(95)<800"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  http.get("https://staging.example.com/products");
  sleep(1);   // think time, as real users pause
}

sleep penting. Tanpa berpikir panjang, setiap pengguna virtual terus menerus menyerang server, menghasilkan lalu lintas yang jauh lebih banyak dibandingkan jumlah pengguna sebenarnya.

Apa itu pengujian stres?

Stress test sengaja melampaui level yang diharapkan. Anda tidak mencoba untuk lulus. Anda menginginkan jawaban atas pertanyaan seperti:

• Pada tingkat manakah kinerja mulai menurun?
• Komponen manakah yang gagal terlebih dahulu: database, server aplikasi, atau panggilan pihak ketiga?
• Apakah itu gagal dengan baik dengan kesalahan yang jelas, atau apakah itu crash dan kehilangan data?
• Apakah ia pulih dengan sendirinya ketika lalu lintas menurun?

export const options = {
  stages: [
    { duration: "5m", target: 500 },    // expected peak
    { duration: "5m", target: 1000 },   // beyond it
    { duration: "5m", target: 2000 },   // further
    { duration: "5m", target: 4000 },   // likely to break
    { duration: "10m", target: 0 },     // recovery: does it come back?
  ],
};

Tahap pemulihan terakhir ini sering kali terlupakan, dan mungkin merupakan tahap yang paling berharga. Sebuah sistem yang menangani kegagalan dengan baik tetapi tidak pernah pulih tanpa memulai ulang secara manual masih berarti pemadaman listrik yang harus diperbaiki seseorang di tengah malam. Idealnya, di bawah beban ekstrem, sistem harus melepaskan pekerjaan secara terkendali, mengembalikan 503 tanggapan yang jelas, bukannya waktu habis.

Spike, rendam dan jenis lainnya

Tes beban dan stres termasuk dalam kelompok pengujian kinerja yang lebih luas:

Tes rendam menangkap masalah yang tidak pernah terlihat oleh tes singkat. Kebocoran memori kecil mungkin terlihat tidak berbahaya selama dua puluh menit, dan hanya membuat layanan terhenti setelah dua hari. Tes lonjakan cocok untuk acara seperti penjualan kilat, di mana lalu lintas tidak meningkat secara bertahap.

Metrik yang penting

Mengapa rata-rata menyesatkan

Rata-rata menyembunyikan permintaan lambat yang dikeluhkan orang-orang nyata. Untuk menunjukkan hal ini, kami membuat 100 waktu respons simulasi, dengan 95 waktu respons cepat (80 hingga 200 ms) dan 5 waktu respons sangat lambat (2,5 hingga 4 detik), lalu menghitung statistik umum:

import math, random, statistics

random.seed(3)
times = [random.randint(80, 200) for _ in range(95)] \
      + [random.randint(2500, 4000) for _ in range(5)]

def pct(values, p):
    values = sorted(values)
    return values[math.ceil(p / 100 * len(values)) - 1]

print("avg", round(statistics.mean(times)), "p50", pct(times, 50),
      "p95", pct(times, 95), "p99", pct(times, 99), "max", max(times))

# avg 302 p50 150 p95 199 p99 3740 max 3896

Perhatikan baik-baik angka-angka itu. Rata-rata 302 ms tidak menggambarkan siapa pun. Permintaan umum membutuhkan waktu sekitar 150 ms, sedangkan permintaan lambat membutuhkan waktu lebih dari 3 detik. Bahkan p95 terlihat sehat pada 199 ms, dan hanya p99 yang menunjukkan masalahnya. Angka seperti p95 berarti 95% permintaan secepat atau secepat ini.

Dan permintaan satu persen bukanlah kejadian langka. Jika suatu halaman membuat 50 permintaan, p99 yang lambat memengaruhi sebagian besar tampilan halaman. Tetapkan target pada persentil yang penting bagi Anda, dan lihat beberapa persentil secara bersamaan.

Alat

Semua ini dapat menjalankan tes beban dan stres. Pilih salah satu yang sesuai dengan keahlian tim Anda, daripada mengejar daftar fitur. Untuk menggunakannya di pipeline Anda, lihat apa itu CI/CD.

Bagaimana merencanakan tes

1. Tetapkan sasaran. Gunakan analisis nyata untuk menemukan lalu lintas puncak Anda, dan tentukan target.
2. Pilih perjalanan. Buat model perilaku pengguna yang realistis, seperti menelusuri, menelusuri, dan checkout, dalam proporsi yang realistis. Hanya menekan halaman beranda tidak membuktikan banyak hal.
3. Gunakan lingkungan yang realistis. Server pementasan kecil tidak dapat memprediksi produksi. Perhatikan perbedaan apa pun.
4. Siapkan data. Gunakan volume yang realistis, karena kueri yang cepat pada 100 baris mungkin merayapi 10 juta.
5. Peringatkan orang-orang. Beri tahu tim operasi Anda dan pihak ketiga mana pun, dan jangan melakukan tes beban pada penyedia pembayaran secara tidak sengaja. Tirukan layanan eksternal jika diperlukan.
6. Mulailah dari yang kecil. Jalankan tes asap kecil terlebih dahulu untuk memastikan bahwa skrip Anda berfungsi.
7. Pantau semuanya. Tanpa metrik server, Anda akan melihat bahwa server melambat, namun tidak mengapa.
8. Ulangi. Jalankan lagi setelah setiap perbaikan, dan pertahankan garis dasar untuk dibandingkan.

Membaca hasilnya

Database adalah hambatan yang umum terjadi, jadi jika kueri adalah masalahnya, baca panduan kami tentang optimasi kueri SQL. Baris terakhir tabel tersebut merupakan jebakan penting: selalu periksa kesehatan mesin yang menghasilkan beban juga.

Kesalahan umum

• Membingungkan pengguna dengan permintaan. Perjelas apakah target berarti pengguna secara bersamaan atau permintaan per detik.
• Menghilangkan waktu berpikir. Hal ini meningkatkan lalu lintas dan memberikan hasil yang menyesatkan.
• Pengujian terlambat. Seminggu sebelum peluncuran tidak ada waktu untuk memperbaiki masalah arsitektur.
• Menggunakan satu titik akhir. Campuran lalu lintas nyata untuk membaca, menulis, dan menelusuri.
• Caching menyembunyikan semuanya. Permintaan berulang yang identik hanya dapat menguji cache Anda, jadi variasikan datanya.
• Pengujian sekali. Performa berubah setiap rilis, jadi jalankan pengujian secara berkala.

Penutup

Jalankan tes beban untuk memastikan bahwa Anda dapat menangani lalu lintas yang Anda harapkan, dan tes stres untuk mengetahui apa yang terjadi jika Anda tidak bisa menanganinya. Mulailah dari yang kecil: pilih perjalanan pengguna Anda yang paling penting, tetapkan satu target yang jelas, dan jalankan pengujian singkat terhadap pementasan dengan pemantauan aktif. Proses pertama biasanya mengajarkan Anda sesuatu, dan Anda dapat membangunnya dari sana.

Pertanyaan yang sering diajukan

Teruslah belajar