Xác định giới hạn hệ thống (Break-point)

Một câu hỏi tưởng chừng đơn giản nhưng hiếm đội ngũ nào trả lời được trước khi sự cố xảy ra: hệ thống của bạn chịu được bao nhiêu người dùng cùng lúc trước khi sập? Phần lớn chỉ biết con số đó vào đúng đêm flashsale — khi đã quá muộn để làm gì khác ngoài chứng kiến nó gãy.

Vấn đề không nằm ở chỗ hệ thống nhanh hay chậm lúc bình thường, mà ở chỗ bạn không biết ngưỡng tối đa của nó nằm ở đâu. Khi tải dự kiến tăng liên tục, khi tài nguyên đã ở mức cao, hoặc sau một thay đổi lớn về mã nguồn hay hạ tầng, việc mù mờ về giới hạn chịu tải đồng nghĩa với việc bạn đang đánh cược với downtime. Break-point Test sinh ra để tìm chính xác cái ngưỡng đó — trong môi trường kiểm soát, trước khi người dùng thật tìm ra nó giúp bạn.

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

• Break-point Test là gì và khi nào bắt buộc phải thực hiện.
• Cách cấu hình kịch bản "bậc thang" bằng JMeter với bốn tham số cốt lõi.
• Bộ tiêu chí 4 cấp độ để xác định đâu là điểm gãy thật sự của hệ thống.
• Những cái bẫy khiến kết quả break-point trở nên vô nghĩa.

Break-point Test là gì?

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. Trong đó, Break-point Test là phương pháp dùng để xác định giới hạn tối đa mà hệ thống có thể chịu đựng — tức điểm tải mà tại đó hệ thống bắt đầu gãy. Đây là loại hình đánh giá / tìm ngưỡng, nên yêu cầu thường không rõ ràng và không có tiêu chí PASSED/FAILED cố định.

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 ở các 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ó kế hoạch cải thiện.
• Mức tiêu thụ tài nguyên hiện tại đang đượ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

Vì Break-point là loại hình tìm ngưỡng, bạn không thể trông chờ một tiêu chí PASS/FAIL rạch ròi. Tuy nhiên, có thể tham khảo các yêu cầu phi chức năng (non-functional requirement — NFR) sau làm khung định hướng:

• 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 cứng về thời gian phản hồi — tùy thuộc mô hình kinh doanh của bạn).
• Giám sát tài nguyên máy chủ.

Công cụ và cách cài đặt

Sử dụng JMeter cùng Concurrency Thread Group (hoặc Stepping Thread Group). Tải plugin tại đây. Bốn tham số cốt lõi cần cấu hình:

Tham số	Ý nghĩa
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 VU.
Ramp-up Steps count	Số bước nhảy trong kịch bản test. Số VU tạo ra mỗi bước = Target Concurrency / Ramp-up Steps count.
Hold Target Rate Time	Thời gian duy trì số lượng VU mong muốn.

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

Ví dụ triển khai

Kinh nghiệm thực chiến. Mỗi bước nhảy cần được duy trì tối thiểu 3 – 10 phút. Chỉ khi đó server mới có đủ thời gian xử lý đúng và đủ với lượng request sinh ra từ số lượng VU tương ứng — nếu không, kết quả sẽ phản ánh sai sức chịu tải thật.

Cách tính cụ thể cho một kịch bản 2000 VU:

• Target Concurrency: giả sử 2000 VU.
• Ramp-up Steps count: mỗi lần tăng 10 VU → có 200 nhịp nhảy (2000 / 10).
• Ramp-up Time: mỗi bước nhảy duy trì 3 phút → thời gian cần để tạo là 3 × 200 = 600 (phút).
• Hold Target Rate Time: để 01, vì khi thực hiện break-point không cần duy trì quá dài sau khi đã đủ VU.

Hướng dẫn tính toán và xác định điểm gãy

Dựa trên kinh nghiệm, Testek gợi ý một số tiêu chí để xác định đâu là ngưỡng thật của hệ thống. Hai nhóm cần theo dõi song song là hiệu năng và tài nguyên:

Theo hiệu năng hệ thống / sản phẩm

Cấp độ	Dấu hiệu	Hành động
Level 1	Thời gian phản hồi tăng nhanh khi VU tăng	Ảnh hưởng nghiêm trọng 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	Đã chạm điểm gãy

Theo tài nguyên hệ thống

Thông tin tài nguyên tăng nhanh, mạnh và đạt > 80%. Khi chạm 80% thì cần bắt đầu theo dõi — đây không phải con số cố định: tùy từng hệ thống mà define tỷ lệ tương ứng, có đơn vị 75% đã bắt đầu xem xét, nhưng có đơn vị tới 90% hoặc thậm chí 100% mới quan tâm.

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 đã xử lý hoặc cải tiến từ phía 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: ví dụ hệ thống dùng cloud được DevOps thiết lập scale tùy thích, không limit số lượng Pod/Node hay tài nguyên cho từng đơn vị. 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: tăng tải đột ngột có thể gây sai lệch 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 ý 4 cấp độ ở 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, nên lặp lại để 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ó ba hướng đi:

• 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 ngưỡng.
• 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ả thực tế.

Kết luận

Break-point Test không phải để chứng minh hệ thống "khỏe", mà để chủ động biết trước nó gãy ở đâu. Khi bạn tăng tải theo bậc thang một cách kỷ luật — duy trì mỗi bậc đủ lâu, theo dõi đồng thời hiệu năng và tài nguyên, lặp lại tối thiểu 3 lần — con số "giới hạn tối đa" không còn là ẩn số đáng sợ, mà trở thành dữ liệu để bạn lên kế hoạch mở rộng và phòng ngừa downtime.

Bạn đã từng tìm ra break-point bất ngờ của một hệ thống tưởng chừng "khỏe"? Hãy chia sẻ kinh nghiệm thực chiến của bạn để cộng đồng cùng học hỏi và nâng cao kỹ năng kiểm thử hiệu năng.