Đang tải... (xem toàn văn)
hướng dẫn test performance website, mobile từ A tới Z bằng jmeter. Cách tạo testplan bằng recording website, mobile. Quy trình thực hiện các load test, phân tích đánh giá kết quả. Có ví dụ trực quan dễ hiểu nhất
Giới thiệu chung kiểm thử hiệu (performance testing) 1.1.Kiểm thử hiệu 1.1.1 Tại cần kiểm thử hiệu Liệu ứng dụng có đáp ứng đủ cho người dùng cách nhanh chóng? Liệu việc xử lý ứng dụng có đáp ứng yêu cầu người dùng, khả chịu tải nữa? Liệu ứng dụng có xử lý số lượng giao dịch theo yêu cầu kinh doanh? Liệu ứng dụng có ổn định mong muốn người dùng khả chịu tải khơng? Chúng ta có người dùng có kinh nghiệm việc đưa vào sử dụng thực tế? Kiểm thử hiệu làm rõ ràng rủi ro việc triển khai phần mềm, ngăn ngừa hệ thống downtime sẵn sàng trước vấn đề gặp phải 1.1.2 Mục đích - Kiểm thử hiệu nhằm giảm bớt rủi ro việc ứng dựng, nâng cấp phát triển - phần mềm Nó dùng để xác nhận xác minh thuộc tính chất lượng khác hệ thống như: khả mở rộng, độ tin cậy mức độ sử dụng tài nguyên Xác định công suất vận hành tối đa ứng dụng điểm "thắt cổ chai" (bottleneck) xác định phần tử nguyên nhân gây điều Thực kiểm thử hiệu vấn đề: o Hệ thống hệ thống thực khối lượng công việc cụ thể nhanh o Khả đáp ứng hệ thống với hạn mức tải cụ thể Đánh giá thông lượng hệ thống (Throughput) Thời gian phản hồi (Response time) Ứng xử hệ thống trường hợp ngưỡng tải, cao tải, tải o Khả mở rộng hệ thống (Thiết lập baseline), o Hỗ trợ tối ưu hệ thống (Chỉ điểm nghẽn hệ thống) 1.1.3 Khái niệm Kiểm thử hiệu là: - Một kỹ thuật kiểm thử phi chức để xác định đánh giá đặc tính sản phẩm như: Tốc độ (respond Time),khả mở rộng (scalability),tính ổn định (stability), độ tin cậy(reliability) - Cách kiểm thử đặt yêu cầu hệ thống/thiết bị đo lường vận hành/thao tác/trả lời hệ thống/thiết bị, thực thi điều kiện tải cao bình thường 1.1.4 Các yếu tố kiểm thử Thời gian đáp ứng (response time) Tỷ lệ lỗi (pass/fail) Lưu lượng liệu (throughput) Số yêu cầu giây (TPS – transaction per second) Số người dùng đồng thời (concurrent user / virtual user) Tài nguyên máy (RAM, CPU…) 1.1.5 - Các thuật ngữ kiểm thử hiệu CCU – Concurrent user: số lượng user đẩy tải Resoure Monitering: (giám sát tài nguyên hệ thống) TPS (Transaction Per Second): Số Transaction xử lý thành công giây - Throught put: số Transaction xử lý thành công đơn vị thời gian Respond Time: Thời gian phản hồi hệ thống, tính từ lúc request gửi tới nhận respond trả từ hệ thống Ngưỡng: Số user tối đa mà chức cho phép truy cập đồng thời Breaking point( Điểm chết hệ thống): Số user truy cập đồng thời vào hệ thống làm hệ thống bị chết dán đoạn 1.1.6 Các loại kiểm thử hiệu - - - Load testing o Là trình đẩy request đo lường phản ứng hệ thống thiết bị o Load testing thực để xác định hành vi hệ thống điều kiện tải bình thường điều kiện tải cao tải o Load testing giúp xác định khả hoạt động tối đa hệ thống tắc nghẽn (bottlenecks) hay yếu tố gây suy thoái (degradation) o Các tham số: Respond Time, TPS, throught,… Stress testing: o Là cách để kiểm tra (độ) tính tin cậy o Là việc đẩy hệ thống lên mức giới hạn (điều kiện tải cực cao) để xác định điểm yếu (weak point – lỗi đồng bộ, thiếu nhớ ), thử làm gián đoạn trang web cách tăng lượng tải cao kiểm tra xem hệ thống phản ứng phục hồi o Ví dụ: Hệ thống có điểm chết (breaking point)là 1100 user Spike test thực đẩy vào hệ thống khoảng 2000 tới 3000 user vòng 1-2 s xem hệ thống có bị lỗi tràn nhớ hay đồng hay không (spike test phần stress test dùng để xác định hiệu hệ thống điều kiện tải tăng liên tục vượt khỏi dự kiến thời gian ngắn) Volume testing: o Là kiểm thử phi chức o Kiểm thử với lượng liệu lớn Dữ liệu kích thước sở liệu kích thước tập tin giao tiếp (.dat, xml) đối tượng volume testing o VD: Mở rộng kích thước CSDL kiểm tra hiệu suất ứng dụng o Capacity test: xác định chiến lược để định cỡ (sizing) hệ thống nhằm đáp ứng - yêu cầu hiệu hệ thống tương lai Endurance testing: o phần Load test nhằm xác định thông số hiệu hệ thống điều kiện tải dự kiến thời gian dài o Ví dụ: sau thực kiểm thử hiệu xác định ngưỡng hệ thống 1000 user Con số khách hàng mong muốn chức toán đáp ứng 500 người dùng đồng thời thời điểm bình thường Bài test độ bền thực đẩy vào hệ thống khoảng 500 user cho chạy chạy lại liên tục vòng 2h(hoặc lâu hơn) để xác định xem hệ thống chạy có bền, có đảm bảo tiêu chí Respond Time hay % chiếm dụng RAM, CPU yêu cầu không 1.2 Các yếu tố ảnh hưởng đến kiểm thử tải - - Việc lập kế hoạch: Kế hoạch vạch rõ ràng cho ta kết khả quan, ngược lại phức tạp cho ta kết có xu hướng rối rắm Mục tiêu đặt ra: ta có câu trả lời rõ ràng Kỹ nhân viên Môi trường thử nghiệm kiểm thử tải Cơ sở liệu: Trong môi trường kiểm thử, sở liệu phải nạp sẵn liệu hành liệu giả mà có kích thước nội dung liệu hành Cơng cụ kiểm thử tải: Phải có tính quan trọng như: tham số hóa liệu, nắm bắt liệu động, theo dõi sở hạ tầng hỗ trợ nhiều giao thức cho ứng dụng 1.3 Quy trình thực kiểm thử hiệu 1.3.1 Các hướng kiểm thử - Thực kiểm thử tải cho hệ thống dựa giới hạn hệ thống đưa trước Thực kiểm thử tải để xác định giới hạn cho hệ thống để đưa giới hạn cho hệ thống, để đưa giới hạn cho việc triển khai trì phát triển hệ thống 1.3.2 Quy trình kiểm thử hiệu 1.3.2.1 Lập kế hoạch test Kế hoạch kiểm thử cần nêu rõ mục tiêu kiểm thử, yêu cầu kiểm thử, thiết kế kiểm thử quản trị dự án Các bước thực mô tả cách rõ rang , mục đích thu sau test phải mơ tả chi tiết Xác định yêu cầu hiệu năng, cấu hình ranh giới xác định bắt đầu kiểm thử 1.3.2.2 Tạo lập Scripts Scripts thao tác thực tế người dùng lưu lại nhằm phục vụ cho việc kiểm thử hiệu năng.Với công cụ hỗ trợ cho việc kiểm thử hiệu năng, lưu lại bước thực kịch dạng mã lệnh.Mã lệnh chỉnh sửa cách phù hợp để phục vụ nhu cầu tester tình đề 1.3.2.3 Thiết lập kịch test Kịch trình tự thao tác, script thực khoảng thời gian với số người dùng xác định để đạt mục đích test khác 1.3.2.4 Thực thi kịch test Với kịch tạo lập, tester thực chạy chương trình nhiều máy tính khác thời điểm để kiểm thử Cùng với tester thực việc quản lý giám sát việc thực thi tình suốt trình chạy 1.3.2.5 Phân tích kết test Phân tích kết sau thực thi đưa kết luận hiệu 1.3.3 Quy trình thực load test 1.3.2.6 Xác định tiêu chí hiệu - Xác định tiêu chí hiệu có giá trị xác định sớm vòng đời phát triển ứng dụng.Các tiêu chí thường mô tả dạng thông số cụ thể lưu trữ lại để tất thành viên tham gia kiểm thử xem xét thảo luận chúng Các tiêu chí xác định thông qua tài liệu đặc tả website - Những tiêu chí hiệu thường đưa ra: o Thời gian đáp ứng ( thời gian phản hồi) web site : thời gian mà website phản hồi lại yêu cầu từ người dùng Ví dụ danh mục sản phaảm phải hiển thị vòng chưa đầy giây người dùng thực truy cập vào trang chủ website thương mại o Lượng truy cập : Ví du : hệ thống phải hỗ trợ 100 giao dịch giây o Tài nguyên sử dụng : Vi xử lý, nhớ , vào/ra đĩa cứng, vào/ra mạng o Tải người dùng tối đa: Xác định có người sử dụng chạy cấu hình phần cứng cụ thể o Các số liệu nghiệp vụ liên quan : Ví dụ số lượng đơn đặt hàng số lượng gọi xử lý thời điểm xác định 1.3.2.7 Xác định hành động Xác định tất kịch cho Website - Ví dụ : website thương mại điện tử thường phải sử dụng kịch dành cho người dùng : duyệt catalog, tìm kiếm sản phẩm, đặt hàng Xác định hoạt động liên quan đến kịch - Ví dụ : Một nút đặt hàng kịch bao gồm hoạt động sau: o Đăng nhập vào trang web o Duyệt danh mục sản phẩm o Tìm kiếm sản phầm o Thêm mục vào giỏ mua hàng o Xác nhận thông tin thẻ tín dụng đặt hàng o Xác định kịch thường sử dụng hay thường sử dụng tài nguyên nhiều (đây kịch sử dụng để thực Load Test) 1.3.2.8 Xác định mẫu Workload - Khi xác định mẫu workload, cần xem xét đặc điểm sau để xác định đặc tính cho kịch cản sử dụng: o Một kịch người dùng : bao gồm hoạt động thực bở người sử dụng để hoàn thành nhiệm vụ Điều coi phiên người dung o Một người sử dụng thông thường thực hành động ngắt quãng trang phiên Điều coi thời gian nghỉ o Một phiên giao dịch tính thời gian trung bình đánh giá với nhiều người sử dụng Điều quan trọng thực tết diễn xác định mức tải người dùng thực đồng thời, chồng chéo 1.3.2.9 Xác định mức tải mục tiêu - Xác định mức tải mục tiêu áp dụng chó việc phân phối khối lượng cơng việc xác định bước trước Mục đich việc xác định mức tải mục tiêu để đàm bảo kiểm thử sử dụng để dự đoán so sánh với điều kiện tải trọng hiệu suất - Những yếu tố đầu vào thường sử dụng để xác định tải mục tiêu: o Khối lượng công việc ( dự kiến ) Vì liên quan đến mục tiêu hiệu o Kịch o Phân phối công việc o Đặc điểm phiên giao dịch (danh sách bước, thời gian, tỷ lệ người dùng mới…) 1.3.2.10 Xác định thông số - Trong trình kiểm thử hiệu năng, số liệu thu thập không giới hạn Tuy nhiên, việc thu thập nhiều số liệu gây khó khăn phân tích tác động tiêu cực đến thực tế ứng dụng Vì vậy, điều quan trọng xác định số liệu có liên quan đến mục tiêu hiệu năng, điều cần thiết giúp xác định điểm tắc nghẽn.Chỉ số liệu phân tisch cách xác cung cấp thơng tin có giá trị lựa chọn.Một vài gợi ý giúp xác đinh số liệu cung cấp thơng tin có giá trị : o Xác định câu hỏi liên quan đến hiệu ứng dụng mà dễ dàng kiểm tra : ví dụ thời gian đáp ứng tốn đặt hàng , làm để nhiều đơn đặt hàng đặt phút Với câu trả lời cho câu hỏi trên, xác đinh mục tiêu hiệu để so sánh : ví dụ thời gian check out nên 30 giây tối đa 10 đơn đặt hàng nên đặt phút Các câu trả lời dựa nghiên cứu thị trường, liệu lịch sử, o Xác đinh số liệu: sử dụng danh sách câu hỏi câu trả lời liên quan đến hiệu năng, xác định số liệu cung cấp thông tin liên quan đến câu hỏi câu trả lời o Xác định số liệu hỗ trợ: Giúp xác đinh mức tải chấp nhận cho ứng dụng Các giá trị giúp phân tích hiệu ứng dụng mức tải khác o Đánh giá lại số liệu thu thật cách thường xuyên : mục tiêu, ưu tiên , rủi ro vấn đề bị rang buộc để thay đổi trình dự án Với thay đổi, số liệu khác cung cấp giá trị nhiều so với giá trị mà trước xác định 1.3.2.11 Thiết kế kiểm thử chi tiết - Việc thiết kế kịch kiểm thử cụ thể cần sử dụng kịch đậto ra, số liệu lựa chọn mẫu workload Với thử nghiệm khác có mục đích khác nhau, thu thập liệu khác nhau, kịch khác có mức tải mục tiêu khác - Các điểm cần ý thiết kế kiểm thử bao gồm: o Khơng thay đổi thiết kế kiểm thử thiết kế khó thực cơng cụ o Nếu thực việc cài đặt thử nghiệm thiết kế, đảm bảo chi tiết liên quan đến việc cài đặt thử nghiệm ghi lại o Đảm bảo mơ hình có chứa tất liệu cần thiết để tạo thử nghiệm thực tế.Người dùng lần đầu thường dành nhiều thời gian hoạt động trang người dùng có kinh nghiệm (đã sử dụng trang lần trước) o Các liệu kiểm thử tốt liệu thu từ sở liệu log file o Không nên bị vào yếu tố phức tạp bỏ qua hành động đơn giản 1.3.2.12 Chạy thử nghiệm - Đây bước sử dụng công cụ có sẵn để thực việc thực thi thu bước Ở bước , tester thực việc mô kịch xây dựng với mẫu workload xây dựng tương ứng công cụ kiểm thử tự động - Việc mô tải sai lệch làm cho tất thiết kế bước trở nên vơ ích Để hiểu liệu thu thập từ việc thực thi thử nghiệm, mô tải phải phản ánh thiết kế thử nghiệm mơ khơng phản ánh thiết kế kết bị hiểu sai Những bước chuẩn bị mô tải sau: o Bước 1: Cấu hình mơi trường thử nghiệm theo cách mà phản ánh mơi trường sử dụng thực tế nhiều tốt, có khác biệt, nên ý khác biệt o Bước 2: Đảm bảo đo hiệu cho số liệu xác định không can thiệp vào tính xác mơ tải o Bước 3: Sử dụng công cụ tạo tải trọng thích hợp để tạo tải với đặc điểm mô tả thiết kế thử nghiệm o Bước 4: Một số điểm lưu ý trình thực thử nghiệm bao gồm: + Bắt đầu với số lượng nhỏ người dùng phân phối theo hồ sơ người dùng, sau tăng dần tải trọng Điều để có thời gian cho hệ thống ổn định tăng tải đánh giá tính xác mơ + Xem xét việc tiếp tục tăng tải ghi lại hành vi đạt đến ngưỡng cho nguồn lực xác định mục tiêu hiệu suất đặt ra, tải vượt tải trọng mục tiêu quy định thiết kế thử nghiệm Thông tin hành vi hệ thống qua ngưỡng xác định quan trọng giá trị số liệu tải mục tiêu thử nghiệm 1.3.2.13 Phân tích kết - Phân tích kết thu để tìm điểm tắc nghẽn hiệu lần chạy thử nghiệm sau toàn thành tất thử nghiệm Dưới bước để phân tích liệu: o Phân tích liệu thu thập so sánh kết với mức độ chấp nhận số liệu để xác định xem hiệu suất Website thử nghiệm kết o Phân tích số liệu đo để chuẩn đốn tắc nghẽn Dựa phân tích, nắm bắt số liệu bổ sung vòng kiểm tra GIỚI THIỆU VỀ JMETER 2.1 Giới thiệu Jmeter 2.2 Test Plan - Mô tả chuỗi bước Jmeter thực chạy - - Một test plan đầy đủ bao gồm • Thread Groups: yêu cầu gửi tới server • Logic Controllers: Nếu request định nghĩa test plan bạn thực thi phục thuộc vào vài logic Chúng thích hợp với cấu trúc if- then – else Loop java hay ngơn ngữ khác • Sample: Những phần tử gửi yêu cầu tới server Có sample cho kiểu request: HTTP/HTTPS, FTP, SOAP, JDBC,”Java”, LDAP, MôngDB, TCP,… • Listener: Tập kết việc run test, cung cấp cho người dùng công cụ hiển thị cách trực quan, dễ hiểu • Time • Assertion: Cho phép bạn kiểm tra response bạn lấy liệu mong đợi, phạm vi thời gian định sẵn Các test plan cấu hình giao diện • Có thể lưu thành file jmx • Được Run, Stop • Jmeter report warnings error file jmetter.log, thông tin test INFO 2016-12-13 17:36:39.862 [kg.apc.p] (): *** Logging available filesystems *** INFO 2016-12-13 17:36:39.863 [kg.apc.p] (): Filesystem: fs=/sys type=sysfs INFO 2016-12-13 17:36:39.863[kg.apc.p] (): Filesystem: fs=/proc/sys/fs/binfmt_misc type=binfmt_misc INFO 2016-12-13 17:36:39.863 [kg.apc.p] (): Filesystem: fs=/boot type=ext4 INFO 201612-13 17:36:39.863 [kg.apc.p] (): Filesystem: fs=/dev/shm type=tmpfs INFO 2016-12-13 17:36:39.863 [kg.apc.p] (): Filesystem: fs=/dev/pts type=devpts INFO 2016-12-13 17:36:39.864 [kg.apc.p] (): Filesystem: fs=/u01 type=ext4 INFO 2016-12-13 17:36:39.864 [kg.apc.p] (): Filesystem: fs=/ type=ext4 INFO 2016-12-13 17:36:39.864 [kg.apc.p] (): Filesystem: fs=/proc type=proc INFO 2016-12-13 17:36:39.864 [kg.apc.p] (): *** Logging available network interfaces *** INFO 2016-12-13 17:36:39.865 [kg.apc.p] (): Network interface: iface=lo addr=127.0.0.1 type=Local Loopback INFO 2016-12-13 17:36:39.865 [kg.apc.p] (): Network interface: iface=eth1 addr=10.58.71.184 type=Ethernet INFO 2016-12-13 17:36:39.865 [kg.apc.p] (): *** Done logging sysinfo *** INFO 2016-12-13 17:36:39.865 [kg.apc.p] (): Binding UDP to 4444 INFO 2016-12-13 17:36:40.868 [kg.apc.p] (): Binding TCP to 4444 INFO 2016-12-13 17:36:40.873 [kg.apc.p] (): JP@GC Agent v2.2.0 started Cách xem thông số server 3.14.1.4 Trong Jmeter, add PerfMon Metrics Collector Listener 84 3.14.1.5 Thêm IP server chịu tải + port mà PerfMon Server Agen lắng nghe (port mặc định 4444) chọn Metric to collect Chạy test plan xem thông số server qua Chart lưu kết vào file csv: 3.14.1.6 b Việc xem số liệu thông số Jmeter để phục vụ cho việc phát triển debug kịch test Còn trường hợp test tải, đề xuất test chế độ nonGUI mode đồng thời đẩy liệu thông số server file Cách đọc kết file csv - Kết lưu file csv ảnh lưu vào thư mục …./ apache-jmeter3.0\bin Jmeter: 10 - Nội dung file csv sau: Giải thích thơng số: - Timestamp: thời gian Jmeter lấy thông tin server, thời gian không phụ thuộc vào thời gian server, lấy theo ngày/giờ/phút/giây máy client cài Jmeter - Elapsed: giá trị thông số server Ví dụ: RAM = 5431 => % sử dụng RAM server = 5431/1000= 5.431 % - Label: danh sách server tải tương ứng với thông số RAM, CPU, DISK, … Chú ý: - Để lấy thời gian (timestamp) định dạng ngày/tháng/năm giờ:phút:giây nội dung file trên, ta phải cấu hình thêm lệnh “jmeter.save.saveservice.timestamp_format=yyyy/MM/dd HH:mm:ss” file user.properties - Để lấy RAM, CPU request cần Synchronizing Timer => thời gian trả thông số RAM/CPU = thời gian đồng + thời gian phản hồi (min) -> thời gian hoàn thành test plan GUI mode - Nếu bạn chạy Jmeter chế độ GUI, cần add PerfMon Metrics Collector Listener, định nghĩa servers thông số cần monitor, đảm bảo agent chạy c server chịu tải khơng bị khóa firewall, sau chạy test plan Các giá trị hiển thị biểu đồ thời gian thực Non GUI Mode - Nếu bạn chạy Jmeter chế độ non-GUI muốn lưu liệu sau monitor file, cần cấu hình file kết test plan listeners GUI, hệ thống tự lưu lại Sau chạy test plan tải file lưu vào GUI xem giá trị 3.15 Request đính kèm thêm file Khi record request mà có đính kèm thêm file giao dịch thường bị lỗi, bạn kiểm tra lại giao dịch thấy mục Send File with the Request hiển thị tên file, không hiển thị lên đường dẫn đầy đủ đến file Do để chạy bạn cần điền đầy đủ đường dẫn đến file copy file vào thư mục bin Jmeter Cần cập nhật lại - client => khả đẩy request lên server nhanh, số lượng nhiều => server hoạt động với tốc độ Ví dụ: - GUI ngốn tài nguyên máy => RAM có 4GB => ngốn hết 3GB (để generate giao diện show sampler listenner) => 1GB cho việc sinh xử lý requests => nên chậm - Non-GUI, ko tốn tài ngun => máy 4GB trống ~3GB => 3GB dùng cho việc generate requests, xử lý requests => request sinh nhanh hơn, xử lý nhanh 3.16 Tham biến giá trị thay đổi Request Add Post Procecssors Regular Express Extractor - • • • • • Regular Expression Extractor (REE) cho phép bạn lấy giá trị biến từ server trả response message, sử dụng cấu trúc biểu thức quy REE xử lý sau request mà muốn l kết trả về, add bên request mà bạn cần lấy thông tin tin response tương ứng Các thông tin hình REE bao gồm Regular Name: Tên biến nhận thơng tin Regular Expression: Cấu trúc dòng chứa thơng tin cần lấy, vị trí chứa thơng tin cần lấy Thông tin filter cần đặt dấu () viết dạng ngữ pháp regular expression Cấu trúc nà lấy từ View Result tree show Text (tại bước request) tương ứng Template: $1$ Match No (0 for Random):1 Default Value: NOT_FOUND 106 Một số cú pháp thơng dụng • +: kí tự • \d: tất kí tự sơ • [^”]: tất kí tự trừ “ * * Kinh nghiệm cho thấy, login hay thực chức khơng thành cơng kiểm tra response data request trước đó, có chuỗi ký tự: chắn phải dùng hàm Regular Expression Extractor để lấy giá trị biến từ server trả để sử dụng cho tham số request sau => để có response data trả giống với response web trả 3.17 Khắc phục giá trị tham số bị lỗi font Record Run request cho hệ thống ERP 2.0, Link test ứng dụng: http://10.58.71.179:8765/erp-web 107 Acc: pmtc/ qwertyuiop123a@A Thực trạng: - Tham số submit có giá trị = ĐĂNG NHẬP: nên chạy request Jmeter, Jmeter gửi chuỗi ĐĂNG NHẬP lên server => dẫn đến trường hợp server không hiểu chuỗi gửi lên trả kết lỗi font - Khắc phục: bật firebug -> thực login vào hệ thống vào Net->all->post login -> post -> source -> lấy đoạn mã hóa tham số Submit= %C4%90%C4%82NG+NH%E1%BA%ACP, copy đoạn mã hóa paste vào cột value thay giá trị ĐĂNG NHẬP request, xem hình dưới: Paste vào request: 3.18 Phân tích thơng số Aggregate report Jmeter 108 3.18.1 Lable - Hiển thị tên reques test plan bạn Mặc định, tất request bị trùng tên test plan, hiển thị dòng table này, cho dù nội dung request có khác hay nằm khác Thread Group Vì vậy, đặt tên cho Request, người lưu ý nhớ điều này, đặt tên khác 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?” check, request gán thêm tiền tố = tên Thread Group chứa request Tham khảo hình bên dưới: “Include group name in the label?” is CHECKED 109 3.18.2 # Samples - Tổng số lần run 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: Thì HTTP Request Thread Group run 10 x = 30 (lần) —> # Samples: 30 Tuy nhiên, cơng thức khơng số trường hợp: Request bạn nằm bên Logic Controller đó, chẳng hạn Logic Controller, such as Loop Controller, Once Only Controller, While Controller, v.v Ví dụ 2: Tiếp tục với ví dụ trên, lần để HTTP Request vào Logic Controller, Loop Controller, để giá trị Loop Count cho controller Lúc request bạn run: 10 x x = 60 (lần) —> # Samples: 60 3.18.3 Average (milisecond) Thời gian phản hồi trung bình (Response Time) request, tính lần run cuối Ví dụ 3: Một Request A run tổng cộng lần với kết Response Time tương ứng 101ms, 106ms, 153ms, 128ms Thì Response Time trung bình Request A 122ms = (101+106+153+128)/4 3.18.4 Min (milisecond) - Respone Time thấp request tính cho tồn tất lần run Trong ví dụ Min =101 ms 3.18.5 Max(milisecond) - Respone Time cao request tính cho tồn tất lần run Trong ví dụ Min =153 ms 3.18.6 x % Line - x% có giá trị thấp A Ở giải thích sơ qua chút Percentiles Mình xin phép khơng dịch từ này, người đừng hiểu phần trăm (%) Nói cách đơn giản Percentiles số x, kèm theo giá trị A Nghĩa có x% có giá trị thấp giá trị A, lại (100-x)% có giá trị lớn giá trị A Lấy ví dụ đơn giản Sau kiểm tra lớp học, giáo nói 90th Percentile điểm số 110 Nghĩa 90% số điểm lớp điểm, lại 10% cao điểm Hay ví dụ khác, sau làm đánh giá lực để pv vào công ty, người ta thông báo cho bạn điểm số bạn có Percentile là: 74% Nghĩa số tất người làm test này, có 74% số người có điểm thấp bạn, 26% lại có điểm số cao bạn • 90% Line (90th Percentile) (millisecond):nghĩa 90% số requests có response time nhỏ giá trị hiển thị table, 10% số requests lại có response time lớn giá trị hiển thị table • 95% Line (90th Percentile) (millisecond):nghĩa 95% số requests có response time nhỏ giá trị hiển thị table, 5% số requests lại có response time lớn giá trị hiển thị table • 99% Line (90th Percentile) (millisecond):nghĩa 99% số requests có response time nhỏ giá trị hiển thị table, 1% số requests lại có response time lớn giá trị hiển thị table thông số percentile 90th, 95th 99th thông số hay sử dụng percentile, khơng Performance Testing mà lĩnh vực khác Và số hồn tồn cấu hình JMeter thông qua file jmeter.properties, từ phiên 2.12 Mở file từ folder /JMETER_HOME/bin/ tìm đến dòng bên dưới: CODE: SELECT ALL # # Aggregate Report and Aggregate Graph - configuration # # # Percentiles to display in reports # Can be float value between 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 uncomment giá trị aggregate_rpt_pct1, aggregate_rpt_pct2 aggregate_rpt_pct3 cách xoá 111 dấu # đầu, sửa lại giá trị mà bạn muốn Như mình, sửa aggregate_rpt_pct1=75, sau save file, restart JMeter, xem hiển thị nhé: Note: thay đổi giá trị này, thay đổi label header report, đồng thời tính tốn lại cho với số 3.18.7 Error % - % số lượng request bị fail, bị lỗi Ví dụ bạn run request A 100 lần thấy có 15% errors, nghĩa request A fail/error 15 lần (100*15%) 3.18.8 Throughput: Thông lượng Con số cho bạn biết số lượng requests hệ thống (server) xử lý đơn vị thời gian, giây, phút, Cơng thức tính throughput 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 run - Tổng thời gian = (Thời gian bắt đầu chạy request cuối cùng) + (Thời gian chạy/Response Time request cuối cùng) - (Thời gian bắt đầu chạy request đầu tiên) - Đơn vị chuyển đổi: Mặc định tính theo millisecond, nên để đổi second số 1000, 1000*60 bạn muốn chuyển phút Ví dụ 4: Mình run test với threads lần Loop Count, test có HTTP Request access vào google Hãy xem kết bên dướidưới 112 Trong test sử dụng thêm Listener View Result in Table để thấy thông số thời gian start, response time cách nhanh Thời gian bắt đầu chạy request đầu tiên: 17:24:55.911 (1476095095911 in ms) Thời gian bắt đầu chạy request cuối cùng: 17:24:56.838 (1476095096838 in ms) Thời gian chạy/Response Time 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 kiểm tra với Throughput Aggregate Report: Hoàn toàn trùng khớp Điều chứng tỏ công thức Lưu ý: Đối với JMeter ln ln hiển thị Throughput > 1.0, số trường hợp số < 1.0 convert qua đơn vị khác để hiển thị Ví dụ 0.5 requests/second, 0.5 ko thoả điều kiện, nên hiển thị 30requests/min Cũng tương đương mà, phải không bạn Nhưng bạn ghi kết file CSV, số throughput luôn dạng request/second, nên trường hợp hiển thị 0.5 3.18.8 KB/sec – Thông lượng Cũng thông lượng, ko đo lường số request, mà đo Kilobytes/second Công thức Throughput KB/sec = (Throughput * Average Bytes) / 1024 113 Với Aggregate Report khơng thấy thơng số Average Bytes Bạn xem thơng số từ Summay Report 3.18.9 Total Trong report có dòng cuối Total, tổng kết lại toàn kết từ request bên Ngoại trừ # Samples, Throughput KB/sec, cộng lại theo nghĩa "Total" Còn thơng số lại tính Total cách lấy giá trị trung bình từ tất request 3.18.10 Phân tích Sau đọc xong phần trên, bạn có nhìn tổng quan thông số report Ý nghĩa thơng số Bước đây, nhìn vào số đưa đánh giá phù hợp Hãy tập trung vào thông số quan trọng Performance Report: Response Time: việc xử lý request NHANH hay CHẬM Và đương nhiên, Response Time phải THẤP tốt Throughput: số lượng requests server xử lý đơn vị thời gian Vậy thì, thời gian, xử lý nhiều tốt Nên với Throughput phải CAO tốt Dựa vào đó, có trường hợp sau Respose Time Through THẤP THÂP THẤP CAO CAO THẤP CAO CAO KQ Ko xảy Response Time THẤP nghĩa thời gian đáp ứng nhanh, Throughput THẤP lại số request xử lý Noooo, chuyện vơ lý Lý tưởng Thời gian xử lý thấp số lượng request xử lý đồng thời lại cao Còn chần chờ mà khơng tự tin báo cáo Server tốt Hãy xem xét khả mở rộng tính năng, tăng thêm số lượng test để tìm xem giới hạn server Fail Test thời gian xử lý cao, lượng request xử lý lại thấp Phải xem xét để improve phía sever side Khá nhạy cảm bạn thấy Throughput cao, tức server làm 114 việc tốt, thời gian xử lý lại cao (không tốt) Có thể vấn đề lúc đế từ phía Client, cụ thể đến từ JMeter, đoạn script bạn viết chưa tối ưu, khiến q trình xử lý nhiều thời gian chẳng hạn? Hãy kiểm tra lại để chắn có kết test xác 115