Đọc Hiểu Và Phân Tích Các Thông Số Của Report Trong JMeter

testingvn.com

Chia sẻ là một cách học hỏi

Skip to content

Ad blocker detected: Our website is made possible by displaying online advertisements to our visitors. Please consider supporting us by disabling your ad blocker on our website.

Đọc hiểu và Phân tích các thông số của report trong JMeter

Công cụ kiểm thử hiệu năng miễn phí, chỉ hỗ trợ java. Forum rules Công cụ kiểm thử hiệu năng miễn phí, chỉ hỗ trợ java. Post Reply 11 posts harano Jr. Tester Posts: 58 Joined: Fri 20 Apr, 2012 10:43 am Contact: Contact harano Send private message

Đọc hiểu và Phân tích các thông số của report trong JMeter

• Quote

Post by harano » Thu 13 Oct, 2016 5:58 pm

Link bài viết tiếng Anh: https://jmetervn.wordpress.com/2016/10/ ... in-jmeter/ Xin chào mọi người Đối với Performance Testing thì việc đánh giá, phân tích report sau khi đã chạy test, là một điều không phải đơn giản, cho dù tool đó có "cool" đến mức nào, hiển thị report chi tiết đến mức nào thì cuối cùng, người test (QC/Tester) vẫn phải là người đọc hiểu và đưa ra kết luận cho report đó. JMeter cũng không ngoại lệ, report của JMeter đầy đủ những thông tin cần thiết, nhưng làm thế nào để hiểu? Hy vọng bài viết hôm nay sẽ giúp mọi người có được cái nhìn tổng quan về các thông số của report, tự đánh giá được status của hệ thống sau khi test. Mình sẽ tập trung vào 1 trong những Report hữu ích của JMeter, đó là Aggregate Report. 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ố. Hãy tìm hiểu xem ý nghĩa của từng thông số là gì 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 nhé. Tham khảo hình bên dưới: “Include group name in the label?” is UNCHECKED by default Nếu lựa chọn “Include group name in the label?” được check, thì những request sẽ được gán thêm tiền tố = tên của Thread Group chứa request đó. Tham khảo hình bên dưới: “Include group name in the label?” is CHECKED • # 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): 10 – Loop Count: 3 Thì 1 HTTP Request của Thread Group này sẽ run 10 x 3 = 30 (lần) —> # Samples: 30 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, v.v... 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: 10 x 3 x 2 = 60 (lần). —> # Samples: 60 • 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 4 lần với các kết quả Response Time tương ứng là 101ms, 106ms, 153ms, và 128ms. Thì Response Time trung bình của Request A sẽ là 122ms (Công thức tính giá trị trung bình chắc mình không cần nhắc lại nữa nhỉ ) • 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 = 101ms • 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 = 153ms • Percentiles (millisecond): Ở đây mình sẽ giải thích sơ qua một chút về Percentiles. Mình xin phép không dịch từ này, và mọi người cũng đừng hiểu nó là phần trăm (%) nhé. Nói một cách đơn giản 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. Lấy 1 ví dụ đơn giản. Sau một bài kiểm tra ở lớp học, cô giáo nói 90th Percentile điểm số là 6. Nghĩa là 90% số điểm của lớp sẽ dưới 6 điểm, còn lại 10% sẽ cao hơn 6 điểm. Hay một ví dụ khác, sau khi làm bài đánh giá năng lực để pv vào 1 công ty, người ta thông báo cho bạn điểm số của bạn có Percentile là: 74%. Nghĩa là trong số tất cả những người đã làm bài test này, có 74% số người có điểm thấp hơn bạn, và 26% còn lại có điểm số 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

3 thông số percentile 90th, 95th và 99th là những thông số rất được hay sử dụng trong percentile, không chỉ Performance Testing mà còn trong những lĩnh vực khác nữa. Và những con số này hoàn toàn có thể cấu hình được trong JMeter thông qua file jmeter.properties, từ phiên bản 2.12. Mở file này từ folder /JMETER_HOME/bin/ và tìm đến những dòng như bên dưới:

