Aggregate Report là một report rất hữu ích của Jmeter

1. Các số liệu trong report:

Mọi người có thể thấy Aggregate Report là 1 report dạng table, với 12 columns ứng với 12 thông số. Chúng ta sẽ tìm hiểu xem ý nghĩa của từng thông số nhé!

• Label: Hiển thị tên của từng requests có trong test plan của bạn.

Mặc định, tất cả những request bị trùng tên trong test plan, sẽ chỉ hiển thị 1 dòng duy nhất trong table này, cho dù nội dung của các request đó có khác nhau hay nằm khác Thread Group đi chăng nữa. Vì vậy, khi đặt tên cho các Request, mọi người lưu ý nhớ điều này, và đặt tên khác nhau

Ở cuối màn hình, chúng ta để ý sẽ thấy có checkbox “Include group name in the label?”. Nếu tích chọn “Include group name in the label?” thì lable request sẽ được gán thêm tiền tố tên của Thread Group chứa request đó.

• #Samples: Tổng số lần run của request.
Công thức:

Samples = Number of Threads (users) * Loop Count

Ví dụ 1: Thread Group có cấu hình
– Number of Threads (users): 100
– Loop Count: 5
Thì 1 HTTP Request của Thread Group này sẽ run 100 x 5 = 300 (lần)
—> #Samples: 500

Tuy nhiên, công thức trên sẽ không còn đúng trong 1 số trường hợp: đó là khi Request của bạn nằm bên dưới 1 Logic Controller nào đó, chẳng hạn như Logic Controller, such as Loop Controller, Once Only Controller, While Controller,.. (Chúng ta sẽ tìm hiểu dần)
Ví dụ 2: Tiếp tục với ví dụ 1 ở trên, nhưng lần này thì hãy để HTTP Request vào 1 Logic Controller, là Loop Controller, và để giá trị Loop Count cho controller này là 2. Lúc này request của bạn sẽ run: 100 x 5 x 2 = 1000 (lần).
—> #Samples: 1000
• Average (millisecond): Thời gian phản hồi trung bình (Response Time) của request, tính cho đến lần run cuối cùng.

Ví dụ 3: Một Request A run tổng cộng 3 lần với các kết quả Response Time tương ứng là 41ms, 46ms, 56ms thì Response Time trung bình của Request A sẽ là ~47.68

• Min (millisecond): Respone Time thấp nhất của request tính cho toàn bộ tất cả các lần run.

Trong ví dụ 3 ở trên thì Min = 41ms

• Max (millisecond): Respone Time cao nhất của request tính cho toàn bộ tất cả các lần run.

Trong ví dụ 3 ở trên thì Max = 56ms

• Percentiles (millisecond): Ở đây chùng ta cần hiểu Percentiles là j để có thể hiểu được các phần sau Percentiles mọi người cũng đừng hiểu nó là phần trăm (%). Percentiles sẽ là một con số x, và đi kèm theo 1 giá trị A. Nghĩa là sẽ có x% có giá trị thấp hơn giá trị A, còn lại (100-x)% sẽ có giá trị lớn hơn giá trị A. Ví dụ: Lớp bạn có 100 người làm bài kiểm tra, Giảng viên nói bạn có Percentile là 60% có nghĩa là: Trong tất cả học sinh trong lớp (100 người) có 60 người (Tương đương 60%) có điểm thấp hơn bạn và 40 người (40%) có điểm cao hơn bạn

• Median (millisecond): Nó gần giống với trung bình, nhưng ý nghĩa thì khác hoàn toàn. Median + một giá trị A, sẽ chia toàn bộ các giá trị của bạn thành 2 phần bằng nhau, một phần sẽ chứa những giá trị < A, phần còn lại sẽ chứa những giá trị > A. Median cũng được hiểu như là 50th Percentile. Quay lại Performance, thì Median sẽ chỉ ra, sẽ có 50% số request có response time nhỏ hơn giá trị (hiển thị trên table), và 50% số request còn lại có response time lớn hơn giá trị này

• 90% Line (90th Percentile) (millisecond):nghĩa là 90% số requests sẽ có response time nhỏ hơn giá trị hiển thị trong table, 10% số requests còn lại sẽ có response time lớn hơn giá trị hiển thị trong table

• 95% Line (90th Percentile) (millisecond):nghĩa là 95% số requests sẽ có response time nhỏ hơn giá trị hiển thị trong table, 5% số requests còn lại sẽ có response time lớn hơn giá trị hiển thị trong table

