Average Load Testing: Kiểm thử hiệu năng trong điều kiện thực tế

Không phải sự cố nào cũng đến từ một cú sốc tải khổng lồ. Phần lớn hệ thống không gãy vào ngày mở bán — chúng âm thầm rò rỉ bộ nhớ, chậm dần, và lăn ra lỗi vào một ngày làm việc hoàn toàn bình thường, khi lượng người dùng chỉ ở mức trung bình quen thuộc. Nghịch lý là: đúng cái điều kiện "bình thường" đó lại là thứ ít ai chịu kiểm thử nghiêm túc.

Đội kỹ thuật thường dồn toàn bộ sức lực vào kịch bản tải đỉnh (peak) hoặc thử cực hạn (stress), rồi cho rằng nếu hệ thống chịu được mức cao nhất thì mức thường chắc chắn ổn. Đó là một ngộ nhận đắt giá. Một hệ thống có thể vượt qua bài stress trong 15 phút nhưng vẫn suy giảm hiệu suất sau vài giờ chạy liên tục ở tải trung bình — vì memory leak, kết nối DB không được giải phóng, hay cache phình ra theo thời gian. Average Load Testing sinh ra để bắt đúng loại lỗi này: lỗi của sự ổn định kéo dài, không phải lỗi của cú sốc tức thời.

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

• Bản chất của Average Load Test và vì sao nó không thể thay thế bằng Stress Test.
• Khi nào nên chạy bài kiểm thử này trong vòng đời phát hành.
• Cách triển khai bằng Apache JMeter với Concurrency Thread Group và cấu hình ramp-up đúng chuẩn.
• Hai cách xác định mức tải trung bình dựa trên dữ liệu thay vì cảm tính.
• Bộ chỉ số bắt buộc phải phân tích sau khi test xong.

Average Load Test là gì?

Average Load Test là hình thức kiểm thử hiệu năng mô phỏng hành vi sử dụng thông thường của người dùng trong môi trường thực tế — tức là vào một ngày bình thường, với số lượng người dùng tương đối ổn định và các thao tác tiêu chuẩn. Mục tiêu cốt lõi là xác minh xem hệ thống có đáp ứng yêu cầu hiệu suất dưới mức tải trung bình hay không, và quan trọng hơn — liệu nó có giữ được hiệu suất đó qua nhiều giờ vận hành liên tục.

Điểm mấu chốt: bài test này không đi tìm điểm gãy. Nó trả lời một câu hỏi khác và thực tế hơn: "Trong điều kiện vận hành hằng ngày, hệ thống có ổn định và đáng tin cậy không?"

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

Ba loại kiểm thử này thường bị dùng lẫn lộn. Khác biệt nằm ở hình dạng tải và câu hỏi mà mỗi loại trả lời:

Loại kiểm thử	Mức tải áp dụng	Câu hỏi cần trả lời
Average Load Test	Bằng tải trung bình thực tế, duy trì lâu	Hệ thống có ổn định trong điều kiện vận hành hằng ngày không?
Stress Test	Vượt ngưỡng (đến khi suy giảm hoặc gãy)	Giới hạn ở đâu? Gãy thế nào? Phục hồi ra sao?
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: Stress đi tìm giới hạn, Spike mô phỏng cú sốc, còn Average Load xác nhận sự bền bỉ ở mức tải đời thường — phần dễ bị bỏ quên nhất.

Khi nào nên chạy Average Load Test?

Kỹ thuật này phát huy giá trị rõ nhất trong các tình huống sau:

• Sau khi release một phiên bản mới (thay đổi code hoặc hạ tầng) để xác minh hệ thống vẫn ổn định.
• Khi cần theo dõi hiệu suất định kỳ nhằm phát hiện sớm dấu hiệu thoái hoá.
• Trước khi đưa hệ thống ra môi trường thực tế (staging → production).

Mục tiêu cụ thể của một bài Average Load Test:

• Đảm bảo hiệu suất hệ thống dưới tải điển hình.
• Phát hiện sớm các dấu hiệu suy giảm hoặc điểm nghẽn tiềm ẩn.
• Xác minh hệ thống đáp ứng SLA trong môi trường sản xuất.

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

Công cụ chủ lực ở đây là Apache JMeter, kết hợp với plugin Concurrency Thread Group (cài qua Plugin Manager, hoặc tải tại đây). So với Thread Group mặc định, Concurrency Thread Group cho phép giữ ổn định số người dùng đồng thời mục tiêu — đúng tinh thần của bài test này.

Các tham số cấu hình đề xuất:

