Kiểm thử hiệu năng là một bước quan trọng trong quy trình phát triển và triển khai phần mềm, giúp xác định khả năng chịu tải của hệ thống. Break-point Test là một phương pháp quan trọng để xác định giới hạn tối đa mà hệ thống có thể chịu đựng. Bài viết này sẽ chia sẻ kinh nghiệm thực hiện Break-point Test sử dụng JMeter.

Mục đích khi thực hiện Break-point Testing:

• Xác định điểm break-point của ứng dụng.
• Kiểm tra thời gian phản hồi của ứng dụng ở mức tải khác nhau.
• Giám sát tài nguyên máy chủ.
• Xác định tác động của lỗi lên các hệ thống khác.
• Điều tra thêm nhằm tối ưu, cải thiện hiệu năng chung.

Khi nào nên thực hiện kiểm thử Break-point?

• Dự kiến tải của hệ thống sẽ tăng liên tục (ví dụ: các chương trình flashsale). Cần đánh giá và tìm ra điểm ngưỡng của hệ thống để có kế hoạch cải thiện.
• Mức tiêu thụ tài nguyên hiện tại được coi là cao.
• Sau khi có những thay đổi lớn về mã nguồn hoặc hạ tầng.

Cách thức thực hiện kiểm thử Break-point

Break-point là loại hình đánh giá/tìm ngưỡng hệ thống, vì vậy yêu cầu sẽ không rõ ràng, cụ thể. Không có tiêu chí rõ ràng để đánh giá hệ thống PASSED hay FAILED. Tuy nhiên, bạn có thể tham khảo các yêu cầu về non-functional requirement (NFR) như sau:

• Thực hiện break-point test để xác định khả năng chịu tải tối đa của ứng dụng.
• Lưu ý đến thời gian phản hồi (và không có giới hạn về thời gian phản hồi, tùy thuộc vào mô hình kinh doanh của bạn).
• Giám sát tài nguyên máy chủ.

Công cụ: Sử dụng JMeter và sử dụng ConcurrencyThreadGroup (hoặc Stepping Thread Group). Tải plugin tại đây.

Cài đặt thông số trong JMeter:

• Target Concurrency: Số lượng Virtual User (VU) mong muốn. Càng nhiều VU, càng tốt.
• Ramp-up Time: Thời gian để tạo đủ số lượng VUs.
• Ramp-up Steps count: Số bước nhảy trong kịch bản test. Ta có thể tính được số lượng VU được tạo trong mỗi bước = Target Concurrency / Ramp-up Steps count.
• Hold Target Rate Time: Thời gian duy trì số lượng VUs mong muốn.

Bạn hãy hình dung nó như hình bậc thang, cứ mỗi bậc là 1 lượng VU được tăng lên, ta sẽ đi tới khi nào không thể leo được lên nữa hoặc bậc thang đó bị hỏng.

Ví dụ triển khai:

Hãy nhớ, khi sử dụng Break-point hãy lưu ý, mỗi bước nhảy cần được duy trì tối thiểu 3 – 10mins, như vậy mới đảm bảo server xử lý đúng và đủ với lượng request được tạo ra từ số lượng VU tương ứng.

Cách tính cụ thể như sau:

• • Target Concurrency: Giả sử 2000 VU.
  • Ramp-up Time: Mỗi bước nhảy sẽ duy trì trong 3mins, vậy thời gian cần để tạo là 3* Ramp-up Steps count = 3*200 = 600.
  • Ramp-up Steps count: Mỗi lần tăng 10 VU -> Như vậy là sẽ có 200 nhịp nhảy (2000/10).
  • Hold Target Rate Time: Ta để 01, vì khi thực hiện Break-point không cần duy trì quá dài khi đã đủ VU.

Hướng dẫn tính toán và thực hiện Break-point:

Dựa trên kinh nghiệm, Testek gợi ý bạn một số tiêu chí nhằm xác định đâu là ngưỡng của hệ thống:

• Hiệu năng hệ thống/sản phẩm:
  • Level 1: Thời gian phản hồi tăng nhanh khi VUs tăng, ảnh hưởng nghiêm trọng đến trải nghiệm người dùng.
  • Level 2: Tỷ lệ timeout lớn (trên 30%) cần theo dõi.
  • Level 3: Tỷ lệ lỗi lớn (>30%), cần theo dõi tiếp.
  • Level 4: Hệ thống bị sập, không thể xử lý yêu cầu.
• Tài nguyên hệ thống: Thông tin tài nguyên tăng nhanh, mạnh và đạt > 80% (Khi đạt 80% thì cần bắt đầu theo dõi, cái này không có con số cố định đâu, tuỳ từng hệ thống mà sẽ define tỷ lệ tương ứng, có đơn vị thì 75% họ đã bắt đầu xem xét, nhưng có đơn vị 90% hoặc thậm chí tới 100% luôn).

Cần thực thi kịch bản vài lần (tối thiểu 3 lần) để có kết quả chính xác và tin cậy nhất và thực hiện lại sau khi đã được xử lý hoặc cải tiến từ server.

Các lưu ý khi thực hiện kiểm thử Break-point:

• Tránh kiểm thử trong môi trường không giới hạn tài nguyên (cloud, DevOps môi trường không có giới hạn về tài nguyên): Ví dụ hệ thống sử dụng cloud, được DevOps thiết lập scale tuỳ thích và không có limit về số lượng Pod/Node hoặc tài nguyên cho từng đơn vị đó, vì thế hãy yêu cầu môi trường với số lượng tài nguyên thực tế.
• Tăng tải dần dần, tránh tăng tải đột ngột gây sai lệch kết quả: Tăng tải đột ngột có thể gây vấn đề sai lệch về kết quả trong việc xác định nguyên nhân và thời điểm hệ thống bắt đầu gặp sự cố.
• Định nghĩa rõ ràng về “sự cố” của hệ thống: Nên xác định các mức độ sự cố khác nhau (Có thể tham khảo gợi ý trên từ Testek).
• Lặp lại kiểm thử sau khi đã điều chỉnh hệ thống: Sau khi tinh chỉnh hệ thống, nên lặp lại kiểm thử để xác định liệu giới hạn hệ thống có thay đổi hay không.

Phân tích kết quả kiểm thử Break-point

Sau khi thực hiện Break-point test và xác định được giới hạn, bạn có thể:

• Chấp nhận giới hạn và chuẩn bị biện pháp khi hệ thống gần đạt tới giới hạn.
• Tinh chỉnh hệ thống để mở rộng giới hạn.
• Nếu quyết định tinh chỉnh, lặp lại kiểm thử để đánh giá hiệu quả.