Ở bài viết hôm trước chúng ta đã tìm hiểu về cơ bản về Performance Testing, bắt đầu từ bài viết hôm nay chúng ta sẽ cùng nhau practice trên Jmeter tool, một trong những công cụ phổ biến nhất, nhiều tài liệu support nhất.
Test Plan trong Jmeter
Test plan là một tập hợp các bước mà ta sẽ thực hiện để kiểm thử hiệu năng cho một trang web hay một ứng dung. Test plan bao gồm các thành phần sau.
Thread group ( đại diện cho nhóm user ảo bạn mong muốn để test ): Giả sử bạn muốn kiểm tra xem nếu có 100 người dùng truy cập vào trang web cùng lúc thì trang web responsed thế nào. Thread Group giúp bạn tạo các user này này để mô phỏng tình huống đó.
Samplers: Là thành phần thực hiện send request và đợi responsed từ server.
Config Elements: Được sử dụng để cấu hình các parameter cho các Sampler, như url, path,…
Listeners: Tập hợp result của test và hiển thị thông tin phản hồi, thời gian chờ, và các dữ liệu hiệu suất khác dưới dạng đồ thị hoặc bảng.
Timers: Để xác định khoảng thời gian chờ giữa các request, giúp mô phỏng hành vi thực tế của người dùng.
Assertions: Dùng để verify các response, ví dụ HTTP code, data responsed, hoặc các giá trị cụ thể khác.
Thực hành tạo Test Plan
Ở đây ta sẽ test kịch bản đơn giản: giả sử có 1000 user truy cập vào blog: https://duyphamnotes.com/
Add Thread group
Click chuột phải “Test Plan” và thêm thread group mới: Add -> Threads (Users) -> Thread Group
Nhập thêm các giá trị sau trong Thread group:
Number of Threads: 100 (Số lượng người dùng truy cập trang web: 100)
Loop Count: 5 ( Số lần lặp lại => mỗi user sẽ thực hiện kịch bản kiểm thử 5 lần )
Ramp-Up Period: 100 Là thời gian để 100 user này thực hiện xong 1 lần ( trung bình mỗi user 1s để thực hiện 1 action )
Add Jmeter Element
- Click chuột phải Thread Group and chọn: Add -> Config Element -> HTTP Request Defaults.
điền url https://duyphamnotes.com/
- Tạo tiếp một HTTP Request nữa, trong đây mình sẽ nhập thêm đường path để trỏ đến: https://duyphamnotes.com/testing-knowledge/
Add Graph Result
Click chuột phải vào Test Plan: Add -> Listener -> Graph Results
Run and view result
Ấn nút Run (Ctrl + R) trên Toolbar để bắt đầu chạy. Bạn sẽ nhìn thấy kết quả test hiển thị trên Graph
Phân tích kết quả
- Số lượng mẫu (No of Samples):
- Tổng số mẫu thử là 500, tức là có 100 người dùng thực hiện 5 lần yêu cầu đến hệ thống, đúng như cấu hình của mình.
- Thời gian phản hồi trung bình (Average):
- Thời gian phản hồi trung bình (đường màu xanh dương) là 683 ms. Đây là thời gian trung bình mà hệ thống phản hồi cho mỗi request. Với 100 user truy cập, kết quả này có vẻ chấp nhận được.
- Thời gian phản hồi trung vị (Median):
- Thời gian phản hồi trung vị (đường màu tím) là 436 ms. Giá trị trung vị thấp hơn trung bình, cho thấy đa số request có thời gian response khá nhanh, nhưng có một số yêu cầu có thời gian response lâu hơn (outliers), gây kéo dài thời gian trung bình.
- Độ lệch chuẩn (Deviation):
- Độ lệch chuẩn (đường màu đỏ) là 450 ms, cho thấy mức độ dao động trong thời gian phản hồi giữa các yêu cầu. Độ lệch chuẩn cao cho thấy không phải tất cả các yêu cầu đều có thời gian phản hồi ổn định, con số này càng NHỎ thì performance của server càng TỐT
- Throughput:
- Throughput đạt khoảng 210.654 yêu cầu/phút (khoảng 3.5 yêu cầu/giây). Throughput cho thấy số lượng yêu cầu mà hệ thống có thể xử lý trong một phút. Con số này là tương đối ổn định, cho thấy hệ thống vẫn có khả năng duy trì xử lý yêu cầu từ 100 người dùng.
- Xu hướng của các đường biểu diễn:
- Đường xanh lá biểu thị throughput có xu hướng ổn định và đạt đỉnh trong thời gian đầu rồi giữ nguyên, cho thấy hệ thống đã đạt đến khả năng xử lý tối đa và duy trì ở mức đó.
- Thời gian phản hồi trung bình và trung vị ổn định sau khi tất cả người dùng đã được khởi động (sau 100 giây).
Kết luận
- Hệ thống có thể xử lý tốt 100 người dùng với thời gian phản hồi trung bình dưới 1 giây và throughput ổn định.
- Tuy nhiên, độ lệch chuẩn cao cho thấy có sự không đồng đều trong thời gian phản hồi giữa các yêu cầu. Điều này có thể là một điểm cần xem xét nếu hệ thống yêu cầu tính nhất quán cao về thời gian phản hồi.
- Nếu yêu cầu về hiệu suất cao hơn, cần tối ưu hóa để giảm độ lệch chuẩn hoặc cải thiện thời gian phản hồi cho các request outlier.