Code: Select all

#--------------------------------------------------------------------------- # Aggregate Report and Aggregate Graph - configuration #--------------------------------------------------------------------------- # # Percentiles to display in reports # Can be float value between 0 and 100 # First percentile to display, defaults to 90% #aggregate_rpt_pct1=90 # Second percentile to display, defaults to 95% #aggregate_rpt_pct2=95 # Second percentile to display, defaults to 99% #aggregate_rpt_pct3=99 Sau đó hãy uncomment các giá trị aggregate_rpt_pct1, aggregate_rpt_pct2 hoặc aggregate_rpt_pct3 bằng cách xoá dấu # ở đầu, và sửa lại bằng giá trị mà bạn muốn. Như mình, mình đã sửa aggregate_rpt_pct1=75, sau đó save file, restart JMeter, hãy xem nó sẽ hiển thị như thế nào nhé: Note: thay đổi giá trị này, nó sẽ thay đổi label của header trong report, đồng thời cũng tính toán lại cho đúng với con số mới. • 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. Ví dụ 4: Mình sẽ run 1 test với 5 threads và 2 lần Loop Count, test này chỉ có duy nhất 1 HTTP Request và access vào google. Hãy xem kết quả bên dướidưới Trong bài test này thì mình đã sử dụng thêm 1 Listener nữa đó là View Result in Table để có thể thấy các thông số về thời gian start, response time một cách nhanh nhất. Thời gian bắt đầu chạy của request đầu tiên: 17:24:55.911 (1476095095911 in ms) Thời gian bắt đầu chạy của request cuối cùng: 17:24:56.838 (1476095096838 in ms) Thời gian chạy/Response Time của request cuối cùng: 155ms Tổng thời gian = (1476095096838 + 155 – 1476095095911) = 1082 Tổng số lượng requests = 10 Throughput = 10 / 1082 * 1000 ≈ 9.2/sec Bây giờ hãy kiểm tra với Throughput ở trong Aggregate Report: https://jmetervn.files.wordpress.com/20 ... png?w=1224 Hoàn toàn trùng khớp. Điều này chứng tỏ công thức trên là đúng 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. Cũng tương đường mà, phải không bạn Nhưng nếu bạn ghi kết quả ra file CSV, thì con số throughput luôn luôn ở dạng request/second, nên trong trường hợp này nó sẽ hiển thị là 0.5 • 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: Sau khi đọc xong phần 1 ở trên, thì ít nhất các bạn cũng đã có cái nhìn tổng quan về các thông số trong report. Ý nghĩa của từng thông số là gì. Bước tiếp theo đây, hãy nhìn vào những con số đó và đưa ra một đánh giá phù hợp. 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. 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 Dựa vào đó, chúng ta có những trường hợp như sau:

• 1. Response Time: THẤP and 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ý 2. Response Time: THẤP and Throughput: CAO --> Đây là một kết quả lý tưởng phải không nào các bạn? Thời gian xử lý thấp và số lượng request xử lý cùng đồng thời lại cao. Còn chần chờ gì nữa mà không tự tin báo cáo 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. 3. 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. 4. 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? 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 nhé.

Top ocsen Fresher Tester Posts: 14 Joined: Mon 21 Jul, 2014 9:14 pm Contact: Contact ocsen Send private message

Re: Đọc hiểu và Phân tích các thông số của report trong JMet

• Quote

Post by ocsen » Wed 03 May, 2017 10:33 am

Hi Thớt, Mình thấy Throughput tính như bạn chưa thực sự chuẩn vì Tổng thời gian chạy còn bị ảnh hưởng bởi RAM UP nữa. Nếu bạn đặt RAM UP càng lớn thì thời gian chạy càng lớn. Lúc đấy xảy ra trường hợp mặc dù server rảnh rỗi thật nhưng throughput lại rất thấp. Trong bài bạn viết mình thấy không có chỗ nào nhắc tới RAM UP nhỉ. Top tvn Admin Posts: 4900 Joined: Tue 10 Aug, 2010 10:11 am Location: HCM Contact: Contact tvn Send private message Website Skype

