Spike Test trong kiểm thử hiệu năng

10 giờ sáng, vé concert mở bán. Trong vòng 60 giây, lượng truy cập nhảy vọt gấp hàng chục lần — và trang web bắt đầu quay vòng vô tận, không ai đăng nhập nổi, hàng nghìn người dùng cùng “F5 đến tuyệt vọng”. Hệ thống vốn chạy mượt suốt nhiều tháng vừa gục ngã đúng vào khoảnh khắc quan trọng nhất, trước mặt khách hàng thật.

Vấn đề không nằm ở chỗ hệ thống chậm lúc bình thường, mà ở chỗ nó không được chuẩn bị để hứng một cú tăng lưu lượng đột biến. Nguyên nhân sâu xa thường là cùng một thứ: thiếu Spike Test — một kỹ thuật kiểm thử hiệu năng ít người làm đúng cách, nhưng lại cực kỳ cần thiết với mọi sản phẩm online có flash sale, mở bán vé hay đăng ký tín chỉ. Cái giá phải trả cho việc bỏ qua nó là downtime đúng vào thời điểm tệ nhất.

Trong bài viết này, bạn sẽ nắm được:

• Bản chất của Spike Test và điểm khác biệt cốt lõi với Load Test, Stress Test.
• Khi nào bắt buộc phải chạy Spike Test cho hệ thống của bạn.
• Cách triển khai bằng Apache JMeter với Ultimate Thread Group, kèm cấu hình mẫu.
• Ba cách xác định mức tải spike hợp lý dựa trên dữ liệu thay vì cảm tính.
• Bộ mục tiêu cần đo và những cái bẫy khiến bạn kết luận sai về sức khoẻ hệ thống.

Spike Test là gì?

Spike Test (kiểm thử tải đột biến) là một loại kiểm thử hiệu năng tập trung mô phỏng sự tăng vọt đột ngột của lưu lượng truy cập (user request) trong thời gian rất ngắn — và thường cũng giảm rất nhanh ngay sau đó. Đặc trưng của nó không phải là độ lớn của tải, mà là hình dạng cú sốc: lên gần như thẳng đứng rồi rơi xuống cũng đột ngột.

Mục tiêu là trả lời ba câu hỏi:

• Hệ thống có chịu được áp lực truy cập đột ngột hay không?
• Nếu bị quá tải hoặc sập, hệ thống phục hồi ra sao?
• Có xuất hiện bottleneck hoặc lỗi hệ thống nào lộ ra dưới cú sốc không?

Phân biệt Spike Test với Load Test và Stress Test

Ba loại kiểm thử thường bị dùng lẫn lộn. Sự khác biệt nằm ở hình dạng và mục đích của tải:

Loại kiểm thử	Hình dạng tải	Câu hỏi cần trả lời
Load Test	Bằng tải kỳ vọng, duy trì ổn định	Hệ thống có đáp ứng SLA ở tải dự kiến không?
Stress Test	Tăng dần vượt ngưỡng đến khi gãy	Giới hạn ở đâu? Gãy như thế nào?
Spike Test	Tăng vọt đột ngột rồi giảm nhanh	Hệ thống xử lý cú sốc tải tức thời thế nào?

Nói ngắn gọn: Load Test xác nhận kỳ vọng, Stress Test đi tìm giới hạn, còn Spike Test mô phỏng cú sốc — đúng kịch bản của một đợt flash sale hay mở bán vé.

Khi nào cần thực hiện Spike Test?

Bạn nên ưu tiên Spike Test trong các tình huống sau:

• Website/app có chiến dịch khuyến mãi giới hạn thời gian (Flash Sale, Campaign, Booking…).
• Dự đoán lưu lượng tăng đột biến từ các sự kiện như:
  • Mở bán vé concert.
  • Chiến dịch truyền thông.
  • Sự kiện truyền hình trực tiếp.
• Muốn kiểm tra hệ thống có sẵn sàng mở rộng theo nhu cầu hay không (scalability readiness).

Cách thực hiện Spike Test bằng JMeter

Công cụ phổ biến và miễn phí cho Spike Test là Apache JMeter. Để dựng được cú tăng vọt rồi thả tải nhanh, nên dùng plugin Ultimate Thread Group (cài từ Plugin Manager) — hoặc tải trực tiếp tại đây.

Năm tham số cấu hình cốt lõi trong Ultimate Thread Group

