Load vs Stress — bảng phân biệt nhanh

Load test vs stress test khác nhau ở mục tiêu: load test kiểm tra hệ thống dưới tải kỳ vọng (số người dùng thật, kể cả giờ cao điểm) xem có đáp ứng đúng cam kết không; còn stress test cố tình đẩy tải vượt ngưỡng cho tới điểm gãy (breaking point) để xem hệ thống hỏng ra sao và phục hồi thế nào. Nói ngắn: load test hỏi "chịu nổi mức bình thường chứ?", stress test hỏi "gãy ở đâu và gãy có êm không?".

Cả hai đều là dạng performance testing (kiểm thử hiệu năng) — một loại kiểm thử phi chức năng, thuộc nhóm performance efficiency trong tiêu chuẩn chất lượng ISO/IEC 25010. Chúng không kiểm tra "app làm đúng chức năng không" mà kiểm tra "app làm nhanh, ổn định, chịu tải tới đâu".

Tiêu chí Load test Stress test
Mục tiêu Xác nhận đáp ứng ở tải kỳ vọng & peak Tìm điểm gãy, xem cách hỏng và phục hồi
Mức tải Bằng hoặc quanh tải thật dự kiến Vượt ngưỡng, tăng dần tới khi hệ thống hỏng
Câu hỏi trả lời "Có đạt SLA ở giờ cao điểm không?" "Bao nhiêu user thì sập? Sập có êm không?"
Chỉ số quan sát Response time, throughput ổn định Điểm bắt đầu lỗi, degradation, recovery
Kết quả kỳ vọng Hệ thống chạy mượt, trong ngưỡng Hệ thống hỏng có kiểm soát, hồi phục được

Load testing là gì

Load testing là gì? Đó là việc mô phỏng số lượng người dùng và giao dịch đúng bằng mức tải mà hệ thống dự kiến gặp trong thực tế — cả tải trung bình lẫn tải đỉnh (peak) — để xác nhận hệ thống vẫn đáp ứng đúng cam kết về tốc độ và độ ổn định. Trọng tâm là "bình thường và cao điểm", không phải "vắt kiệt".

Với Hệ thống đặt phòng họp, giả sử công ty có 200 nhân viên, và giờ cao điểm là 8–9h sáng khi mọi người tranh nhau đặt phòng cho cuộc họp trong ngày. Load test sẽ mô phỏng khoảng 200 người dùng đồng thời đăng nhập, tìm phòng trống, đặt phòng — rồi đo xem trang phản hồi có còn nhanh, giao dịch có bị rớt không.

  • Mục tiêu: kiểm chứng hệ thống đạt SLA/SLO (ví dụ: 95% request trả về dưới 2 giây) ở mức tải thật.
  • Cách chạy: tăng tải dần (ramp-up) tới mức kỳ vọng rồi giữ ổn định một khoảng, quan sát response time và throughput có "phẳng" không.
  • Quan sát: response time không tăng vọt, error rate gần 0, throughput đạt mức mong đợi.

Load test trả lời cho câu hỏi kinh doanh: "Đến ngày go-live, khi cả công ty vào dùng, app có trụ được không?". Muốn hiểu bức tranh lớn hơn về loại kiểm thử này, bạn đọc thêm bài performance testing là gì.

Stress testing là gì

Stress testing là gì? Đó là việc cố tình đẩy tải vượt xa ngưỡng bình thường — tăng dần số người dùng ảo cho tới khi hệ thống bắt đầu lỗi hoặc sập — nhằm tìm ra breaking point (điểm gãy) và quan sát hệ thống suy giảm, hỏng, rồi phục hồi ra sao. Ở đây ta chủ động "làm khó" hệ thống, không mô phỏng tải thật nữa.

