[MOJITO] - Hướng dẫn sử dụng Jmeter để Test Performance cho hệ thống website
1. Quy trình kiểm thử hiệu năng 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ử và các quản trị dự án. Các bước thực hiện được mô tả một cách rõ rang , mục đích thu được sau khi test phải được mô tả chi tiết . Xác định yêu cầu về hiệu năng, ...
1. Quy trình kiểm thử hiệu năng
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ử và các quản trị dự án. Các bước thực hiện được mô tả một cách rõ rang , mục đích thu được sau khi test phải được mô tả chi tiết . Xác định yêu cầu về hiệu năng, cấu hìn của ranh giới và xác định khi nào bắt đầu kiểm thử
Tạo lập Scripts
Scripts là những thao tác thực tế của người dùng được lưu lại nhằm phục vụ cho việc kiểm thử hiệu năng.Với những công cụ hỗ trợ cho việc kiểm thử hiệu năng, chúng ta có thể lưu lại các bước thực hiện kịch bản đó dưới dạng mã lệnh.Mã lệnh này cũng có thể được chỉnh sửa một cách phù hợp nhất để phục vụ nhu cầu của tester trong tình huống đề ra.
Thiết lập kịch bản test
Kịch bản là trình tự các thao tác, các script sẽ được thực hiện trong một khoảng thời gian với 1 số người dùng xác định để đạt được các mục đích test khác nhau.
Thực thi kịch bản test
Với những kịch bản đã được tạo lập, tester sẽ thực hiện chạy chương trình trên nhiều máy tính khác nhau trong cùng một thời điểm để kiểm thử. Cùng với đó tester sẽ thực hiện việc quản lý và giám sát việc thực thi tình huống trong suốt quá trình chạy.
Phân tích kết quả test
Phân tích kết quả sau khi thực thi và đưa ra những kết luận về hiệu năng.
2. Quy trình thực hiện load test
Các bước thực hiện load test
Bước 1: Xác định các tiêu chí về hiệu năng
- Xác định các tiêu chí về hiệu năng có giá trị nhất khi xác định sớm trong vòng đời phát triển của ứng dụng.Các tiêu chí này thường được mô tả dưới dạng các thông số cụ thể và được lưu trữ lại để tất cả các thành viên tham gia kiểm thử có thể xem xét và thảo luận về chúng. Các tiêu chí sẽ được xác định thông qua các tài liệu đặc tả của website
- Những tiêu chí về hiệu năng thường được đưa ra:
- Thời gian đáp ứng ( thời gian phản hồi) của web site : là thời gian mà website phản hồi lại những yêu cầu từ người dùng. Ví dụ danh mục sản phaảm phải được hiển thị trong vòng chưa đầy 3 giây khi người dùng thực hiện truy cập vào trang chủ của website thương mại .
- Lượng truy cập : Ví du : hệ thống phải hỗ trợ 100 giao dịch mỗi giây
- Tài nguyên sử dụng : Vi xử lý, bộ nhớ , vào/ra đĩa cứng, vào/ra mạng
- Tải người dùng tối đa: Xác định có bao nhiêu người sử dụng có thể chạy trên một cấu hình phần cứng cụ thể.
- Các số liệu nghiệp vụ liên quan : Ví dụ như số lượng đơn đặt hàng hoặc số lượng các cuộc gọi được xử lý ở một thời điểm xác định
Bước 2: Xác định các hành động chính
- Xác định tất cả các kịch bản cho Website - Ví dụ : những website thương mại điện tử thường phải sử dụng những kịch bản dành cho người dùng như : duyệt catalog, tìm kiếm sản phẩm, đặt hàng
- Xác định các hoạt động liên quan đến kịch bản chính
- Ví dụ : Một nút đặt hang kịch bản sẽ bao gồm các hoạt động sau : - Đăng nhập vào trang web
- Duyệt các danh mục sản phẩm
- Tìm kiếm sản phầm
- Thêm các mục vào giỏ mua hàng
- Xác nhận thông tin về thẻ tín dụng và đặt hang
- Xác định kịch bản thường được sử dụng nhất hay thường sử dụng tài nguyên nhiều nhất (đây sẽ là kịch bản chính được sử dụng để thực hiện Load Test) - Chẳng hạn như trong một website thương mại điện tử, tìm kiểm sản phầm có thể là kịch bản thường được thực hiện nhất , trong khi đó việc đặt hang có thể là kich bản sử dụng nhiều tài nguyên nhất bởi vì nó truy cập vào cơ sở dữ liệu - Các kịch bản thường được thực thi cho một ứng dụng web hiện tại có thể được xác định bằng cách kiểm tra các tập tin log - Kịch bản cho các hoạt động sử dụng nhiều tài nguyên nhất có thể được xác định bằng cách sử dụng các tài liệu thiết kế, triển khai hoặc mã thực tế của website. Các nguồn tài nguyên chính cần được quan tâm là: Vi xử lý , bộ nhớ, vào /ra đĩa, vào/ ra mạng - Khi các kịch bản chính được xác định , có thể sử dụng chúng để tạo ra các mẫu workload và thiết kế Load test
Bước 3: Xác định các mẫu Workload
Khi xác định mẫu workload, cần xem xét những đặc điểm sau đây để xác định các đặc tính cho kịch cản sử dụng: - Một kịch bản người dùng : bao gồm các hoạt động được thực hiện bở người sử dụng để hoàn thành một nhiệm vụ . Điều này cũng có thể được coi như là một phiên người dùng - Một người sử dụng thông thường sẽ thực hiện các hành động ngắt quãng giữa các trang trong một phiên. Điều này được coi như là thời gian nghỉ - Một phiên giao dịch sẽ được tính thời gian trung bình khi được đánh giá với nhiều người sử dụng. Điều quan trọng trong thực tết diễn ra khi xác định mức tải là các người dùng sẽ thực hiện đồng thời, chồng chéo nhau - Không phải tất cả các các kịch bản đều có thể được thực hiện bởi một người dùng mới, người dùng đã từng sử dụng website, hoặc một trong hai. Việc biết người sử dụng chính cho từng kịch bản sẽ có lợi và phù hợp cho việc kiểm thử
Bước 4: Xác định mức tải mục tiêu
Xác định mức tải mục tiêu được áp dụng chó việc phân phối khối lượng công việc được xác định trong các bước trước. Mục đich của việc xác định các mức tải mục tiêu là để đàm bảo rằng các kiểm thử có thể được sử dụng để dự đoán hoặc so sánh với các điều kiện tải trọng hiệu suất. Sau đây là những yếu tố đầu vào thường được sử dụng để xác định các tải mục tiêu: - Khối lượng công việc ( hiện tại và dự kiến ) Vì nó liên quan đến các mục tiêu hiệu năng - Kịch bản chính - Phân phối công việc - Đặc điểm của phiên giao dịch ( danh sách các bước, thời gian, tỷ lệ người dùng mới,... ) Bằng cách kết hợp các yếu tố trên , có thể xác định được các nội dung chi tiết cần thiết để thực hiện mẫu workload ở một mức tải cụ thể
Bước 5: Xác định các thông số
Trong quá trình kiểm thử hiệu năng, các số liệu thu thập được là không giới hạn. Tuy nhiên, việc thu thập quá nhiều số liệu có thể gây khó khăn khi phân tích cũng như tác động tiêu cực đến thực tế của ứng dụng. Vì vậy, điều quan trọng là xác định các số liệu có liên quan nhất đến mục tiêu hiệu năng, những điều cần thiết sẽ giúp xác định điểm tắc nghẽn.Chỉ những số liệu được phân tisch một cách chính xác và cung cấp những thông tin có giá trị mới được lựa chọn. Dưới đây là một vài gợi ý giúp xác đinh các số liệu sẽ cung cấp những thông tin có giá trị nhất : Xác định câu hỏi liên quan đến hiệu năng của ứng dụng mà có thể dễ dàng kiểm tra được : ví dụ như thời gian đáp ứng thanh toán khi đặt hàng là gì , làm thế nào để nhiều đơn đặt hàng được đặt trong một phút. Với những câu trả lời cho những câu hỏi ở trên, xác đinh mục tiêu hiệu năng để so sánh : ví dụ như thời gian check out nên là 30 giây và tối đa là 10 đơn đặt hàng nên được đặt trong một phút. Các câu trả lời được dựa trên nghiên cứu thị trường, dữ liệu lịch sử,.. Xác đinh các số liệu: sử dụng danh sách các câu hỏi và câu trả lời liên quan đến hiệu năng, xác định các số liệu cung cấp thông tin liên quan đến những câu hỏi và câu trả lời Xác định các số liệu hỗ trợ: Giúp xác đinh mức tải chấp nhận được cho ứng dụng. Các giá trị cơ bản giúp phân tích hiệu năng của ứng dụng ở các mức tải khác nhau Đánh giá lại các số liệu thu thật được một cách thường xuyên : mục tiêu, ưu tiên , rủi ro và các vấn đề hiện tại bị rang buộc để thay đổi trong quá trình của dự án. Với mỗi thay đổi, các số liệu khác nhau có thể cung cấp những giá trị nhiều hơn so với những giá trị mà trước đây đã xác định
Bước 6:Thiết kế kiểm thử chi tiết
Việc thiết kế các kịch bản kiểm thử cụ thể cần sử dụng những kịch bản đậto ra, những số liệu chính được lựa chọn và các mẫu workload. Với mỗi thử nghiệm khác nhau sẽ có một mục đích khác nhau, thu thập dữ liệu khác nhau, các kịch bản khác nhau và có các mức tải mục tiêu khác nhau.
1. Các điểm cần chú ý khi thiết kế kiểm thử bao gồm:
2. Không thay đổi thiết kế kiểm thử vì các thiết kế khó thực hiện trong công cụ
3. Nếu không thể thực hiện việc cài đặt thử nghiệm như thiết kế, hãy đảm bảo rằng những chi tiết liên quan đến việc cài đặt thử nghiệm đã được ghi lại.
4. Đảm bảo rằng mô hình có chứa tất cả các dữ liệu cần thiết để tạo ra những thử nghiệm thực tế.
5. Người dùng lần đầu thường dành nhiều thời gian hoạt động trên từng trang hơn những người dùng có kinh nghiệm (đã từng sử dụng trang ở những lần trước)
6. Các dữ liệu kiểm thử tốt nhất là những dữ liệu thu được từ một cơ sở dữ liệu hoặc log file
7. Không nên quá bị cuốn vào những yếu tố phức tạp và bỏ qua những hành động đơn giản nhất
Bước 7 : Chạy thử nghiệm
Đây là bước sử dụng những công cụ có sẵn để thực hiện việc thực thi những gì đã thu được ở 6 bước trên. Ở bước này , tester sẽ thực hiện việc mô phỏng kịch bản đã được xây dựng với những mẫu workload đã được xây dựng tương ứng bằng những công cụ kiểm thử tự động Việc mô phỏng tải sai lệch có thể làm cho tất cả những thiết kế ở 6 bước trên trở nên vô ích. Để hiểu được các dữ liệu thu thập từ việc thực thi thử nghiệm, mô phỏng tải phải phản ánh được thiết kế thử nghiệm vì khi mô phỏng không phản ánh được thiết kế thì kết quả sẽ bị hiểu sai. Những bước khi chuẩn bị mô phỏng tải như sau: - Bước 1: Cấu hình môi trường thử nghiệm theo một cách mà nó phản ánh môi trường sử dụng thực tế càng nhiều càng tốt, và nếu có sự khác biệt, nên chú ý sự khác biệt đó. - Bước 2: Đảm bảo rằng các bộ đo hiệu năng cho các số liệu xác định được và không can thiệp vào tính chính xác của mô phỏng tải. - Bước 3: Sử dụng các công cụ tạo tải trọng thích hợp để tạo ra tải với các đặc điểm được mô tả trong thiết kế thử nghiệm. - Bước 4: Một số điểm lưu ý trong quá trình thực hiện thử nghiệm bao gồm: + Bắt đầu với một số lượng nhỏ người dùng phân phối theo hồ sơ người dùng, và sau đó tăng dần tải trọng. Điều này là để có thời gian cho hệ thống ổn định giữa tăng tải trong khi đánh giá tính chính xác của các mô phỏng. + Xem xét việc tiếp tục tăng tải và ghi lại hành vi cho đến khi đạt đến ngưỡng cho các nguồn lực được xác định trong mục tiêu hiệu suất đã được đặt ra, ngay cả khi tải đó vượt quá tải trọng mục tiêu quy định trong thiết kế thử nghiệm. Thông tin về hành vi của hệ thống khi đi qua ngưỡng xác định cũng quan trọng như giá trị của các số liệu tại tải mục tiêu của thử nghiệm.
Bước 8 : Phân tích kết quả
Phân tích các kết quả thu được để tìm điểm tắc nghẽn hiệu năng giữa mỗi lần chạy thử nghiệm hoặc sau khi toàn thành tất các thử nghiệm. Dưới đây là các bướcđể phân tích các dữ liệu: - Phân tích các dữ liệu thu thập được và so sánh kết quả đó với mức độ chấp nhận được của số liệu để xác định xem hiệu suất của các Website đang được thử nghiệm chỉ ra những kết quả gì. - Phân tích các số liệu đo để chuẩn đoán tắc nghẽn . Dựa trên các phân tích, nắm bắt số liệu bổ sung trong vòng kiểm tra tiếp theo
3. Các thành phần cơ bản của jmeter
JMeter cung cấp tất cả những thành phần cơ bản để phục vụ cho việc thiết kế kế hoạch, thực thi và giám sát kết quả trong suốt quá trình test. Những thành phần cơ bản của JMeter là:
- Thread Group
- Controller ( Sampler và Logic Cotroller )
- Configuration Element
- Listener
- Timer
1. Thread Group
Hình 3.2 : Giao diện của 1 Thread Group
Một Thread Group đại diện cho một nhóm người dùng, và nó chứa tất cả những yếu tố khác.Mỗi Thread Group sẽ mô phỏng những người dùng để thực hiện một trường hợp thử nghiệm cụ thể. Thread Group cho phép tester thực hiện những tùy chỉnh về:
- Số lượng Thread: Mỗi Thread đại diện cho một người dùng ảo, JMeter cho phép thay đổi số lượng người dùng không hạn chế để thực hiện các thử nghiệm.
- Ram-Up Period: Thời gian để bắt đầu tất cả những Thread.
- Loop Count: Số lần lặp lại những yêu cầu của người dùng. Ngoài ra còn có những tùy chọn khác như việc chạy các Thread vào lịch biểu định sẵn, xác định hành động sẽ thực hiện khi xảy ra lỗi…
2. Controller
JMeter cung cấp hai dạng Controller: Sampler và Logic Controller, trong đó: - Sampler ( lấy mẫu ): Cho phép JMeter gửi những yêu cầu cụ thể đến một máy chủ. - Logic Controller: Tùy biến việc khi nào thì gửi yêu cầu. Các thành phần Controller được tạo ra để định nghĩa kịch bản thực tế của người dùng bằng việc ghi lại những yêu cầu cụ thể của người dùng tới một server xác định.Cụ thể đối với kiểm thử website thì đó là những HTTP Request được gửi đến server của người dùng.
3. Listeners
Công cụ Listener mà JMeter cung cấp cho phép xem những kết quả thu được từ việc chạy thử nghiệm dưới các dạng khác nhau như: đồ thị, bảng biểu, cây.. Các listeners sẽ cung cấp một cách trực quan nhất những dữ liệu thu thập được từ việc thực thi các Test case. Tester cũng sẽ có thể tùy chỉnh những thông tin mà Listener trả về một cách dễ dàng bởi các tính năng trong giao diện cụ thể của từng Listener. Có rất nhiều dạng Listener được JMeter cung cấp, có thể kể đến một số Listener thường được sử dụng để cung cấp như:
- Graph Full Results: Cung cấp tất cả những kết quả trả về dưới dạng đồ thị : Lỗi, thời gian phản hồi, lưu lượng …
- View Results in Table: Hiển thị những thông số về thời gian phản hồi của từng yêu cầu, những yêu cầu thực hiện thành công và thất bại… dưới dạng bảng.trong suốt quá trình thực thi thử nghiệm.
- Summary Report : Cung cấp những thống kê tổng thể.
- Timer:
- Timer là một phần rất quan trọng khi xây dựng một Test Plan, nó cho phép cài đặt khoảng thời gian giữa 2 yêu cầu kế tiếp nhau mà người dùng ảo gửi đến máy chủ. Điều này sẽ tạo ra một mô phỏng thực tế nhất so với hoạt động thực tế của người dùng trên website.
- JMeter cung cấp nhiều Timer với các dạng khác nhau để thiết lập thời gian nghỉ giữa việc thực hiện 2 yêu cầu , như :
- Constant Timer: xác lập thời gian là một hằng số.
- Uniform Random Timer: xác lập thời gian nghỉ ở một khoảng xác định.
- Assertion: là công cụ có tác dụng xác nhận những dữ liệu mà Website trả về có đúng với yêu cầu đặt ra hay không.
4. Mô phỏng tải và chạy thử nghiệm
Bước 1: Ghi lại các hành động của người dùng
JMeter cung cấp công cụ HTTP(S) Test Script Recorder, công cụ này có khả năng lưu lại những yêu cầu HTTP mà người dùng gửi đến server bằng cách ghi lại những bản ghi trong quá trình người dùng thực hiện những thao tác lên trình duyệt. Để ghi lại những yêu cầu này, ta cần thiết lập port cho HTTP(S) Test Script Recorder và thiết lập port tương tự ở trình duyệt để HTTP(S) Test Script Recorder có thể lắng nghe được những thao tác mà người dùng thao tác trên trình duyệt. Để sử dụng các chức năng mà HTTP(S) Test Script Recorder cung cấp, trong giao diện chính của JMeter, chọn WorkBench Add None-Test Elements HTTP(S) Test Script Recorder. Thiết lập thông số port là 8080 để ghi lại những yêu cầu HTTP khi người dùng thực hiện các thao tác trên trình duyệt. Các thiết lập được biểu diễn như hình sau:
Hinh Giao diện tính năng HTTP(S) Test Script Recorder Tiếp theo, thiết lập thông số port trong trình duyệt cũng là 8080 (Trình duyệt được sử dụng ở đây là Firefox ). Trong phần tùy chọn của Firefox, thiết lập Proxy với các thông số tương ứng là: Proxy HTTP: localhost. Cổng: 8080.
Hình . Thiết lập Proxy trong trình duyệt Firefox Những thao tác này giúp JMeter có thể lắng nghe và ghi lại những yêu cầu HTTP (mẫu sử dụng) của người dùng khi thực hiện những thao tác truy nhập web trên trình duyệt Firefox. Tiếp theo, để lưu lại những mẫu HTTP Requet, ta sẽ tạo những Simple Controller và đặt tên tương ứng với từng kịch bản cụ thể. Mỗi Simple Controller sẽ được đặt trong mỗi test plan tương ứng, với số lượng Thread – người dùng đã thiết kế như yêu cầu. Vào HTTP(S) Test Script Recorder, chọn Target Controller là WorkBench HTTP(S) Test Script Recorder TrangChu và nhấn nút Start để bắt đầu thực hiện chức năng record các yêu cầu. Tiếp theo, thực hiện việc truy cập vào địa chỉ trang chủ bằng trình duyệt Firefox :http://tradiem.ptit.edu.vn/ để ghi lại những yêu cầu HTTP mà người dùng gửi đến web server. Tương tự, trước khi ghi lại những HTTP Request của hành động Tra cứu điểm thi, ta sẽ chọn Target Controller là WorkBench HTTP Proxy Server TraCuuDiemThi.
Giao diện của Jmeter trước khi ghi lại thao tác của người dùng
Nhấn Start để bắt đầu ghi lại những mẫu HTTP request. Sau khi thực hiện việc ghi lại những mẫu yêu cầu HTTP, JMeter sẽ có giao diện như sau:
Bước 2: Thiết lập các thông số theo yêu cầu
Theo mức tải đích đã được thiết kế cho kịch bản:
- 55 user thực hiện hành động TrangChu
- 45 user thực hiện hành động TraCuuDiemThi
Ta sẽ tạo 2 Thread Group và đặt tên là số lượng người dùng trong đó: 55 users và 45 users Để kiểm tra tải của website Cổng thông tin tuyển sinh PTIT, ta sẽ bắt đầu tăng dần số lượng người dùng lên từ 1~55 trong vòng 550s với Kịch bản 1, 1~45 trong vòng 450 giây với kịch bản 2. Mục đích tăng dần số lượng là để Web Server có thời gian để thích ứng với số lượng user tăng lên. Tiếp theo, khi các user đã hoạt động ổn định, ta sẽ theo dõi hoạt động của các users trong vòng 2h và tiến hành phân tích các tham số để đánh giá khả năng tải của server. Để thiết lập các thông số kể trên, ta tạo 2 Thread Group tương ứng với 2 request tương ứng đã thu được từ việc ghi lại các bản ghi đã kể trên. Kéo và thả Controller TrangChu, TraCuuDiemThi vào các Group tương ứng 55 users, 45 users. Thiết lập số lượng user lần lượt là 55, 45 với các Thread Group tương ứng 55 users, 45 users . Sau đây là hình ảnh biểu diễn các thiết lập kể trên:
Hình : Thiết lập thông số cho hành động truy nhập Trang chủ
Hình: Thiết lập thông số cho hành động tra cứu điểm thi Số lần gửi yêu cầu sẽ được thiết lập là Forever, để đảm bảo rằng những người dùng sẽ liên tục gửi yêu cầu tới server trong suốt quá trình test nhằm tạo ra tải tăng dần.
Bước 3: Thêm Listeners để theo dõi những kết quả trong quá trình test
Muốn thêm một Listener cho một hành động, ta click chuột phải vào hành động đó rồi chọn Add Listener Listeners muốn thêm. Để theo dõi quá trình chạy, ta thêm các Listener với các chức năng tương ứng sau:
- View Results in Table: Cho phép theo dõi các thông tin về số thứ tự yêu cầu, thời gian bắt đầu mỗi yêu cầu, người sử dụng (ảo) thực hiện yêu cầu, thời gian phản hồi của mỗi yêu cầu, dung lượng mỗi yêu cầu trả về.
- View Results Tree: Cho phép theo dõi thông tin của dữ liệu mà Server trả về cho mỗi người dùng dưới các dạng khác nhau.
- Graph Results: Trả về đồ thị biểu diễn những thông số về: Số lượng yêu cầu, lượng yêu cầu được xử lý mỗi phút, giá trị trung bình, giá trị trung vị của toàn bộ thời gian phản hồi từ server.
- Summary Report: Cung cấp báo cáo về các giá trị: thời gian phản hồi thấp nhất/cao nhất, số yêu cầu xảy ra lỗi, lưu lượng trung bình.
Bước 5. Tiến hành chạy thử nghiệm
Sau khi xây dựng và cài đặt xong các thông số để thực hiện test, Test Plan của JMeter sẽ có giao diện như sau: Hình : Giao diện Test plan của Jmeter sau khi thiết lập các thông số
Để bắt đầu chạy thử nghiệm, chọn lệnh Run Start hoặc Click vào nút Run màu xanh trên giao diện chính của chương trình. Quá trình kiểm thử sẽ được thử nghiệm trong vòng 2h để theo dõi những phản hồi của website
6. Phân tích kết quả
Với hành động TrangChu Các kết quả thu được từ Listener View Results in Table : Hình : Những bản ghi đầu của hành động truy nhập trang chủ
Hình : Những lỗi đầu tiên ghi nhận được
Hình : Những bản ghi cuối của hành động truy nhâp trang chủ
Kết quả thu được từ Listener Summary Report: Hình :Summary Report của hành động truy cập trang chủ
Kết quả thu được từ Listener Graph Results: Hình :Đồ thị kết quả của hành động truy cập trang chủ
Những kết quả thu được khi phân tích kết quả từ các Listener với kịch bản Home Page :
- Có thể thấy ban đầu khi số lượng người dùng đang tăng dần thì thời gian phản hồi của Server là khá nhanh, chỉ khoảng < 2s, còn khi đạt số lượng người dùng cố định là 55 người cùng thực hiện truy cập vào trang chủ, con số này rơi vào khoảng ~ 37,15s. Lưu lượng số yêu cầu được thực hiện thành công tăng từ từ khi số lượng người dùng tăng và sau đó rất ổn định( những vạch này được vẽ kế tiếp lên trên)
- Dựa vào bảng này, có thể thấy tất cả các yêu cầu của người dùng đều được thực hiện thành công, với lượng dữ liệu trả về từ Website là 192377 byte cho mỗi yêu cầu.
- Throughput của website sau khi test là 85,382/ minutes có nghĩa là server xử lý 85,382 yêu cầu trên một phút
- Deviation của website sau khi test bằng 380850 nó cho thấy sự sai lệch hiện tại so với mức trung bình
- Số lượng giao dịch lỗi chỉ chiếm 4,06% cho thấy website hoạt động khá tốt
- Giá trị thời gian phản hồi trung bình là 37,155ms
Với hành động Tra cứu điểm thi , các Listener cho các kết quả tương ứng sau Hình: Những bản ghi đầu của hành động tra cứu điểm thi
Hình : Những bản ghi lỗi đầu tiên của hành động Tra cứu điểm thi
Hình : Những bản ghi cuối của hành động tra cứu điểm thi
Hình : Summany Report của hành động tra cứu điểm thi
Hình :Đồ thị kết quả của hành động tra cứu điểm thi
Những kết luận rút ra sau khi phân tích:
- Cũng giống với kịch bản TrangChu, khi số người dùng đang tăng dần thì thời gian phản hồi của Server là chỉ khoảng 3s , nhưng khi số lượng người dùng tăng một cách ổn định thì thời gian phản hồi trung bình cũng dần tăng theo. Lưu lượng người dùng cũng rất ổn định với con số 65,772 giao dịch thành công trên 1 phút
- Thời gian phản hồi trung bình là 39749 ms cho tổng số 7930 giao dịch được thực hiện, trong đó yêu cầu được phản hồi lâu nhất là 6897848 ms. Số giao dịch không thành công cho hành động tra cứu điểm thi là 5,02%. Độ lớn dữ liệu trả về cho mỗi giao dịch thành công là 193850 bytes. Kết luận :Những điều có thể rút ra sau khi thực hiện Load Test cho website Cổng thông tin tuyển sinh PTIT:
- Website có khả năng tải khá tốt. Trong suốt thời gian hoạt động, với số lượng là 100 người dùng cùng truy nhập vào website, gần như tất cả các giao dịch đều được thực hiện thành công
Phụ lục:
Dưới đây là video hướng dẫn thực hiện chi tiết một kịch bản hoản chỉnh: