#15 Báo cáo kiểm thử hiệu năng spiderum và phân tích báo cáo sau khi chạy script

November 23, 2020 1 By Ntech Developers

Đầu tiên mình phải nói rằng có nhiều loại report trong Jmeter được gọi chung là listener. Tuy nhiên mình chỉ tập trung vào 3 report chính đó là: Aggregate Report, Summary Report và Graph Report

Cả 3 loại report này đều có một số thông số chung, mình cũng đã có nhắc đến trong bài trước rồi, mình xin phép nhắc lại một chút trước khi bước vào phân tích

– Mẫu thử(Sample): Số lượng yêu cầu được gửi.
– Thời gian phản hồi trung bình (Average – Avg): là thời gian đã trôi qua kể từ thời điểm yêu cầu đã cho được gửi đến máy chủ cho đến thời điểm khi thông tin cuối cùng được trả về khách hàng.
– Min và Max là thời gian phản hồi tối thiểu và tối đa.
– Độ lệch (Std Deviation): Độ lệch chuẩn đo khoảng cách trung bình của các giá trị trung bình của chúng.
– Thông lượng (Throughput): là tải thực sự được xử lý bởi máy chủ của bạn trong quá trình chạy nhưng nó không cho bạn biết bất cứ điều gì về hiệu suất của máy chủ của bạn trong cùng lần chạy này.
– Nhận và Gửi Kb/giây (Received KB/Sec, Sent KB/Sec): Thông lượng được đo bằng Kilobytes mỗi giây.
– Lỗi% (Error %): Phần trăm yêu cầu có lỗi.

Hãy tập trung vào 2 thông số quan trọng nhất của mọi Performance Report:

– Response Time: chỉ ra được việc xử lý request NHANH hay CHẬM. Response Time thì phải càng THẤP càng tốt.
– Throughput: chỉ ra được số lượng requests được server xử lý trong một đơn vị thời gian. Nên cùng một thời gian, càng xử lý được càng nhiều càng tốt tức là throughtput càng CAO càng tốt

Có 4 trường hợp có thể xảy ra:

– Response Time THẤP + Throughput THẤP: Trường hợp này giống như bạn có lượt xử lý rất tệ và trả về lại rất nhanh. Điều này khá vô lý và cũng hiếm gặp nhưng nếu nó xảy ra thì server của bạn đang bị điều phối (semaphore) chặn lượt xử lý.
– Response Time THẤP + Throughput CAO: Đây là trường hợp lý tưởng nhất vì server xử lý rất tốt và trả về rất nhanh.
– Response Time CAO + Throughput THẤP. Vấn đề này là thường xảy ra nhất khi hệ thống có vấn đề, lượng xử lý được rất ít nhưng mà thời gian trả về thì cực lâu. Có thể do server fail một luồng nào đó, hoặc quá tải hoặc bị thắt cổ chai từ phía server. Cần phải cải thiện tốc độ xử lý từ server
– Response Time CAO + Throughput CAO. Cho trường hợp này bạn phải làm rõ được vấn đề tại sao lượt xử lý của bạn rất nhiều mà tốc độ trả về lại chậm vậy. Điều này mình đã từng gặp khi server của bạn bị tràn request vào do xử lý bất đồng bộ nhưng mà xử lý không kịp dẫn tới deadlock. Còn một nguyên nhân nữa mà khiến đồng đội cái nhau đó là vấn đề từ script test bị sai, hoặc gọi dư thừa không đúng kịch bản, hoặc là nhận response parser chậm (nói chung là script cũng là người code mà, lấy một thứ chưa ổn để kiểm tra hệ thống thì vô nghĩa)

Ngoài ra mình muốn đề cập thêm 2 thông số nữa cũng nên chú ý đó là tỉ lệ phần trăm lỗi xảy ra và độ lệch (Std Deviation). Về phần trăm lỗi thì càng ít càng tốt rồi chắc không cần giải thích nhiều. Mình muốn đi kỹ hơn về độ lệch.

Std.Dev hay Standard Deviation cho biết độ lệch chuẩn của tập dữ liệu cho bạn biết các điểm dữ liệu được tập trung xung quanh giá trị trung bình như thế nào. Độ lệch chuẩn càng nhỏ, dữ liệu càng phù hợp. Độ lệch chuẩn phải nhỏ hơn hoặc bằng một nửa thời gian trung bình cho nhãn.