Vẫn là Hệ thống đặt phòng họp, nhưng lần này mình không dừng ở 200 người. Mình đẩy lên 500, 1000, 2000 người dùng đồng thời… tới khi trang bắt đầu timeout, database từ chối kết nối, hoặc server trả lỗi 500. Điểm mà hệ thống "gục" chính là breaking point ta muốn biết.

  • Mục tiêu: biết giới hạn chịu đựng, xem lỗi xuất hiện ở đâu trước (CPU, RAM, connection pool, database), và hệ thống có hồi phục khi hạ tải không.
  • Cách chạy: tăng tải liên tục vượt ngưỡng, hoặc giữ tải rất cao trong thời gian dài, ghi lại thời điểm và cách hệ thống bắt đầu degrade.
  • Quan sát: error rate leo thang, response time tăng đột biến, và quan trọng: sau khi hạ tải, hệ thống có tự trở lại bình thường (graceful recovery) hay treo luôn.

Một hệ thống tốt không phải là hệ thống "không bao giờ gãy" — mà là gãy có kiểm soát: báo lỗi rõ ràng, không mất dữ liệu, và phục hồi được khi tải giảm.

Các chỉ số: response time, throughput, error rate, concurrency

Dù chạy load hay stress test, bạn đều nhìn vào một bộ chỉ số hiệu năng chung. Đây là bảng mình hay dùng để giải thích cho học viên:

Chỉ số Ý nghĩa Đơn vị
Response time Thời gian từ lúc gửi request tới lúc nhận đủ phản hồi ms / giây
Throughput Số request (hoặc giao dịch) hệ thống xử lý trong 1 giây req/s hoặc TPS
Error rate Tỷ lệ request lỗi trên tổng số request %
Concurrency Số người dùng / request đang hoạt động cùng lúc số user

Vài lưu ý mình muốn nhấn để bạn không hiểu sai:

  • Response time — đừng chỉ nhìn con số trung bình (average), vì nó dễ che giấu những request chậm. Nên nhìn percentile, thường là p90/p95 (90% hoặc 95% request nhanh hơn ngưỡng này). Ví dụ "p95 = 1,8 giây" nghĩa là 95% người dùng chờ dưới 1,8 giây — thông tin hữu ích hơn nhiều so với con số trung bình.
  • Throughput là throughput là gì hay bị nhầm với concurrency: throughput đo việc đã xong (req/s), còn concurrency đo số việc đang chạy song song. Throughput cao mà response time thấp mới là tốt.
  • Error rate tăng là dấu hiệu đầu tiên báo hệ thống sắp tới giới hạn — trong stress test, đây thường là "chuông báo" của breaking point.
  • Concurrency là số người dùng thực sự hoạt động đồng thời; trong công cụ như JMeter nó được mô phỏng bằng virtual users (thread). Lưu ý: 1000 virtual users cấu hình sẵn không đồng nghĩa 1000 request cùng lúc — còn phụ thuộc ramp-up và thời gian nghĩ (think time).

Muốn thực hành đo các chỉ số này bằng công cụ cụ thể, bạn xem JMeter là gì và bài hướng dẫn kiểm thử hiệu năng web JMeter.

Spike & endurance test (bổ sung)

Ngoài load và stress, có hai biến thể bạn nên biết vì hay bị hỏi trong phỏng vấn:

  • Spike test: đổ một lượng tải tăng đột ngột trong thời gian rất ngắn rồi rút đi, mô phỏng tình huống bất ngờ — ví dụ công ty gửi email thông báo họp toàn thể và cả nghìn người vào đặt phòng cùng một phút. Mục tiêu là xem hệ thống có nuốt nổi cú sốc và phục hồi nhanh không.
  • Endurance test (soak test): giữ tải ở mức vừa phải (thường quanh mức load kỳ vọng) nhưng kéo dài nhiều giờ hoặc nhiều ngày, để phát hiện các vấn đề chỉ lộ ra theo thời gian như memory leak (rò rỉ bộ nhớ), đầy log, hoặc connection pool cạn dần.

Có thể hình dung nhanh: spike test kiểm tra "cú sốc bất ngờ", endurance test kiểm tra "sức bền lâu dài", load test kiểm tra "ngày làm việc bình thường", còn stress test kiểm tra "giới hạn chịu đựng". Bốn góc nhìn bổ sung cho nhau, không thay thế nhau.

Nếu gặp thuật ngữ lạ khi đọc, bạn tra nhanh ở thuật ngữ kiểm thử cho chắc.