lƣợc đo nhƣ sau:
Lần tăng 1: Từ 0 đến 100 kết nối trong vòng 25 giây và giữ vững trong vòng 300 giây.
Lần tăng 2: Lặp 10 lần, mỗi lần tăng 25 kết nối trong vòng 25 giây và giữ vững trong 300 giây.
Bảng 4. 3. Các kịch bản kiểm thử sử dụng phần mềm Jmeter Số lƣợng ngƣời Số lƣợng ngƣời
dùng
Mô tả các bƣớc Kết quả mong muốn 1 ngƣời dùng
duyệt nội dung
trang web
christmas- clothing.com
1. Ngƣời dùng truy cập vào trang chủ thành công.
2. Ngƣời dùng tìm kiếm mẫu áo thích hợp.
3. Ngƣời dùng kích chọn xem chi tiết một mẫu áo.
4. Ngƣời dùng kích chọn kiểu áo, màu áo thích hợp.
5. Ngƣời dùng chọn mua sản phẩm.
-Xem kịch bản kiểm tra đƣợc tạo ra có chạy đúng khi mô phỏng 1 ngƣời dùng ảo không?
25 ngƣời dùng duyệt nội dung
trang web
christmas- clothing.com
1. Ngƣời dùng truy cập vào trang chủ thành công.
2. Ngƣời dùng tìm kiếm mẫu áo thích hợp.
3. Ngƣời dùng kích chọn xem chi tiết một mẫu áo.
4. Ngƣời dùng kích chọn kiểu áo, màu áo thích hợp.
5. Ngƣời dùng chọn mua sản phẩm.
-Số liệu thời gian phản hồi, tỉ lệ lỗi. -Tài nguyên của hệ
thống (giá trị trung bình CPU Load, Ram sử dụng)
Tiếp tục tăng số ngƣời dùng mỗi lần 25 ngƣời duyệt nội dung
trang web
christmas- clothing.com
1. Ngƣời dùng truy cập vào trang chủ thành công.
2. Ngƣời dùng tìm kiếm mẫu áo thích hợp.
3. Ngƣời dùng kích chọn xem chi tiết một mẫu áo.
4. Ngƣời dùng kích chọn kiểu áo, màu áo thích hợp.
5. Ngƣời dùng chọn mua sản phẩm.
-Số liệu thời gian phản hồi, tỉ lệ lỗi. -Tài nguyên của hệ
thống (giá trị trung bình CPU Load, Ram sử dụng) Tăng số ngƣời dùng giả lập bằng Jmeter cho đến khi hệ thống không còn khả năng đáp ứng đƣợc.
1. Ngƣời dùng truy cập vào trang chủ thành công.
2. Ngƣời dùng tìm kiếm mẫu áo thích hợp.
3. Ngƣời dùng kích chọn xem chi tiết một mẫu áo.
4. Ngƣời dùng kích chọn kiểu áo, màu áo thích hợp. 5. Ngƣời dùng chọn mua sản phẩm. - Xác định số ngƣời dùng tối đa. - Xác định mối quan hệ giữa tải và số lƣợng ngƣời sử dụng. 4.5 Kết quả kiểm thử
Cài đặt phần mềm Jmeter và thử nghiệm với các kịch bản trên. Trƣớc khi thực hiện kiểm thử chúng ta cài đặt các thông số cho kịch bản: số ngƣời dùng ảo (Thread), khoảng thời gian truy cập vào hệ thống (ramp-up), số lần lặp (Loop count)...
Hình 4. 3. Thiết lập các kịch bản kiểm thử
Các kịch bản sẽ đƣợc lƣu dƣới dạng tập tin jmx: christmas-clothing.com.jmx. Các dữ liệu kiểm thử sẽ đƣợc lƣu trữ tập trung trong một thƣ mục Config. Hình 4.3 cho thấy số ngƣời dùng ảo đƣợc mô phỏng bởi phần mềm Jmeter là 100 ngƣời đồng thời duyệt nội dung trang web christmas-clothing.com.
Ở đây tôi trình bày với kịch bản lặp 10 lần, mỗi lần tăng 25 kết nối trong vòng 25 giây và giữ vững trong 300 giây và lấy kết quả trung bình để tăng độ tin cậy. Các kết quả đo kiểm năng lực của máy chủ đƣợc thực hiện cho biết khả năng phản hồi trung bình, tỉ lệ lỗi cũng nhƣ đánh giá năng lực nói chung của máy chủ trong khả năng trao đổi, truyền thông tin trên mạng; khả năng xử lý truy cập vào/ra (I/O) giữa các thành phần lƣu trữ (đĩa cứng), bộ nhớ (RAM/cache) của máy chủ. Một điểm đáng chú ý là bên cạnh năng lực tính toán thể hiện chủ yếu qua khả năng xử lý của CPU thì khả năng giao tiếp I/O và giao tiếp mạng là 2 yếu tố rất quan trọng tạo lập lên năng lực xử lý công việc nói chung của một máy chủ.
Kiểm thử cơ sở (một ngƣời sử dụng hệ thống)
Hình 4. 4. Kết quả kiểm thử cơ sởJmeter biểu diễn kết quả dƣới dạng bảng, nhƣ hình 4.4. Trong đó: Jmeter biểu diễn kết quả dƣới dạng bảng, nhƣ hình 4.4. Trong đó:
• Cột Label: là tên request.
• Cột Samples: là số lƣợng request.
• Cột Average: đƣợc tính toán là khoảng thời trung bình để xử lý request.
• Cột Min: là thời gian nhỏ nhất xử lý request.
• Cột Max: là thời gian nhỏ nhất xử lý request.
• Cột Std. Dev: độ lệch chuẩn của thời gian xử lý các request.
• Cột Error: phần trăm bị lỗi của các request (lỗi kết nối hoặc lỗi cho đầu ra không mong muốn).
• Cột Thoughput: đƣợc tính toán là số request đƣợc xử lý thành công trong một
đơn vị thời gian. Thời gian này đƣợc tính toán bắt đầu từ Sample đầu tiên cho tới sample cuối cùng, bao gồm cả khoảng thời gian giữa các sample. Thời gian này đƣợc cho là sự phản hồi của lƣợng tải trên máy chủ
Công thức tính Throughput = số lƣợng request/ tổng thời gian thực hiện Đơn vị là số request/s.
• Cột Kb/sec = (avg.bytes*thoughput)/1024
Dựa vào hình 4.4 ta thấy không có lỗi xảy ra khi thực hiện kiểm thử cơ sở. Nhƣ vậy kịch bản kiểm thử đƣợc tạo ra là chạy đúng khi mô phỏng 1 ngƣời dùng ảo.
Kết quả chạy với số ngƣời dùng khác nhau: 25, 50, 75, 100, 125, 150, 175, 200, 225, 250, 275, 300 ngƣời dùng đồng thời.
4.5.1 Tỉ lệ lỗi
Từ kết quả chạy các kịch bản với các giá trị tăng dần của số ngƣời đồng thời thực hiện truy cập hệ thống trên Hình 4.5, tôi vẽ đƣợc đồ thị bên dƣới đƣa ra sự thay đổi của tỉ lệ lỗi HTTP request theo sự biến thiên của tải
Hình 4. 6. Tỉ lệ lỗi với số ngƣời dùng đồng thời lần lƣợt là 25, 50, 75, 100, 125, 150, 175, 200, 225, 250, 275, 300.
Dựa vào hình 4.6 ta thấy: Khi số ngƣời dùng tăng lên từ 25, 50, 75, 100, 125, 150, 175, 200, 225, 250, 275 và 300 thì tỉ lệ lỗi ở mỗi trang cũng tăng lên với tốc độ khác nhau. Cụ thể: khi số ngƣời dùng ảo tăng từ 1 đến 175 thì chƣa xuất hiện lỗi, nhƣng với số lƣợng ngƣời dùng ảo lên đến trên 175 thì bắt đầu xuất hiện tỉ lệ lỗi. Với 200 ngƣời dùng ảo tỉ lệ lỗi là 0.79% và tiếp tục tăng gần nhƣ tuyến tính cho đến giá trị 275. Tuy nhiên đến 300 ngƣời dùng ảo đồng thời gửi request thì tỉ lệ lỗi là 4,45%. Có thể thấy rõ, khi tải (số ngƣời dùng ảo) vƣợt quá 275 và tiếp tục tăng, tỉ lệ lỗi sẽ tăng nhanh.
4.5.2 Thời gian phản hồi
Thời gian phản hồi trung bình (Response Time): Đồ thị biểu thị thời gian từ khi một hành động yêu cầu từ client đến khi máy chủ hoàn tất yêu cầu này. Tải ở đồ thị này là số lƣợng kết nối đồng thời. Số lƣợng kết nối đồng thời tại một thời điểm bất kì là khác nhau.
Đồ thị chỉ ra với mức tải tƣơng ứng thì thời gian hồi đáp tƣơng ứng là bao nhiêu. Phép thử này nhằm đánh giá khả năng mà máy chủ có thể đáp ứng với số lƣợng ngƣời dùng khác nhau. 0 1 2 3 4 5 6 7 8 0 50 100 150 200 250 300 350 Er ror % Users Error vs Users
Hình 4. 7. Thời gian phản hồi với số ngƣời dùng đồng thời khác nhau
Dựa vào đồ thị trên ta thấy thời gian phản hồi trung bình biến thiên tăng theo tải, nhƣng với tốc độ khác nhau, tƣơng tự sự tăng của tỉ lệ lỗi theo tải, trên hình 4.6. Khoảng dƣới 175 ngƣời truy cập đồng thời thì thời gian phản hồi tăng chậm theo tải từ khoảng 1 giây đến khoảng 4 giây. Nhƣ vậy, khả năng chịu tải của hệ thống là dƣới 225 ngƣời dùng đồng thời thì thời gian phản hồi có thể chấp nhận đƣợc. Tuy nhiên với mức tải tăng lên 225 ngƣời thì thời gian phản hồi đã tăng lên 9 giây và với trên 300 ngƣời đồng thời thì thời gian phản hồi lớn hơn 10 giây. Ta thấy thời gian phản hồi của hệ thống tăng lên khá lớn, chứng tỏ hiệu năng của hệ thống bị giảm sút mạnh.
4.5.3 Thông lƣợng 0 0 2000 4000 6000 8000 10000 12000 14000 0 50 100 150 200 250 300 350 A vg . R e sp o n se Ti m e ( m s) Users
Response Time vs Users
Hình 4. 8. Thông lƣợng với số ngƣời dùng đồng thời khác nhau
Nhìn đồ thị trên hình 4.8 có thể nhận thấy, dáng điệu biến đổi của thông lƣợng theo tải (user), tƣơng tự sự biến đổi của tỉ lệ lỗi theo tải (Hình 4.6) và sự biến đổi của thời gian phản hồi theo tải (Hình 4.7).
Trong miền tải từ khoảng 175 đến 250, thông lƣợng có sự thay đổi khá đặc biệt, ban đầu (khoảng 175...210) nó giảm khá đột ngột, chứng tỏ hệ thống bắt đầu bị quá tải, có dấu hiệu của tắc nghẽn, đó là khi tải đƣa vào hệ thống tăng lên, thông lƣợng lại giảm đi. Tuy nhiên khi tải tăng tiếp (khoảng 210...250) thông lƣợng lại tăng lên theo tải. Trong phạm vi hiểu biết của tôi, điều có vẻ “đặc biệt” nói trên là do hoạt động của hệ điều hành, có thể liên quan đến việc quản lý bộ nhớ hoặc quản lý bộ nhớ ảo, hoặc bộ nhớ cache. Sau này, nếu có điều kiện nghiên cứu tiếp, tôi sẽ có gắng tìm hiểu sâu sắc hơn.
4.5.4 Sử dụng tài nguyên máy chủ
Để hỗ trợ giám sát mức độ sử dụng CPU, Memory, Disks I/O and Networks I/O,... nhằm tìm ra thành phần là “nút cổ chai” của hệ thống và đƣa ra khuyến nghị nâng cấp hệ thống một cách chính xác, tôi đã cài thêm Server Agent trong máy chủ của tôi và cài thêm cũng nhƣ cấu hình plugin jmeter perfmon trong jmeter "jp@gc - PerfMon Metrics Collector". Tôi đã nhận các đồ thị trong jmeter nhƣ hình dƣới đây:
0 50 100 150 200 250 300 350 400 450 500 0 50 100 150 200 250 300 350 Th ro u gh p u t (k b p s) Users Throughput vs User
a) Kết quả sử dụng CPU (CPU Utilization) với số ngƣời dùng ảo tăng dần từ 25, 50, 75, 100, 125, 150, 175, 200, 225, 250, 275 ngƣời dùng đồng thời (a1) (a2) (a3) (a4)
(a5)
(a6)
Hình 4. 9. Sử dụng CPU trên máy chủ với số ngƣời dùng đồng thời khác nhau Dựa vào Hình 4.9 (a1, a2, a3 a4) trên ta thấy mô hình sử dụng CPU của hệ thống Dựa vào Hình 4.9 (a1, a2, a3 a4) trên ta thấy mô hình sử dụng CPU của hệ thống đƣợc đặt trong tải ổn định từ 1 hoặc 250 ngƣời sử dụng đồng thời trong 10 phút. Mức sử dụng trung bình trong khoảng 30% - 60%.
Mối quan hệ giữa mức độ sử dụng CPU và số lƣợng ngƣời sử dụng hệ thống
Hình 4. 10. Mối quan hệ giữa số lƣợng user và số lƣợng ngƣời tham gia hệ thống Sử dụng số liệu lấy từ các đồ thị trên hình 4.9, tôi vẽ đƣợc đồ thị hình 4.10. Sử dụng số liệu lấy từ các đồ thị trên hình 4.9, tôi vẽ đƣợc đồ thị hình 4.10. Trong miền tải (users) dƣới 200, khi tải tăng lên, thì hệ số sử dụng CPU (CPU usage)
0 20 40 60 80 100 0 50 100 150 200 250 300 CP U usa ge in % Users CPU vs Users
tăng lên theo gần nhƣ theo quy luật tuyến tính, đây chính là điều ngƣời xây dựng hệ thống thông tin mong muốn.
Khi tải vƣợt quá 200 và tiếp tục tăng lên, hệ số sử dụng CPU tăng lên rất nhanh, không còn theo quy luật tuyến tính nữa. Điều này cho thấy CPU bắt đầu bị quá tải. Quan sát Hình 4.9 (a1, a2, a3,…,a6) trên ta thấy:
- Khi tải tăng dần từ 50 đến 100 ngƣời sử dụng đồng thời, mức độ sử dụng CPU cũng tăng dần lên, từ khoảng 30% đến 50%.
- Khi tải tiếp tục tăng cao hơn, từ 150 đến 200 ngƣời sử dụng đồng thời, mức độ sử dụng CPU trung bình nói chung không tăng, ở vào khoảng 50%, nhƣng thăng giáng ngày càng lớn hơn.
- Khi tải tăng lên cao hơn nữa, từ 200 đến 275 ngƣời sử dụng đồng thời, mức độ sử dụng CPU trung bình thậm chí vừa giảm vừa thăng giáng rất mạnh, có những khoảng thời gian khá dài xấp xỉ bằng 0.
Từ các kết quả quan sát trên, tôi có thể rút ra kết luận:
1/ Tài nguyên CPU không phải là thành phần “nút cổ chai” của hệ thống, lúc đƣợc sử dụng cao nhất, hệ số sử dụng CPU mới vào khoảng 55%.
2/ Khi tải vƣợt quá 175 ngƣời sử dụng đồng thời, hệ số sử dụng CPU không tăng và bắt đầu thăng giáng mạnh, chứng tỏ có một thành phần khác của hệ thống bị quá tải, bắt đầu tắc nghẽn, trở thành “nút cổ chai” của hệ thống, làm cho tải đặt lên CPU có lúc giảm nhiều.
3/ Khi tải vƣợt quá 275 ngƣời sử dụng đồng thời, hệ số sử dụng CPU sau thời điểm giảm tải khoảng 2 phút 50 giây, giảm xuống xấp xỉ bằng không. Điều này cho thấy “nút cổ chai” của hệ thống đã tắc hoàn toàn.
Phần nghiên cứu tiếp theo của tôi sẽ chỉ ra đích xác thành phần “nút cổ chai” của hệ thống.
b) Kết quả sử dụng Memory số ngƣời dùng đồng thời khác nhau
(b2)
(b3)
(b4)
(b5)
Hình 4. 11. Sử dụng bộ nhớ trên máy chủ với số ngƣời dùng đồng thời khác nhau Dựa vào Hình 4.11 ta thấy mô hình sử dụng bộ nhớ của hệ thống trên máy chủ Dựa vào Hình 4.11 ta thấy mô hình sử dụng bộ nhớ của hệ thống trên máy chủ trong điều kiện tải 50, 100, 150, 200, 250 ngƣời dùng đồng thời.
Từ các kết quả quan sát trên, tôi có thể rút ra kết luận:
1/ Khi tải (số ngƣời sử dụng đồng thời) tăng dần từ 50 đến 200, mức độ sử dụng bộ nhớ tăng dần.
2/ Khi tải tăng lên đến 250, thì sau 1 phút giam tải, mức độ sử dụng bộ nhớ đạt cực đại và hầu nhƣ không tăng lên nữa, chứng tỏ tài nguyên bộ nhớ đã bị cạn kiệt. 3/ Kết hợp với các kết luận ở trên (mục a) bên trên, tôi có thể kết luận rằng: trong
hệ thống mà tôi khảo sát này, bộ nhớ là thành phần gây nên “nút cổ chai” của hệ thống, nó cần phải đƣợc nâng cấp để nâng cao khả năng chịu tải của hệ thống. Phần nghiên cứu tiếp theo của tôi về tần suất truy cập hệ thống đĩa sẽ chỉ ra rằng: hệ thống đĩa không phải là “nút cổ chai” của hệ thống.
c) Kết quả sử dụng Disk I/O trên máy chủ với ngƣời dùng đồng thời khác nhau
(c1)
(c2)
(c5)
Hình 4. 12. Sử dụng Disk I/O với số ngƣời dùng khác nhau
Dựa vào hình 4.12 chúng ta thấy mô hình sử dụng đĩa để đọc/ghi của hệ thống với điều kiện tải điều kiện tải khác nhau. Trong thời gian tải ổn định số lần truy cập đĩa (number of disk access/sec) sử dụng lớn nhất là 32 lần truy cập đĩa/giây (disks/sec) cho việc đọc ghi, mức giao động trung bình trong khoảng từ 1 đĩa/giây đến 5 đĩa/giây.
4.6 Phân tích đánh giá kết quả mô phỏng
Thông qua việc đánh giá các tham số hiệu năng: Error, Response time, Throughput theo các mức độ tải đƣa vào hệ thống tăng dần, tôi có thể rút ra các kết luận sau:
1/ Có thể xác định miền tải mà hệ thống làm việc ổn định. Trong miền đó khi tải tăng dần lên thì tỉ lệ lỗi hầu nhƣ không tăng và xấp xỉ bằng không; Đồng thời, thời gian phản hồi cũng nhƣ thông lƣợng tăng gần nhƣ tuyến tính theo tải. 2/ Có thể xác định đƣợc mức tải mà hệ thống bắt đầu có dấu hiệu tắc nghẽn, đồng
nghĩa với việc bị quá tải. Đó là giá trị mà nếu tải đƣa vào hệ thống vƣợt qua, tỉ lệ lỗi và thời gian phản hồi sẽ tăng lên nhanh chóng, còn thông lƣợng sẽ giảm đi nhanh chóng.
3/ Giá trị nói trên có thể coi là giới hạn chịu tải của hệ thống. Dựa vào giá trị này, ngƣời quản trị hệ thống có thể đƣa ra khuyến nghị nâng cấp hệ thống khi nhu cầu sử dụng tăng lên.
Thông qua kết quả đo đƣợc tôi thấy: Nguyên nhân dẫn đến sự giảm sút của hiệu năng là bộ nhớ, bộ nhớ là thành phần gây nên “nút cổ chai” của hệ thống nên thời gian xử lý và trả lời của hệ thống còn chậm, làm giảm mức độ hài lòng của ngƣời sử dụng đối với hệ thống. Nhƣ vậy, để cải tiến hiệu năng của hệ thống này bộ nhớ cần phải