Công thức

Nhìn hại não nhỉ, mình lấy ví dụ để minh họa nhé

Hãy hình dung bạn đang đo chiều cao của từng loại chó (đơn vị là mm)

Trước tiên ta xác định trung bình chiều cao

Bây giờ mỗi chú chó khác nhau lại có độ lệch so với chiều cao trung bình trên khác nhau. Khi đó bạn thực hiện tính phương sai giữa chúng.

Lấy căn bậc 2 của phương sai đó chính là độ lệch trung mình theo công thức bên trên rồi

Quay trở lại bài toán ban đầu, ví dụ mình có 1 request nhận giá trị trả về rất lâu, mất khoảng 30 giây, và một request nhận giá trị trả về có vài mili giây và khi đó response trung bình của bạn sẽ cao. Vô lý! Bạn sẽ đặt câu hỏi tại sao? Khi đó thông số độ lệch này giúp bạn đánh giá được mật độ của sự chênh lệch trên nó tập trung ở đâu, từ đó có biện pháp xử lý. Và chẳng ai hi vọng có sự bất thường như vậy.

Được rồi mình bắt đầu đi vào phân tích báo cáo mà hôm trước mình đo được nhé!

Đầu tiên là xem thông số report chung:

---------------------------------
The number of thread    = 5000
Ramp up period             = 1
Sample                  = 5113
Avg                     = 211
min                     = 0
max                     = 2665
Std Deviation           = 298.91
Error %                 = 0.372%
Throughput              = 72.19712
Received KB/Sec         = 1102.85
Sent KB/Sec             = 66.14
Avg. Bytes              = 15642.1
----------------------------------
The number of thread    = 25000
Ramp up period             = 1
Sample                  = 25041
Avg                     = 235
min                     = 22
max                     = 50584
Std Deviation           = 704.14
Error %                 = 0.084%
Throughput              = 51.24883
Received KB/Sec         = 1036.71
Sent KB/Sec             = 47.35
Avg. Bytes              = 20714.4
---------------------------------

Nhìn vào report chung trên thì bạn cũng thấy thời gian trả về trung bình rất tốt đều dưới 1 giây. Nhưng thông số min và max lệch nhau quá nhiều. Ở mốc 25k CCUs thì max nó lên tới 50 giây. Throughput thấy cũng khả quan và không có gì ảnh hưởng cả. Tỉ lệ lỗi thì theo mình là có thể chấp nhận được.

Vậy là vấn đề đặt ra lúc này là độ lệch, khi chỉ số min max lệch nhau quá nhiều đồng thời thông số Std Deviation khá cao. Chúng ta cùng xem tiếpNhìn vào thông số report của 5k mình thấy kịch bản login đang có vấn đề.

Truy ngược lại kịch bản thì mình thấy việc kiểm tra home page trước khi login khá chậm. Vấn đề này phần lớn là việc check domain để phân biêt user đó là top-user hay nguoi-dung để chuyển trang domain. Điều này càng thể hiện rõ hơn khi nhìn vào 1 CCU, tức là chỉ có 1 người dùng thực hiện

Tiếp đến là tỉ lệ lỗi ở luồng tìm kiếm và luồng upvote/downvote

Điều này thì ngay cả thực hiện bằng tay mình cũng thấy có issue trong quá trình tìm kiếm rồi.

Còn upvote/downvote thì khi mình thực hiện bằng tay liên tục thì sẽ xuất hiện tính sai số lượng, mình nghĩ đây là vấn đề phát sinh.

Nhìn tiếp vào biểu đồ graph, đường xanh đi lên từ từ cho đến đỉnh và đi ngang. Điều này chứng tỏ thời gian ramp-up của mình là hợp lý. Nó đi vào từ từ đến cực đại và thực thiện kịch bản

Tuy nhiên có một điểm là đường đỏ đầu là Deviation nó lại cao ngay từ đầu và rơi từ đỉnh xuống. Vấn đề này mình nghĩ ở flow login bên trên bị thắt cổ chai nên có độ lệch cao. Tuy nhiên khi login xong hết nó cắt đường màu xanh lá thì nó đi ngang. Khá đúng với suy đoán bên trên của mình.

Nhìn thêm biểu đồ 25k CCUs