![[Performance JMeter] Bài 16 - Thực hành đổ tải, giám sát và phân tích báo cáo](/uploads/course/performance_testing_with_jmeter_and_grafana_monitor.png)
NỘI DUNG BÀI HỌC
✅ Các khái niệm cơ bản
✅ Mối quan hệ giữa Response Time và Throughput
✅ Hành vi hệ thống khi đổ tải
✅ Phân tích báo cáo tổng quan JMeter
✅ Tổng kết đánh giá hiệu năng
✅ Thực hành & Case Study
✅ Kết luận chung
1️⃣ Các khái niệm cơ bản
| Thuật ngữ | Mô tả | Mục tiêu tốt |
|---|---|---|
| Response Time | Thời gian tính từ khi client gửi request đến khi nhận được phản hồi hoàn chỉnh từ server. Cấu phần: Client Request → Network Time → Server Processing → Network Time → Client Response |
Thấp |
| Throughput | Số lượng request được xử lý thành công trong một đơn vị thời gian (giây hoặc phút). Đơn vị đo thường dùng: • TPS (Transactions per Second) • RPS (Requests per Second) |
Cao |
| Percentile (P90, P95, P99) | Biểu diễn mức phân bố thời gian phản hồi. Ví dụ: • P90 = 300ms → 90% request có thời gian phản hồi ≤ 300ms. • P99 thể hiện tail latency – hiệu năng ở nhóm chậm nhất. |
Duy trì ổn định (đặc biệt là P95, P99) |
2️⃣ Mối quan hệ giữa Response Time và Throughput
Response Time và Throughput có mối quan hệ tỷ lệ nghịch:
-
Khi Response Time thấp, hệ thống phản hồi nhanh hơn → Throughput cao.
-
Khi Response Time cao, hệ thống xử lý chậm hơn → Throughput giảm.
| Response Time | Throughput | Đánh giá | Giải thích |
|---|---|---|---|
| Thấp | Cao | ✅ Tốt (OK) | Hệ thống hoạt động ổn định, hiệu năng tốt. |
| Cao | Thấp | ❌ Không tốt (NOK) | Có thể có bottleneck tại CPU, database, memory hoặc I/O. |
| Cao | Cao | ⚠️ Bất thường (KOK) | Cần kiểm tra lại — có thể do network, log ghi chậm, hoặc lỗi monitor. |
| Thấp | Thấp | 🚫 Không hợp lệ | Có thể do test script lỗi hoặc hệ thống chưa nhận đủ tải. |
👉 Kết luận:
Giữa Response Time và Throughput thường tồn tại tỷ lệ nghịch hợp lý. Nếu một trong hai thay đổi bất thường, cần phân tích nguyên nhân chi tiết qua các yếu tố như network, server resource, database, hoặc logic xử lý ứng dụng.
3️⃣ Khi mức tải (CCU) không đổi
Giả sử số lượng người dùng đồng thời (Concurrent Users – CCU) được giữ cố định trong suốt quá trình kiểm thử.
| Thành phần | Kỳ vọng | Giải thích / Ghi chú |
|---|---|---|
| Response Time | Dao động nhỏ, có độ lệch chuẩn thấp. Ví dụ: Trung bình ~200ms, Min ≈ 100ms, Max ≈ 400ms. |
Cho thấy hệ thống hoạt động ổn định, khả năng xử lý request nhất quán. Nếu Response Time dao động lớn hoặc tăng dần theo thời gian, có thể hệ thống bắt đầu gặp vấn đề về hiệu năng (như rò rỉ bộ nhớ, queue backlog hoặc contention). |
| Throughput | Duy trì ổn định trong suốt quá trình test, tương ứng với mức CCU đang chạy. | Nếu Throughput giảm dần dù CCU không thay đổi, điều đó cho thấy hệ thống đang mất khả năng xử lý ổn định — có thể do resource contention, GC pause, hoặc database chậm dần theo thời gian. |
Ví dụ: Số lượng CCU không thay đổi trong quá trình chạy
b. Báo cáo không đạt kì vọng
4️⃣ Khi mức tải (CCU) thay đổi
Khi thực hiện Performance Test với mức tải tăng dần (CCU tăng theo thời gian), ta quan sát khả năng chịu tải và độ ổn định của hệ thống.
| Thành phần | Kỳ vọng | Ghi chú / Giải thích |
|---|---|---|
| Response Time | Có thể tăng nhẹ khi tải tăng, nhưng phải nằm trong ngưỡng chấp nhận được (được thống nhất giữa khách hàng, nhóm Dev, và System Architect). | Việc tăng nhẹ là bình thường do tài nguyên hệ thống được chia sẻ cho nhiều request hơn. Nếu tăng đột biến hoặc dao động mạnh, có thể hệ thống đã đạt ngưỡng chịu tải. |
| Throughput | Khi tải tăng, nếu hệ thống xử lý tốt, Throughput sẽ tăng tương ứng với CCU. | Dấu hiệu của hệ thống có khả năng scale tốt và vẫn duy trì hiệu năng khi số lượng người dùng tăng. |
| Điểm giới hạn (Break Point) | Tại một mức CCU nhất định, Throughput ngừng tăng hoặc bắt đầu giảm, trong khi Response Time tăng nhanh. | Đây là ngưỡng hiệu năng tối đa (System Capacity Limit) – dùng làm căn cứ cho Capacity Planning và tối ưu hệ thống. |
Ví dụ:
a. Báo cáo đạt kì vọng
b. Báo không đạt kì vọng
5️⃣Liên hệ với báo cáo JMeter
Trong báo cáo JMeter, bạn thường theo dõi các chỉ số:
-
Response Time: Average, Median, P90, P95, P99
-
Throughput: Requests per Second (RPS)
-
Error %: Tỷ lệ lỗi trong quá trình test
Khi phân tích kết quả:
-
So sánh Response Time và Throughput theo thời gian (trên biểu đồ).
-
Nếu Throughput giảm mạnh kèm Response Time tăng, khả năng cao hệ thống đã đạt ngưỡng tải.
-
Nếu cả hai chỉ số ổn định, chứng tỏ hệ thống hoạt động hiệu quả và có độ ổn định cao.
6️⃣ Tổng kết báo cáo Jmeter
| Yếu tố | Mục tiêu | Gợi ý đánh giá |
|---|---|---|
| Response Time | Càng thấp càng tốt | Theo dõi P95, P99 để đảm bảo độ ổn định. |
| Throughput | Càng cao càng tốt | Phản ánh khả năng xử lý tải thực tế của hệ thống. |
| Mối quan hệ | Tỷ lệ nghịch | Khi Response Time tăng → Throughput thường giảm. |
| Ổn định tải (CCU cố định) | Biến động nhỏ | Độ lệch chuẩn thấp → hệ thống ổn định. |
| Khi mức tải thay đổi (CCU tăng) | Response Time tăng nhẹ, Throughput tăng theo | Khi vượt ngưỡng → Throughput giảm, Response Time tăng mạnh → hệ thống đạt giới hạn chịu tải. |
7️⃣ Thực hành
🧠 Mục tiêu
-
Củng cố lý thuyết qua các kịch bản thực tế.
-
Rèn kỹ năng đọc biểu đồ, phát hiện bất thường và xác định bottleneck.
-
Làm quen với việc đánh giá hệ thống qua Response Time, Throughput, CCU.
🧩 Bài 1 – Hệ thống hoạt động tốt
Mục tiêu: Nhận diện hành vi của hệ thống ổn định, đạt kỳ vọng.
Kịch bản:
-
✅ Lượng tải không đổi (CCU cố định)
→ Response Time dao động nhỏ, Throughput ổn định. -
✅ Lượng tải thay đổi (CCU tăng dần)
→ Response Time tăng nhẹ trong giới hạn cho phép, Throughput tăng tương ứng.
⚙️ Bài 2 – Hệ thống hoạt động không tốt
Mục tiêu: Nhận diện dấu hiệu bất ổn, hiệu năng kém.
Kịch bản:
-
❌ Lượng tải không đổi (CCU cố định)
→ Response Time tăng dần theo thời gian, Throughput giảm. -
❌ Lượng tải thay đổi (CCU tăng dần)
→ Throughput không tăng hoặc giảm sớm, Response Time tăng đột biến.
🔥 Bài 3 – Server / Hạ tầng
Mục tiêu: Phân tích khi hệ thống gặp vấn đề tài nguyên.
Kịch bản:
-
⚠️ CPU cao tải (CPU-bound)
→ Response Time cao, Throughput giảm mạnh. - ⚠️ Full connection database
→ TPS đạt ngưỡng dù cpu, ram server vẫn avaiable nhiều. - ⚠️ Memory Leak (rò rỉ bộ nhớ)
→ OutOfMemory hoặc restart server.
🚀 Bài 4 – Load Test Final
Điều kiện:
+ Fix lỗi response time độ lệch chuẩn lớn
+ Fix lỗi cao tải CPU
+ Fix lỗi memory leak
+ Fix lỗi full hikari conection database
Mục tiêu:
-
Thực hành chạy load test hoàn chỉnh (end-to-end).
-
Xác định break point, system capacity, và đánh giá tổng thể hiệu năng.
-
Tổng hợp và trình bày báo cáo JMeter đầy đủ (Response Time, Throughput, Percentile, Error%).
✅ Kết luận chung
Khi phân tích hiệu năng, luôn cần xem xét Response Time, Throughput, và CCU đồng thời để có đánh giá toàn diện.
Mục tiêu không chỉ là đạt chỉ số cao, mà là đảm bảo hiệu năng ổn định, khả năng mở rộng và tính nhất quán trong điều kiện tải thực tế.
Zalo