Re: Đọc hiểu và Phân tích các thông số của report trong JMet

• Quote

Post by tvn » Wed 03 May, 2017 5:10 pm

ocsen wrote:Hi Thớt, Mình thấy Throughput tính như bạn chưa thực sự chuẩn vì Tổng thời gian chạy còn bị ảnh hưởng bởi RAM UP nữa. Nếu bạn đặt RAM UP càng lớn thì thời gian chạy càng lớn. Lúc đấy xảy ra trường hợp mặc dù server rảnh rỗi thật nhưng throughput lại rất thấp. Trong bài bạn viết mình thấy không có chỗ nào nhắc tới RAM UP nhỉ.

Công thức tính thông lượng wrote:Throughput = (Tổng số lượng requests) / (Tổng thời gian) * (Đơn vị chuyển đổi)

Trong đó: 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.

Giả sử mình có 1000 requests Trường hợp 1: RAM-UP là 1000 (giây) => thì trung bình 1 request trên 1 giây. Trường hợp 2: RAM-UP là 2000 (giây) => thì trung bình 0.5 request trên 1 giây (hay 2 giây sẽ có 1 request). Trường hợp 3: RAM-UP là 500 (giây) => thì trung bình 2 request trên 1 giây. Như vậy, tổng thời gian chạy của Trường hợp 1, 2 và 3 sẽ khác nhau. Dẫn đến thông lượng sẽ khác nhau. Và, có thể vì lý do gì đó, và có thể nói là để tính chính xác hơn, thì lấy thời gian chạy request cuối cùng trừ cho thời gian bắt đầu chạy request đầu tiên (mình không đề cập đến thời gian thực hiện request cuối cùng) thì sẽ là tổng thời gian sẽ chạy hết 1000 requests ở trên. Và thường thì nó sẽ là LỚN hơn thời gian RAM UP. Nên nếu như mình gộp RAM-UP vào công thức này thì nó sẽ thế nào? Có thể tổng thời gian chạy hết 1000 requests = RAM-UP + x (giây). Mà x này lấy ở đâu ra? Dựa vào số nào cho chính xác? Theo mình hiểu, RAM-UP là thời gian cần phải gửi hết số lượng requests (giả lập) cần thiết. JMeter sẽ dựa vào RAM-UP period để tính ra thời gian cho mỗi lần gửi request lên server. Theo ocsen thì tại sao mình cần xem xét RAM-UP trong trường hợp này? và Công thức tính thông lượng sẽ trông như thế nào, nếu có RAM-UP? (đây chỉ là thảo luận để mọi người hiểu thêm, hiểu rõ hơn về cách tính thông lượng và xem kết quả report. Nên cứ mạnh dạn mà thảo luận nha, đừng sợ đúng hay sai.) Đào Tạo Tester | ISTQB Online | Istqb Exam Online Top harano Jr. Tester Posts: 58 Joined: Fri 20 Apr, 2012 10:43 am Contact: Contact harano Send private message

Re: Đọc hiểu và Phân tích các thông số của report trong JMet

• Quote

Post by harano » Thu 04 May, 2017 9:21 pm

ocsen wrote:Hi Thớt, Mình thấy Throughput tính như bạn chưa thực sự chuẩn vì Tổng thời gian chạy còn bị ảnh hưởng bởi RAM UP nữa. Nếu bạn đặt RAM UP càng lớn thì thời gian chạy càng lớn. Lúc đấy xảy ra trường hợp mặc dù server rảnh rỗi thật nhưng throughput lại rất thấp. Trong bài bạn viết mình thấy không có chỗ nào nhắc tới RAM UP nhỉ.