• 99% Line (90th Percentile) (millisecond):nghĩa là 99% số requests sẽ có response time nhỏ hơn giá trị hiển thị trong table, 1% số requests còn lại sẽ có response time lớn hơn giá trị hiển thị trong table

• Error %: % số lượng request bị fail, bị lỗi. Ví dụ bạn run request A 100 lần và thấy có 15% errors, nghĩa là request A đã fail/error 15 lần (100*15%)

• Throughput: Thông lượng. Con số này cho bạn biết được số lượng requests được hệ thống (server) xử lý trong 1 đơn vị thời gian, có thể là giây, phút, hoặc giờ.

Công thức tính throughput là:

Throughput = (Tổng số lượng requests) / (Tổng thời gian) * (Đơn vị chuyển đổi)

Với:

• Tổng số lượng requests = Tổng số lần request này được run
• Tổng thời gian = (Thời gian bắt đầu chạy của request cuối cùng) + (Thời gian chạy/Response Time của request cuối cùng) - (Thời gian bắt đầu chạy của request đầu tiên)
• Đơn vị chuyển đổi: Mặc định nó sẽ tính theo millisecond, nên để đổi về second thì số này sẽ là 1000, hoặc 1000*60 nếu bạn muốn chuyển về phút.

Lưu ý: Đối với JMeter thì nó luôn luôn hiển thị Throughput > 1.0, vì vậy trong 1 số trường hợp số này < 1.0 thì nó sẽ convert qua 1 đơn vị khác để hiển thị. Ví dụ 0.5 requests/second, 0.5 ko thoả điều kiện, nên nó sẽ hiển thị là 30requests/min.
• KB/sec: Cũng là thông lượng, nhưng ko đo lường bằng số request, mà đo Kilobytes/second.
Công thức là

Throughput KB/sec = (Throughput * Average Bytes) / 1024

Với Aggregate Report thì mình không thấy được thông số Average Bytes. Bạn có thể xem thông số này từ Summay Report.

• Total: Trong report có 1 dòng cuối cùng đó là Total, nó sẽ tổng kết lại toàn bộ kết quả từ những request bên trên. Ngoại trừ # Samples, Throughput và KB/sec, nó sẽ được cộng lại theo đúng nghĩa "Total". Còn các thông số còn lại đều được tính Total bằng cách lấy giá trị trung bình từ tất cả những request ở trên.

2. Phân tích report

• Chúng ta sẽ 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. Và đương nhiên, 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. Vậy thì, cùng một thời gian, càng xử lý được càng nhiều càng tốt. Nên với Throughput thì nó phải càng CAO càng tốt

• Chúng ta có những trường hợp như sau:

• Response Time: THẤP và Throughput: THẤP --> Trường hợp này sẽ không bao giờ xảy ra. Vì Response Time THẤP nghĩa là thời gian đáp ứng rất nhanh, nhưng Throughput THẤP lại chỉ ra rằng số request được xử lý rất ít. Noooo, chuyện này là vô lý

• Response Time: THẤP and Throughput: CAO --> Đây là một kết quả lý tưởng. Thời gian xử lý thấp và số lượng request xử lý cùng đồng thời lại cao. Như vậy có thể thấy rằng Server đang rất tốt. Hãy xem xét khả năng mở rộng các tính năng, hoặc tăng thêm số lượng test để tìm xem giới hạn của server là bao nhiêu.

• Response Time: CAO and Throughput: THẤP --> Ngược lại với bên trên, đây là lúc mà Performance Test của bạn đã bị fail. Test chỉ ra rằng thời gian xử lý quá cao, và lượng request được xử lý lại rất thấp. Phải xem xét để improve về phía sever side.

• Response Time: CAO and Throughput: CAO --> Khá nhạy cảm, vì bạn có thể thấy Throughput cao, tức là server đang làm việc rất tốt, vậy tại sao thời gian xử lý lại cũng cao (không tốt). Có thể vấn đề lúc này đế từ phía Client, hoặc cụ thể là đến từ JMeter, có thể đoạn script của bạn viết chưa được tối ưu, khiến quá trình nó xử lý mất nhiều thời gian chẳng hạn? ... Bạn hãy kiểm tra lại để chắc chắn rằng mình có một kết quả test chính xác.