Disclaimer:

Tester có dùng cách này hay không, không liên quan đến tôi.

Yêu cầu thực hiện performance test từ khách hàng hoặc từ PM không có kinh nghiệm hoặc không biết tech là “Hệ thống có đáp ứng được 200 users trong 1 thời điểm hay không?” Với họ, users là đơn vị sát nhất và dễ hiểu nhất.

Tuy nhiên, thực tế thì users không phải là load của hệ thống mà chỉ là tác nhân tạo load mà thôi.

User --> client --> request --> server

Giả sử User click button Login trên Web Browser (client), Web Browser gọi 3 requests lần lượt đến Server. Vậy thì Request mới là load của Server.

Để làm được yêu cầu trên của khách hàng, tester phải:

• Xác định scenario run test: Vì mỗi scenario sẽ gọi các request khác nhau mà mỗi request lại yêu cầu server xử lý khác nhau –> tiêu tốn resource khác nhau –> performance sẽ khác nhau.
• Hỏi lại xem “200 users trong 1 thời điểm” là như thế nào? Vì có khi khách hàng mong muốn 200 users cùng bấm button login, 200 users tạo ra 200 transactions trong 1 phút, hoặc đơn giản là họ thấy số lượng users của system là 200 người thì có nghĩa là server phải phục vụ tốt cho 200 users này. Cái này rất quan trọng thì nó sẽ thay đổi đến cách mình tạo load profile, load profile thay đổi thì load lúc run test sẽ thay đổi –> ảnh hưởng đến kết quả. NOTE: thông thường PM sẽ nghĩ là 200 users 1 thời điểm có nghĩa là 200 req/s, tester sẽ set số CCU = 200, khi run test thực tế server chết bất đắc kỳ tử –> PM thay đổi yêu cầu sang 200 users/ phút. hahahaha
• Cuối cùng, bạn sẽ cần phải làm rõ nghĩa của cái từ “đáp ứng”. Vì đáp ứng là thế nào? có được phép có request error ko? Nếu có thì tỉ lệ error là bao nhiêu? Nếu không có error thì response time như thế nào là đạt yêu cầu, hay cứ có throughput 200 req/s là được response có dài 60s cũng ok? Và nếu response time < 3s thì đây là mean hay percentile 90 của response time.

Nếu tester nào mà không làm những điều cơ bản trên mà hục mặt đi làm thì chỉ có chết, rồi chạy đi hỏi khắp nơi thôi. Làm xong cũng không biết làm đúng hay sai.

– Q: Ê ê ông ơi, ông nói dài phết rồi mà tôi chưa thấy ông nói đến đoạn “lừa đảo” trong báo cáo nhỉ?

– A: Đây đây, đang định nói đây, gì mà nóng.

Như bạn đã thấy thì khách hàng và PM chỉ quan tâm đến “users”, còn server thì chỉ quan tâm đến số lượng request. Và thật tình cờ, users có thể thay đổi rate gửi request bằng think time.

Think time là thời gian mô phỏng thời gian đọc thông tin và action của users thật khi thao tác trên application.

Ví dụ: Users thật mở login page, điền username & password, click login. Think time chính là thời gian user đợi login page load xong, điền thông tin và click login. Có nghĩa là giữa 2 request có 1 khoảng thời gian nghỉ.

Nếu bạn thay đổi giá trị của think time, bạn sẽ trực tiếp thay đổi arrival rate đến server.

Giả sử: vẫn là 200 users

• Nếu think time = 0, thời gian run test là 10min, tổng số request là 300.000.
• Nếu có think time > 0, thời gian run test vẫn là 10min, tổng số lượng request là 150.000.

Trường hợp 1 gây ra quá tải cho server –> bạn kết luận server không thể đáp ứng cho 200 users 1 lúc

Trường hợp 2 server chạy khỏe re –> bạn kết luận server có thể đáp ứng cho 200 users 1 lúc.

Đây là chính là chút “mánh khóe” trong báo cáo performance test. Thay đổi think time, bạn sẽ biến từ “không đáp ứng” thành “đáp ứng”.

– Q: Ơ sao lại thế, thế trong 2 TH trên thì cái nào là đúng, cái nào là sai?

– A: Cái nào cũng đúng cả thôi, cái sai là kết luận của performance test không phải là số lượng users, nó nên là throughtput và response time, sai chính từ câu hỏi rồi. hahaha

– Q: Làm thế nào để set think time cho đúng, có quy tắc gì không?

– A: Không chả có quy tắc gì cả, thông thường mình sẽ record scenario và tool sẽ tự tạo think time tương ứng cho mình. Để trông thật hơn, mình nên có khoảng thời gian +/- cho think time.

Kết luận: think time là 1 thứ bạn cần phải biết khi làm performance test, hãy dùng đúng lúc, đúng chỗ để có thể tự tin với kết quả performance test. Còn bạn đọc bài xong vẫn không tự tin, hãy đăng ký khóa học perfomance test basic của mình. 😀