Xin chào bạn oscen, Đầu tiên, mình muốn đính chính lại câu nói của bạn một chút, công thức này là công thức được cung cấp trên trang chủ JMeter, bạn vui lòng tham khảo ở link này: http://jmeter.apache.org/usermanual/glossary.html phần throughout ở cuối trang, mình chỉ đang diễn giải ra rõ ràng hơn. Tiếp theo, điều bạn thắc mắc ở đây là RAMP-UP, bạn đang nghĩ là RAMP-UP càng lớn thì thời gian chạy càng lớn, và server rảnh rỗi nhưng throughput lại thấp. - Server không hề rảnh rỗi trong quá trình test, khi run performance test, thường sẽ run với Loop Count = Forever, nên các requests sẽ được đẩy vào server liên tục liên tục cho đến khi kết thúc mới thôi. - Ở ví dụ trong bài viết của mình, mình chỉ run với 10 threads (users), và Loop Count = 1, nên lúc nào nó cũng chỉ có 10 requests. Có thể vì vậy nên bạn đang nhầm là "số lượng requests không thay đổi", và ramp-up lớn, nhỏ sẽ ảnh hưởng đến throughput. Nhưng mình muốn nhấn mạnh, đó chỉ là ví dụ mà thôi, nên mình đưa ra trường hợp đơn giản nhất, để chứng minh cái công thức tính throughput. - Thực tế, khi đẩy request liên tục = loop forver, thì requests sẽ được sinh ra liên tục, nên ramp-up ngắn thì số requests ít, và ramp-up dài thì số request cũng tăng theo...và công thức trên luôn đúng cho mọi trường hợp. - Throughput trong ví dụ của mình, được tính ra là 9.2/sec, nhưng nó không mang nhiều ý nghĩa, cũng không nói lên được throughput của server đó là 9.2 requests/second. Throughput mang lại giá trị để đánh giá kết quả test, nó phải là throuhgput ngay tại điểm quá tải của server, server không thể nào đạt được throughput cao hơn nữa, thì đó mới đúng là con số cần tìm. - Lấy một ví dụ đơn giản:

• Một tiệm bánh (tương ứng với server) và số bánh bán được xem như là số request được xử lý

• + Ngày 1 bán được 40 bánh trong 8 giờ. Vậy công suất của tiệm bánh đó là phục vụ được 5 bánh / giờ

• + Ngày 2 bán được 80 bánh trong 8 giờ. Vậy công suất của tiệm bánh đó là phục vụ được 10 bánh / giờ

• + Ngày 3 bán được 72 bánh trong 8 giờ. Vậy công suất của tiệm bánh đó là phục vụ được 9 bánh / giờ

• + Ngày 4 bán được 100 bánh trong 8 giờ. Vậy công suất của tiệm bánh đó là phục vụ được 12,5 bánh / giờ

• + Ngày 5 có 200 người mua bánh nhưng trong 8h vẫn chỉ bán được 100 bánh. Vậy công suất của tiệm bánh đó là phục vụ được 12,5 bánh / giờ

• + Ngày 6 có 150 người mua bánh nhưng trong 8h vẫn chỉ bán được 100 bánh. Vậy công suất của tiệm bánh đó là phục vụ được 12,5 bánh / giờ

