JMeter nền tảng: dựng test plan tải từ số 0

1. JMeter là gì và khi nào cần load testing

Apache JMeter là công cụ mã nguồn mở của Apache Software Foundation, viết bằng Java, dùng để đo hiệu năng và độ chịu tải của ứng dụng. Ban đầu JMeter sinh ra để kiểm thử web nhưng nay hỗ trợ HTTP/HTTPS, REST/SOAP, JDBC (cơ sở dữ liệu), JMS, FTP, gRPC qua plugin và nhiều giao thức khác. Với một nhà mạng viễn thông, khi hàng triệu thuê bao đồng loạt tra cứu cước hay nạp thẻ vào đầu tháng, câu hỏi không phải 'chức năng có chạy không' mà là 'hệ thống chịu được bao nhiêu người cùng lúc trước khi chậm hoặc sập'. Đó chính là bài toán load testing mà JMeter giải quyết.

Cần phân biệt các loại kiểm thử hiệu năng: load test đo hành vi ở tải kỳ vọng; stress test đẩy quá giới hạn để tìm điểm gãy; spike test mô phỏng tăng đột ngột; soak (endurance) test chạy dài để phát hiện rò rỉ bộ nhớ. JMeter làm được cả bốn nhờ điều chỉnh số luồng, thời gian ramp-up và độ dài phiên. Người mới hay nhầm 'chạy 100 request' với 'load test', nhưng load test thật cần mô phỏng người dùng đồng thời (concurrency) kèm think-time thực tế, dữ liệu đa dạng và tiêu chí pass/fail rõ ràng theo SLA.

2. Giải phẫu một Test Plan

Mọi kịch bản JMeter đều nằm trong một Test Plan — nút gốc của cây (file .jmx dạng XML). Dưới Test Plan là các thành phần được thực thi theo thứ tự và phạm vi (scope) nhất định: Thread Group chứa người dùng ảo; bên trong là Config Elements (áp cấu hình chung), Samplers (gửi request thật), Timers (chèn thời gian chờ), Assertions (kiểm tra kết quả) và Listeners (thu thập số liệu). Hiểu thứ tự này là chìa khóa: Config Element luôn được áp trước khi Sampler chạy dù nằm ở đâu trong cùng scope; còn Sampler chạy tuần tự từ trên xuống.

File .jmx là XML nên có thể đọc và version-control bằng Git. Tuy nhiên bạn nên chỉnh sửa qua GUI cho các thay đổi lớn để tránh làm hỏng cấu trúc; chỉ sửa tay những giá trị đơn giản như số threads được tham số hóa. Dưới đây là một đoạn .jmx rút gọn cho ThreadGroup — chú ý các thuộc tính ramp-up, số luồng và vòng lặp được lưu dưới dạng thẻ stringProp.

<ThreadGroup guiclass="ThreadGroupGui" testname="Subscribers - Balance Check" enabled="true">
  <intProp name="ThreadGroup.num_threads">200</intProp>
  <intProp name="ThreadGroup.ramp_time">60</intProp>
  <boolProp name="ThreadGroup.scheduler">true</boolProp>
  <stringProp name="ThreadGroup.duration">600</stringProp>
  <elementProp name="ThreadGroup.main_controller" elementType="LoopController">
    <boolProp name="LoopController.continue_forever">false</boolProp>
    <intProp name="LoopController.loops">-1</intProp>  <!-- -1 = lặp mãi tới khi hết duration -->
  </elementProp>
</ThreadGroup>

3. Thread Group: users, ramp-up, loops

Thread Group là trái tim của mọi kịch bản: mỗi thread mô phỏng một người dùng ảo độc lập, có bộ biến riêng và duyệt qua các Sampler tuần tự. Ba tham số cốt lõi là Number of Threads (số user ảo), Ramp-Up Period (thời gian tính bằng giây để khởi động dần đủ số thread) và Loop Count (số lần lặp kịch bản mỗi thread). Ví dụ 200 threads với ramp-up 60 giây nghĩa là cứ mỗi 0,3 giây thêm một user vào — cách này tránh 'thundering herd' làm sai lệch kết quả vì mọi user ập vào cùng khoảnh khắc.

• Number of Threads = số người dùng ảo đồng thời (tối đa), không phải tổng số request.
• Ramp-Up quá ngắn tạo spike giả; quá dài thì không bao giờ đạt tải đích. Quy tắc thường dùng: ramp-up ≈ số thread để lên 1 user/giây.
• Loop Count = -1 hoặc dùng Scheduler + Duration để chạy theo thời gian thay vì theo số vòng.
• Tổng request ≈ threads × loops × số sampler; hãy tính trước để khỏi bất ngờ về lưu lượng.