Nay mình lại chơi trò lên group thấy câu hỏi nào hay thì kéo về viết bài blog để đỡ phải nghĩ content. Câu hỏi của bài này là:

Đại ý của câu hỏi vì sao số request không đủ như config?

Config của bạn ý như sau:

Threads (VU): 5000
Ramp-up     : 1 (s)
Loop count  : Infinte
Duration    : 600 (s)

Với config này, ta có thể hiểu là start 5000 threads trong vòng 1s, kéo việc run test trong vòng 600s (10min).

Tham khảo các câu trả lời của các bạn trong group:

Câu trả lời này hóa ra lại là 3 câu hỏi khác mà 3 câu hỏi này không trực tiếp trả lời vấn đề, cuối cùng kết luận là do “service xử lý không kịp, response time 3-10s” mà không có mấy dòng giải thích vì sao.

Một vài bạn khuyên nên tăng ramp-up:

Có vẻ như việc tăng ramp-up không match với yêu cầu của người đặt câu hỏi.

Bạn này không trả lời đúng vào câu hỏi nhưng có đưa ra nhiều phân tích đúng đắn.

• 5k request khác với CCU 5000
• Tổng số request đã gửi từ 5000 threads là 706K request
• Ramp-up liên quan nhiều đến việc tạo load của generator chứ không liên quan gì đến khả năng đáp ứng của server.

Bạn đưa ra mấy ý như sau:

• Client đang “ép” server xử lý 5000 req/s –> 300K req/min –> 3M req/10min.
• Server có thể còn làm nhiều việc khác sau khi nhận 1 request và server đang không đạt đc mức 5000 req/s
• Compare số liệu ở client và monitor ở server, có thể monitor đếm sai hoặc do server quá tải không xử lý được như kỳ vọng dẫn đến failed request.

Ý số 1 của bạn này mình không đồng ý, client gửi bao nhiêu lên chả được, client có ép được server phải xử lý bao nhiêu đâu. Ví dụ như ở server, có thể setting 1 cái thread pool bằng 10, có nghĩa là chỉ xử lý 10 requests đồng thời từ client thôi, không quan tâm đến số lượng request được gửi đến server là bao nhiêu, nó hold hết cho vào queue rồi xử lý dần dần. Vậy nên client có thể gửi 5000 req/s cùng lúc nhưng server không nhất thiết phải xử lý 5000 request đó cùng lúc.

Ý số 2 hình như cũng không trả lời trực tiếp cho câu hỏi “vì sao monitor không nhìn thấy đủ số lượng request?”

Ý số 3 thì khá hợp lý khi cần compare số liệu client và server và cũng có thể monitor đếm sai thì sao.

Ý của bạn này là có thể jmeter không đẩy đủ tải lên cho server, nên số lượng request không đủ. Good point nhưng bạn sai trong TH này rồi, JMeter bị giới hạn bởi hardware nhưng không phải fix là 2k-3k CCU, mà nó tùy vào từng máy run test. Mình đã giải thích ở bài này.

• Nên dùng loại thread group khác
• Cần điều chỉnh ramp-up
• Chưa chắc request thành công vì thiếu assertion

Cả 3 ý đều không liên quan gì đến câu hỏi nhưng là good reminder cho người hỏi. Hãy xem xét lại với yêu cầu từ sếp, bạn chuyển thành script jmeter như vậy đã đúng và hợp lý hay chưa. Nhìn chung 3 gợi ý của bạn này cũng … ok.

Đây là câu trả lời tưởng chừng vô dụng nhưng rất đáng để xem xét. Liệu rằng bạn đã hiểu cái thông số chart trên tool monitor nó thể hiện cái gì chưa, biết đâu nó không match với cái bạn đang nghĩ thì sao?

Số phiên hiện tại ở đây là gì?

Cuối cùng là câu trả lời của mình:

• Với config trên + giả định hardware dư thừa, dưới client sẽ tạo đủ 5K threads và duy trì 5K threads này đủ 10 phút. Trong thời gian 10 phút đó, mỗi thread sẽ liên tục làm nhiệm vụ

Gửi request --> server process --> nhận response --> Gửi request ....

Thời gian gửi request sẽ rất nhỏ so với thời gian server process, vậy nên có thể thấy là hầu hết trong quãng thời gian 10p, lúc nào server cũng đang è cổ xử lý 5K request cùng lúc. Có nghĩa là dưới client và trên server khá match nhau về việc bao nhiêu request đang được xử lý cùng lúc

• Vậy vấn đề có thể là tool monitor?
  • Phải biết “Số phiên hiện tại trên Backend của HAProxy” thể hiện điều gì đã? –> nếu nó là số concurrent session mà server đang handle thì có thể thấy nó khá match với client, khi đã có thời điểm nó đạt 5K (phút thứ 5)
  • Vì sao chỉ có 1 thời điểm đạt 5K mà không phải là toàn bộ 10p đạt 5k? Vì theo mình cái tool này điểm vẽ chart của nó là 5min nó vẽ 1 điểm. =))))) nó chỉ vẽ ở 3 mốc: 0, 5, 10 –> đoạn 1,2,3,6,7,8 nó có vẽ điểm nào đâu. Đây cũng là 1 vấn đề thường gặp khi phân tích chart report trên jmeter, mức độ granurality quá lớn, dẫn đến hiểu sai luôn quá trình run test.

Nếu granurality = 1 phút thì đồ thị có thể như sau:

Kết luận:

Đây là 1 câu hỏi khó vì câu hỏi tập trung vào vấn đề sai lệch ở công cụ monitor ở 2 đầu client và server. Mình sẽ không có comment gì thêm về việc bạn run thế có đúng yêu cầu hay không hay bạn có nền tảng về perf test chưa, mình chỉ đang tập trung vào câu hỏi và xem xét các ý trả lời của các bạn khác. Và câu trả lời của mình chưa chắc đã đúng vì mình cũng chỉ suy luận dựa trên những gì bạn cung cấp thôi.