Vậy ở đây, đâu mới là công suất thật của tiệm bánh đó? Nếu chỉ bán xong ngày đầu, kết luận công suất là 5 bánh/giờ, liệu có đúng? Hay qua 3 ngày đầu tiên, kết luận công suất là 10 bánh/giờ, liệu có đúng? Mà công suất thật sự của nó là 12,5 bánh/giờ. Khi mà có số lượng bánh được order, vượt quá khả năng làm bánh của cửa tiệm, lúc đó, con số 12,5 mới có giá trị, dễ thấy rằng, mặc dù người mua mua tới 150 bánh (giả sử mỗi người mua một bánh), thậm chí 200 bánh, tiệm bánh muốn bán không? Muốn chứ, nhưng khả năng chỉ tới đó thôi, 12,5 bánh/giờ, quá 100 bánh/ngày là không thể phục vụ kịp. Nhưng còn những con số 5 bánh/giờ, 10 bánh/giờ của ngày 1, ngày 2...nó là gì, có phải là công suất không? Đúng, nó chính là công suất, nhưng nó là công suất của ngày 1, và công suất của ngày 2. Chứ không thể đem nó ra để đánh giá công suất của tiệm bánh. Và với ngày 5, ngày 6, cả 200 người khách đó, đến mua vào 1 tiếng buổi sáng, hay họ chia đều ra đến rải rác suốt 8 tiếng, thì liệu kết quả có khả quan hơn khong, xin thưa là không? Nếu đến cùng lúc trong vòng 1 tiếng, thì chắc chắn những người đến sau phải đợi, thậm chí đợi vài tiếng để có bánh, nhưng cửa tiệm sẽ cảm thấy bị quá tải ngay trong 1 tiếng đó rồi. Còn nếu đến rải rác suốt 8 tiếng, thì cũng không khá hơn, dù được thảnh thơi, mỗi thời điểm chỉ tiếp một vài khách, nhưng không vì thế mà số bánh làm được và bán được tăng lên, vì tối đa chỉ bán được 100 bánh thôi. Cái thời gian 1 tiếng, hay rải rác 8 tiếng đó, chính là ramp-up. Vậy bạn đã thấy nó không thể ảnh hưởng đến server rồi chứ Quay lại bài toán throughput, cái ví dụ của mình cũng giống như một ngày của tiệm bánh này, nó chỉ là throuhgput với cái số lượng threads mà mình đã run, có thể xem nó như ngày một, và khi bạn thay đổi ramp-up, có thể throughput nó sẽ khác, nhưng vẫn chỉ là throughput tương đương với cái test đó của bạn. Để tìm được throuhgput thật sự chính xác, thì cần phải theo dõi giống như tiệm bánh, bằng cách - Run nhiều test để so sánh - Run test với nhiều mốc threads (users) khác nhau để so sánh - Và đặc biệt, không để server rảnh rỗi mà luôn dùng loop forever để đẩy requests liên tục vào server Kết: Ramp-up không bao giờ làm ảnh hưởng đến throughput cuối cùng của phía server, ramp-up lớn hay bé, nó chỉ có khả năng làm server overload nhanh hay chậm (nếu có thể) mà thôi. Nếu có dịp, mình sẽ làm một cái test giống hệt nhau, chỉ khác nhau về ramp-up, để chứng minh dù ramp-up có khác nhau thế nào đi nữa, throughput (capacity) của hệ thống cũng không bao giờ thay đổi. Last edited by harano on Tue 09 May, 2017 11:32 am, edited 1 time in total. Top ocsen Fresher Tester Posts: 14 Joined: Mon 21 Jul, 2014 9:14 pm Contact: Contact ocsen Send private message

Re: Đọc hiểu và Phân tích các thông số của report trong JMet

• Quote

Post by ocsen » Fri 05 May, 2017 11:47 am

Mình cảm ơn 2 bạn TVN và HARANO nha Đúng là lúc thắc mắc mình chỉ đang nghĩ tới ví dụ loop count =1 thôi. Hi suy nghĩ hơi ngắn hehe. Top tvn Admin Posts: 4900 Joined: Tue 10 Aug, 2010 10:11 am Location: HCM Contact: Contact tvn Send private message Website Skype

Re: Đọc hiểu và Phân tích các thông số của report trong JMet

• Quote

Post by tvn » Fri 05 May, 2017 5:27 pm

You're welcome. Vậy thì với loop count > 1 thì "suy nghĩ sẽ dài hơn" ^^ JMeter sẽ chạy lâu hơn. Keke. Đào Tạo Tester | ISTQB Online | Istqb Exam Online Top ocsen Fresher Tester Posts: 14 Joined: Mon 21 Jul, 2014 9:14 pm Contact: Contact ocsen Send private message

Re: Đọc hiểu và Phân tích các thông số của report trong JMet

• Quote

Post by ocsen » Sat 06 May, 2017 4:25 pm