• Target Concurrency: tổng số người dùng ảo cần đạt (tương đương VU).
• Ramp-up Time: thời gian khởi tạo để đạt đủ số VU mục tiêu.
• Ramp-up Steps Count: số bước tăng tải dần đến mục tiêu.
• Hold Target Rate Time: thời gian duy trì mức tải sau khi đã khởi tạo đủ VU — đây là giai đoạn quan trọng nhất để quan sát tính ổn định.

Kinh nghiệm thực chiến. Một bài Average Load Test chỉ có giá trị khi nó chạy đủ lâu để lộ ra lỗi tích luỹ theo thời gian:

• Kịch bản nên chạy ít nhất từ 1 đến 4 giờ — đủ dài để memory leak hay rò rỉ kết nối kịp biểu hiện.
• Thời gian ramp-up nên giới hạn trong ≤ 1/3 tổng thời gian test. Ví dụ: test 1 giờ → ramp-up tối đa 20 phút, hold 40 phút.
• Nếu hạ tầng test đủ mạnh, bạn có thể rút ngắn ramp-up để dồn thời gian phân tích giai đoạn ổn định (steady state) — nơi mọi vấn đề thật sự lộ diện.

Cách xác định mức tải trung bình

Đây là bước quyết định độ chính xác của cả bài test. Có hai cách tiếp cận, và nên ưu tiên cách dựa trên dữ liệu thật.

Cách 1: Dựa trên dữ liệu thực tế

• Phân tích log, dashboard và các công cụ giám sát như Grafana, New Relic, Prometheus…
• Tính toán lượt truy cập / thao tác trung bình theo ngày hoặc theo tháng.

Ví dụ: nếu trung bình tháng là 120 CCUs (concurrent users) thì đây chính là cơ sở để xây dựng mức Average Load.

Cách 2: Dựa theo phần trăm Peak Load

Khi chưa có đủ dữ liệu vận hành, bạn có thể suy ra mức trung bình từ Peak Load — vốn được xác định qua các bài kiểm thử như Break-point Test:

Ngưỡng theo Peak	Phân loại	Ví dụ với Peak = 200 CCUs
50% Peak	Low Average	100 CCUs
60% Peak	Mid Average	120 CCUs
75% Peak	High Average	150 CCUs

Như vậy, với Peak = 200 CCUs, bạn có thể thiết kế các kịch bản chạy lần lượt ở 100, 120 và 150 CCUs để phủ trọn dải tải vận hành thực tế.

Phân tích & đánh giá kết quả

Chạy xong mới chỉ là một nửa công việc. Giá trị thật nằm ở khâu đọc kết quả. Những chỉ số bắt buộc phải soi kỹ:

• Tính ổn định: hệ thống giữ hiệu suất đều hay dao động bất thường theo thời gian?
• Thời gian phản hồi (response time): có bị spike ở một số bước hay nhóm người dùng nhất định không?
• Tỷ lệ lỗi: có lỗi HTTP hay lỗi logic nào phát sinh dưới tải?
• Điểm nghẽn (bottleneck): nút thắt nằm ở đâu — cơ sở dữ liệu, API hay backend logic?
• Sử dụng tài nguyên: CPU, RAM, Disk có vượt ngưỡng cảnh báo trong suốt thời gian hold không?

Ví dụ cấu hình thực tế. Để trực quan hoá dữ liệu thay vì đọc số liệu thô, hãy kết hợp JMeter Dashboard với bộ đôi Grafana + Prometheus. Khi đó bạn quan sát được đường response time và mức tiêu thụ tài nguyên theo thời gian thực — đủ để phát hiện một đường hiệu suất đang trượt dốc dù tỷ lệ lỗi vẫn bằng 0.

Kết luận

Average Load Test là một kỹ thuật thực tế, bền vững và không thể thiếu trong quy trình kiểm thử hiệu năng. Nó không hào nhoáng như stress hay spike, nhưng lại bảo vệ bạn khỏi đúng loại sự cố hay xảy ra nhất: hệ thống thoái hoá âm thầm trong điều kiện vận hành hằng ngày. Mô hình tư duy cần nhớ rất gọn: tải đúng mức thật — chạy đủ lâu — đọc kỹ giai đoạn ổn định. Làm tốt ba việc đó, bạn phát hiện lỗi ẩn từ sớm, nâng cao trải nghiệm người dùng và đảm bảo chất lượng trước khi giao sản phẩm cho production.

Bạn đã từng dùng Average Load Test trong dự án của mình chưa? Hãy chia sẻ kinh nghiệm và những "cái bẫy" bạn từng gặp để cùng cộng đồng học hỏi lẫn nhau nhé!