Tham số	Ý nghĩa
Start Thread Count	Số lượng VU (Virtual User) cần khởi tạo
Initial Delay (s)	Thời gian trễ trước khi bắt đầu khởi tạo
Startup Time (s)	Thời gian để tạo toàn bộ số VU
Hold Load For (s)	Thời gian duy trì tải
Shutdown Time (s)	Thời gian thả tải (VU ngắt kết nối)

Cách dựng từng đường tải để tạo hình spike:

• Line 1: luôn khởi đầu với số người dùng ở mức tải thường (baseline).
• Line 2: bắt đầu tăng đột ngột số người dùng trong thời gian rất ngắn (ví dụ tăng thêm 40 VUs).
• Line 3, 4, 5…: lặp lại tương tự để chồng các đợt spike liên tiếp.

Kinh nghiệm thực chiến. Để mô phỏng đúng tinh thần “tăng sốc – giảm đột ngột”, hãy giữ Startup Time < 30s, Hold Time ngắn (30s – 3 phút), và thả tải cũng nhanh tương ứng. Nếu ramp-up kéo dài, bạn đang chạy Load Test chứ không còn là Spike Test nữa.

Cách xác định số lượng tải Spike hợp lý

Mức tải spike không nên đặt theo cảm tính. Có ba cách thường dùng để chọn con số đáng tin:

1. Phân tích dữ liệu lịch sử: dùng logs hệ thống, traffic metrics và dashboard cũ để tìm các đỉnh đột ngột đã từng xảy ra, rồi áp dụng dự báo tăng trưởng để nhân hệ số đột biến.
2. Tham khảo các chiến dịch tương tự: so sánh với những chiến dịch có hành vi người dùng tương đồng trên thị trường để ước lượng quy mô cú sốc.
3. Tự giả lập ngưỡng Spike: bắt đầu với 150% – 200% mức tải trung bình hoặc đỉnh gần nhất, tuỳ năng lực hạ tầng rồi scale dần cho phù hợp.

Mục tiêu của một bài Spike Test

Một bài Spike Test có giá trị phải đo đồng thời nhiều chiều, không chỉ nhìn vào tốc độ phản hồi:

• Đo thời gian phản hồi: so sánh response time giữa trạng thái bình thường và khi spike xảy ra.
• Đánh giá tính bền vững: hệ thống giữ được bao lâu trước khi crash?
• Theo dõi lỗi HTTP: bao gồm 500, 502, 504… và xác định vị trí phát sinh lỗi.
• Ghi nhận khả năng phục hồi: hệ thống có tự hồi phục sau spike không, và mất bao lâu?
• Xác định điểm nghẽn: bottleneck nằm ở đâu — CPU, RAM, Disk, DB hay network?

Kinh nghiệm thực chiến từ dự án lớn

Kinh nghiệm thực chiến. Bốn nguyên tắc dưới đây tách một bài Spike Test nghiêm túc khỏi một lần “bắn cho vui”.

• Dữ liệu thử nghiệm phải thực tế: đừng dùng JSON mẫu hay dữ liệu giả đơn giản — phải mô phỏng gần đúng hành vi của user thật, nếu không kết luận sẽ sai lệch.
• Giám sát nhiều tầng: kết hợp JMeter + Grafana + Prometheus hoặc một công cụ APM như New Relic để có cái nhìn full-stack (App → DB → Infra).
• Lập nhiều kịch bản spike khác nhau (nhưng phải dựa trên thực tế), ví dụ:
  • Spike trong 30s.
  • Spike rồi giảm dần.
  • Spike liên tục 5 lần, cách nhau 5 phút.
• Đừng test 1 lần duy nhất: hiệu năng không đo bằng một cú bắn — phải lặp lại test và phân tích log, biểu đồ nhiều lần mới có kết luận đáng tin cậy.

Kết luận

Spike Test là thứ bạn chỉ nhận ra tầm quan trọng khi… hệ thống đã sập. Nó không khó để triển khai, nhưng lại là tấm khiên duy nhất cho những thời điểm lưu lượng tăng vọt mà bạn không thể kiểm soát — flash sale, mở bán vé, một chiến dịch truyền thông bất ngờ thành công. Đừng đợi đến khi người dùng tức giận vì “web quay đều như chong chóng”; hãy chuẩn bị hệ thống cho kịch bản xấu nhất ngay từ hôm nay.

Bạn từng stress khi khách hàng gọi điện vì hệ thống sập đúng lúc mở sale chưa? Hãy chia sẻ bài viết và kinh nghiệm kiểm thử của bạn với cộng đồng để cùng nâng chất lượng sản phẩm!