Tiện đây hai Thánh cho mình hỏi ngu tý. Khi test load thì mình sẽ để load trong bao lâu hay bao nhiêu lần? Và khi tìm được 1 con số gọi là ngưỡng thì khi có phải khi load ngưỡng đó trong bao lâu cũng pass phải không ạ? Top harano Jr. Tester Posts: 58 Joined: Fri 20 Apr, 2012 10:43 am Contact: Contact harano Send private message

Re: Đọc hiểu và Phân tích các thông số của report trong JMet

• Quote

Post by harano » Tue 09 May, 2017 11:41 am

ocsen wrote: Tiện đây hai Thánh cho mình hỏi ngu tý. Khi test load thì mình sẽ để load trong bao lâu hay bao nhiêu lần?

Load Test là gì? Là test để tìm ra ngưỡng của hệ thống, và đã gọi là "test", thì bắt buộc mình phải test nhiều lần, với những con số khác nhau, mới rút ra được kết luận cuối cùng. Ví dụ start test với 100 users, vẫn thấy work bình thường, test với 200 users, vẫn bình thường, tăng lên 400 users, có thể vẫn bình thường, tăng lên 1000, thấy có dấu hiệu overload, error, lúc đó lại giảm xuống 700 chẳng hạn, nếu bình thường thì lại tiếp tục tăng lên, 800, nếu ngay tại mức 800 này, chỉ cần tăng thêm nữa là sẽ overload, có lỗi ngay, thì có thể kết luận 800 đó là ngưỡng của hệ thống. Vậy làm sao để biết được con số 800? Có phải phải bắt đầu test từ 100, rồi nâng lên hạ xuống sau mỗi lần test không? Kể cả con số 100, bạn có thể bắt đầu bằng 200, 300, tuỳ...Không có bất cứ ràng buộc hay yếu tố nào ảnh hưởng tới cái đó cả. Cứ tes thôi Nên không có bất cứ một con số cụ thể nào cho việc "load trong bao lâu" hay "bao nhiêu lần".

ocsen wrote:Và khi tìm được 1 con số gọi là ngưỡng thì khi có phải khi load ngưỡng đó trong bao lâu cũng pass phải không ạ?

Đúng vậy, khi bạn run số threads là ngưỡng của server, thì bạn run bao lâu nó cũng pass, nhưng ko phải quá lâu (10', 20' 30' thì ok), vì nếu bạn run trong 1 tiếng, 4 tiếng hay 8 tiếng, 1 ngày, 3 ngày ... một thời gian dài như vậy, nghĩa là bạn đã làm Soak Test rồi, nó lại là một dạng test khác. Top ocsen Fresher Tester Posts: 14 Joined: Mon 21 Jul, 2014 9:14 pm Contact: Contact ocsen Send private message

Re: Đọc hiểu và Phân tích các thông số của report trong JMet

• Quote

Post by ocsen » Thu 11 May, 2017 10:30 am

Thanks bạn nhé. Những gì bạn chia sẻ giúp mình giải quyết được khá nhiều khúc mắc. Ủng hộ bạn hihi. Top ocsen Fresher Tester Posts: 14 Joined: Mon 21 Jul, 2014 9:14 pm Contact: Contact ocsen Send private message

Re: Đọc hiểu và Phân tích các thông số của report trong JMet

• Quote

Post by ocsen » Mon 03 Jul, 2017 5:36 pm

Help me !!!!!!!!!!!!!! Theo luồng Jmeter nên mình muốn nhờ mọi người ai đã gặp trường hợp này rồi cho mình cách giải quyết với ((((((((((((((((((( Mình chạy jmeter thì thấy thời gian phản hồi của request lại lớn hơn rất nhiều so với tổng thời gian chạy của Jmeter (hình dưới). Mình thấy rất vô lý nhưng không rõ tại sao lại vậy. Khi gửi script sang máy khác chạy thì lại không gặp trường hợp này. [img]E:\hangnt51.png[/img] Top Post Reply Display: All posts1 day7 days2 weeks1 month3 months6 months1 year Sort by: AuthorPost timeSubject Direction: AscendingDescending 11 posts