Tổng quan nghiên cứu

Theo thống kê, Apache Web Server hiện chiếm hơn 60% thị trường web toàn cầu, phản ánh mức độ phụ thuộc ngày càng sâu của doanh nghiệp vào các hệ thống thông tin dựa trên dịch vụ web. Trong bối cảnh toàn cầu hóa kinh tế, các mô hình kinh doanh B2B và B2C đòi hỏi hệ thống thông tin phải đáp ứng truy cập mọi lúc, mọi nơi theo thời gian thực — điều mà các hệ thống khép kín truyền thống hay giải pháp VPN chi phí cao không thể đáp ứng linh hoạt.

Luận văn thạc sĩ "Nghiên cứu tính khả dụng của các hệ thống thông tin doanh nghiệp dựa trên dịch vụ web" của tác giả Triệu Quang Chính (Trường Đại học Công nghệ — ĐHQGHN, 2017, dưới sự hướng dẫn của PGS. Nguyễn Đình Việt) tập trung giải quyết bài toán cấp thiết: làm thế nào đánh giá chính xác tính khả dụng của hệ thống thông tin web thông qua các chỉ số định lượng về thời gian đáp ứng, tài nguyên hệ thống và tỉ lệ lỗi?

Thực tế cho thấy hậu quả của việc bỏ qua kiểm thử hiệu năng rất nghiêm trọng. Ngày 15/01/2016, trang web đặt vé xe Tết của Công ty Phương Trang liên tục quá tải từ 7 giờ đến hơn 10 giờ 30, khiến hàng nghìn hành khách không mua được vé, gây thiệt hại lớn về doanh thu lẫn uy tín. Tương tự, trang Interpark (Hàn Quốc) dù đã bổ sung thêm 30 máy chủ vẫn bị sập trong khoảng 45 phút khi mở bán vé fanmeeting Wanna One (tháng 10/2017).

Nghiên cứu sử dụng công cụ JMeter để mô phỏng người dùng đồng thời truy cập vào trang web bán mỹ phẩm trực tuyến, với yêu cầu kỹ thuật đặt ra là phục vụ trên 500 người dùng đồng thời, thời gian đáp ứng đạt mức hài lòng dưới 5 giây và mức chấp nhận được không quá 10 giây. Kết quả nghiên cứu cung cấp cơ sở dữ liệu định lượng để các doanh nghiệp lên kế hoạch nâng cấp hạ tầng công nghệ thông tin một cách hiệu quả và tiết kiệm chi phí.

Cơ sở lý thuyết và phương pháp nghiên cứu

Khung lý thuyết áp dụng

Luận văn xây dựng trên hai trụ cột lý thuyết chính.

Lý thuyết đánh giá hiệu năng hệ thống (Performance Evaluation Theory): Hiệu năng được xác định bởi sự kết hợp của ba nhân tố: tính sẵn sàng (availability), thông lượng (throughput) và thời gian đáp ứng (response time). Đánh giá hiệu năng là hoạt động điều tra, phân tích số liệu đo lường phức tạp nhằm đánh giá mức khả năng chịu đựng tài nguyên hệ thống dưới lượng tải công việc xác định. Khung lý thuyết này được hiện thực hóa qua bảy hoạt động kiểm thử tuần tự: xác định môi trường kiểm thử, xác định tiêu chí hiệu năng chấp nhận được, lập kế hoạch và thiết kế trường hợp kiểm thử, cấu hình môi trường, triển khai thiết kế, thực thi kiểm thử và phân tích — báo cáo — kiểm tra lại.

Lý thuyết kiến trúc hệ thống thông tin web (Web-Based Information System Architecture): Hệ thống thông tin dựa trên web (WBIS) vận hành theo mô hình Client–Server đa tầng, trong đó mô hình "N-tầng" là chuẩn hiện đại thay thế cho kiến trúc hai tầng bảo mật thấp và khả năng mở rộng kém. Tài nguyên hệ thống bao gồm phần cứng, phần mềm, tài nguyên mạng, tài nguyên dữ liệu và nhân lực — tất cả đều là biến số ảnh hưởng trực tiếp đến tính khả dụng.

Các khái niệm chuyên ngành cốt lõi gồm: thông lượng (throughput — tổng dữ liệu truyền từ máy chủ tới máy khách trên một đơn vị thời gian), thời gian đáp ứng (response time — từ khi gửi yêu cầu đến khi nhận byte đầu tiên), tỉ lệ lỗi (error rate — tỉ lệ giao dịch thất bại/tổng giao dịch), nút cổ chai (bottleneck — thành phần tài nguyên gây suy giảm hiệu năng toàn hệ thống), và tải công việc (workload — số lượng và bản chất các yêu cầu gửi đến hệ thống trong một đơn vị thời gian).

Phương pháp nghiên cứu

Nguồn dữ liệu và cỡ mẫu: Nghiên cứu sử dụng tải nhân tạo (artificial workload) do phần mềm JMeter tạo ra. Cỡ mẫu được thiết kế theo nguyên tắc tăng dần: mỗi lần tăng 25 người dùng ảo đồng thời, bắt đầu từ 1 người cho đến khi hệ thống không còn đáp ứng được. Hai kịch bản kiểm thử song song được thực hiện: Kịch bản 1 mô phỏng người dùng truy cập qua trình duyệt Firefox trên máy tính để bàn; Kịch bản 2 mô phỏng người dùng truy cập qua trình duyệt Safari trên iPhone.

Phương pháp chọn mẫu: Chọn mẫu có chủ đích (purposive sampling) dựa trên kịch bản người dùng thực tế — người dùng truy cập trang chủ, chọn sản phẩm, thêm vào giỏ hàng, khai báo địa chỉ và hoàn tất đặt hàng — nhằm tái tạo hành vi thực tế gần nhất.

Môi trường kiểm thử: Máy chủ sử dụng CPU Intel Xeon E5-2660 (8 nhân, tốc độ 2,2 GHz), RAM DDR 4GB, HDD 30GB, hệ điều hành Windows Server 2012. Máy khách dùng CPU Intel Core i7-4870 (7 nhân, 2,5 GHz), RAM 16GB, HDD 256GB, Windows 10 Enterprise 64-bit. Đường truyền máy khách đạt tốc độ upload tối đa 8 Mbps và download 12 Mbps (VNPT), trong khi máy chủ tại Mỹ có upload tối đa 86 Mbps và download 866 Mbps.

Phương pháp phân tích: JMeter được tích hợp với gói plugin mở rộng JmeterPlugins-Standard để thu thập và trực quan hóa dữ liệu đa chiều gồm: biểu đồ thời gian đáp ứng theo tải, biểu đồ tỉ lệ lỗi, thông lượng request, mức sử dụng CPU, mức sử dụng RAM và chỉ số Disk I/O. Phương pháp phân tích tải nhân tạo được chọn vì cho phép kiểm soát chính xác điều kiện kiểm thử và tái tạo cả điều kiện tải bất hợp lý — điều không thể thực hiện được với tải tự nhiên.

Tiêu chí kiểm thử cơ sở: Kiểm thử chuẩn (benchmark test) chiếm khoảng 15–20% mức tải mục tiêu, đặt nền tảng so sánh cho các lần kiểm thử tải và kiểm thử áp lực về sau.

Kết quả nghiên cứu và thảo luận

Những phát hiện chính

Phát hiện 1 — Ngưỡng chịu tải và điểm gãy hiệu năng: Hệ thống duy trì thời gian đáp ứng ở mức hài lòng (dưới 5 giây) khi số người dùng đồng thời ở mức thấp. Khi tải tăng vượt ngưỡng, thời gian đáp ứng leo thang đột ngột lên trên 10 giây — vượt mức chấp nhận được — và tỉ lệ lỗi bắt đầu tăng đáng kể. Mối quan hệ này có thể quan sát rõ trên biểu đồ đường (line chart) thể hiện trục X là số người dùng đồng thời và trục Y là thời gian đáp ứng trung bình (giây), cho thấy đường cong tăng phi tuyến tính rõ rệt.

Phát hiện 2 — Tỉ lệ lỗi theo nền tảng truy cập: Kết quả thực nghiệm ghi nhận sự chênh lệch tỉ lệ lỗi giữa hai nền tảng. Trình duyệt Firefox trên máy tính để bàn và trình duyệt Safari trên iPhone cho thấy các đường cong tỉ lệ lỗi khác biệt khi số người dùng đồng thời tăng dần. Biểu đồ cột so sánh (grouped bar chart) theo từng mốc người dùng là công cụ trực quan phù hợp để thể hiện sự chênh lệch này. Điều này chứng tỏ thiết bị và trình duyệt là biến số không thể bỏ qua trong đánh giá tính khả dụng.

Phát hiện 3 — Sử dụng tài nguyên phần cứng và nút cổ chai: Dữ liệu giám sát phía máy chủ cho thấy mức sử dụng CPU và RAM tăng tỉ lệ thuận với số người dùng ảo. Đặc biệt, mối quan hệ giữa số lượng người dùng ảo và hiệu suất trung bình sử dụng RAM thể hiện xu hướng tuyến tính ở tải thấp, sau đó tăng đột biến ở tải cao — dấu hiệu cổ điển của tình trạng memory pressure. Chỉ số Disk I/O cũng tăng theo tải, cho thấy hoạt động đọc/ghi đĩa là một điểm tiềm ẩn gây nghẽn cổ chai thứ cấp.

Phát hiện 4 — Thông lượng và mức trần hệ thống: Thông lượng (KB/giây) tăng theo số người dùng cho đến một ngưỡng nhất định, sau đó đạt trần và không tiếp tục tăng dù tải vẫn tăng — biểu hiện điển hình của tình trạng bão hòa tài nguyên. Biểu đồ kép thể hiện đồng thời đường thông lượng request (requests/giây) và thông lượng dữ liệu (KB/giây) giúp phân biệt rõ ràng giữa khả năng xử lý yêu cầu và khả năng truyền tải dữ liệu của hệ thống.

Thảo luận kết quả

Sự suy giảm hiệu năng phi tuyến tính quan sát được phù hợp với lý thuyết hàng đợi (queuing theory) — khi tài nguyên bão hòa, thời gian chờ tăng theo hàm số mũ chứ không tuyến tính. Đây là nguyên nhân khiến các doanh nghiệp thường đánh giá thấp nhu cầu tài nguyên khi chỉ kiểm thử ở mức tải thấp.

So sánh với sự cố thực tế của Phương Trang và Interpark, kết quả nghiên cứu xác nhận: ngay cả khi bổ sung thêm 30 máy chủ, nếu không kiểm thử đúng phương pháp để xác định ngưỡng thực sự, hệ thống vẫn có thể sụp đổ dưới tải đột biến. Nghiên cứu nhấn mạnh rằng phương pháp tăng tải dần (ramp-up) không chỉ xác định ngưỡng chịu tải mà còn giúp quan sát hiệu ứng "mở ấm" (warm-up effect) của hệ thống — yếu tố thường bị bỏ qua trong kiểm thử đơn giản.

Đề xuất và khuyến nghị

1. Triển khai kiểm thử hiệu năng định kỳ trước các sự kiện lớn: Các doanh nghiệp thương mại điện tử cần thực hiện kiểm thử tải và kiểm thử áp lực ít nhất 4–6 tuần trước các đợt khuyến mại lớn (Tết, Black Friday, giờ vàng flash sale). Bộ phận kỹ thuật chịu trách nhiệm lập kịch bản dựa trên dữ liệu lưu lượng lịch sử, với mục tiêu xác nhận khả năng phục vụ tối thiểu 500 người dùng đồng thời ở mức thời gian đáp ứng dưới 5 giây.

2. Xây dựng quy trình xác định và xử lý nút cổ chai: Sau mỗi chu kỳ kiểm thử, nhóm vận hành cần phân tích đồng thời ba chỉ số: CPU usage (%), RAM usage (%) và Disk I/O — thay vì chỉ theo dõi thời gian đáp ứng. Khi phát hiện tài nguyên nào đạt trên 80% năng lực trong 3 lần đo liên tiếp, cần ưu tiên nâng cấp thành phần đó trước tiên. Mục tiêu là duy trì ngưỡng tài nguyên an toàn dưới 70% trong điều kiện tải bình thường.

3. Chuẩn hóa môi trường kiểm thử đa nền tảng: Kết quả nghiên cứu cho thấy sự khác biệt đáng kể giữa trình duyệt máy tính và trình duyệt di động. Do đó, bộ phận QA cần thiết lập quy trình kiểm thử bắt buộc trên ít nhất hai nền tảng (desktop và mobile) với kịch bản người dùng thực tế. Tỉ lệ người dùng mobile hiện chiếm trên 60% lưu lượng tại nhiều sàn thương mại điện tử Việt Nam, nên ưu tiên tối ưu hóa hiệu năng cho nền tảng này là thiết yếu.

4. Áp dụng kiến trúc N-tầng và cơ chế mở rộng linh hoạt: Các hệ thống vẫn đang vận hành trên kiến trúc hai tầng cần ưu tiên chuyển đổi sang mô hình N-tầng trong vòng 12 tháng tới, với lộ trình: đánh giá hiện trạng (tháng 1–2), thiết kế kiến trúc mới (tháng 3–4), triển khai thử nghiệm (tháng 5–9), kiểm thử toàn diện và đưa vào vận hành (tháng 10–12). Ban lãnh đạo công nghệ thông tin chịu trách nhiệm phê duyệt ngân sách và giám sát tiến độ.

5. Đầu tư vào công cụ giám sát thời gian thực: Song song với kiểm thử định kỳ, doanh nghiệp cần triển khai hệ thống giám sát (monitoring) theo thời gian thực để cảnh báo sớm khi các chỉ số vượt ngưỡng an toàn. Điều này giúp rút ngắn thời gian phản ứng sự cố từ hàng giờ xuống còn vài phút — tương đương với việc giảm thiểu thiệt hại doanh thu và uy tín thương hiệu một cách đáng kể.

Đối tượng nên tham khảo luận văn

1. Kỹ sư và kiểm thử viên phần mềm: Luận văn cung cấp hướng dẫn thực hành chi tiết về việc sử dụng JMeter — từ cấu hình proxy ghi lại kịch bản, thiết lập Thread Group, tích hợp plugin mở rộng đến đọc và phân giải các biểu đồ kết quả. Đây là tài liệu tham khảo kỹ thuật hữu ích cho kỹ sư muốn xây dựng năng lực kiểm thử hiệu năng mà không cần đầu tư vào công cụ thương mại đắt tiền như HP LoadRunner hay IBM Rational Performance Tester.

2. Nhà quản lý công nghệ thông tin và CTO: Phân tích so sánh giữa các công cụ kiểm thử (Apache JMeter, HP LoadRunner, LoadUI, IBM Rational Performance Tester) theo tiêu chí chi phí, giao thức hỗ trợ, hệ điều hành và ngôn ngữ kịch bản giúp lãnh đạo kỹ thuật đưa ra quyết định lựa chọn công cụ phù hợp với ngân sách và yêu cầu dự án. Khung bảy hoạt động kiểm thử hiệu năng cũng là cơ sở để xây dựng quy trình chuẩn (SOP) cho bộ phận vận hành.

3. Chủ doanh nghiệp thương mại điện tử và startup công nghệ: Các case study về sự cố quá tải của Phương Trang và Interpark — được phân tích gắn với nguyên nhân kỹ thuật cụ thể — là bài học thực tiễn có giá trị cao. Luận văn giúp các nhà sáng lập hiểu rõ mối liên hệ trực tiếp giữa tính khả dụng hệ thống và doanh thu, từ đó ưu tiên đầu tư kiểm thử trước khi ra mắt sản phẩm hoặc mở rộng quy mô.

4. Nghiên cứu sinh và giảng viên ngành Công nghệ thông tin: Luận văn hệ thống hóa toàn diện các loại kiểm thử hiệu năng (load test, stress test, endurance test, spike test, volume test, capacity test), định nghĩa rõ ràng từng khái niệm và mối quan hệ giữa chúng. Đây là nguồn tài liệu học thuật tiếng Việt hiếm có, phù hợp làm tài liệu đọc thêm cho các học phần về Kiểm thử phần mềm, Hệ thống thông tin và Quản trị hạ tầng CNTT.

Câu hỏi thường gặp

1. Tính khả dụng (usability/availability) của hệ thống thông tin web là gì và tại sao quan trọng?

Tính khả dụng trong ngữ cảnh luận văn này được hiểu là khả năng hệ thống phục vụ người dùng với nỗ lực tối thiểu trong các điều kiện môi trường, thời điểm và số lượng người dùng khác nhau. Thực tế cho thấy mỗi giây trễ trong tải trang có thể làm giảm tỉ lệ chuyển đổi của trang thương mại điện tử — đồng thời khiến người dùng chuyển sang đối thủ cạnh tranh. Sự cố của Phương Trang (01/2016) minh họa rõ ràng thiệt hại kép: mất doanh thu lẫn uy tín thương hiệu chỉ trong một ngày.

2. Tại sao chọn JMeter thay vì các công cụ thương mại như HP LoadRunner?

JMeter được chọn vì là phần mềm mã nguồn mở, miễn phí, nhẹ (không cần cài đặt, chỉ cần môi trường Java), hỗ trợ đa nền tảng (Windows, Linux, macOS) và có cộng đồng hỗ trợ lớn nhất trong nhóm công cụ kiểm thử miễn phí. Mặc dù HP LoadRunner mạnh hơn về báo cáo và script, chi phí giấy phép cao khiến nó không phù hợp cho doanh nghiệp vừa và nhỏ hoặc nghiên cứu học thuật. JMeter có thể bù đắp hạn chế báo cáo thông qua các plugin miễn phí như JmeterPlugins-Standard.

3. Kiểm thử tải (load test) và kiểm thử áp lực (stress test) khác nhau như thế nào?

Kiểm thử tải kiểm tra hệ thống ở điều kiện tải bình thường hoặc tải tối đa dự kiến, nhằm xác minh hệ thống đáp ứng các mục tiêu hiệu năng đã cam kết (SLA). Kiểm thử áp lực vượt ra ngoài ngưỡng tải bình thường để tìm điểm gãy (breakpoint) của hệ thống. Ví dụ trong luận văn: kiểm thử tải kiểm tra khả năng phục vụ 500 người đồng thời dưới 5 giây, còn kiểm thử áp lực tiếp tục tăng tải vượt 500 người để xác định tại mức nào hệ thống bắt đầu trả về lỗi.

4. Nút cổ chai (bottleneck) là gì và làm thế nào xác định được?

Nút cổ chai là thành phần tài nguyên có công suất thấp nhất trong chuỗi xử lý, giới hạn hiệu năng toàn hệ thống. Xác định nút cổ chai bằng cách theo dõi đồng thời CPU usage, RAM usage và Disk I/O trong quá trình kiểm thử tải. Thành phần nào đạt 100% trước tiên trong khi các thành phần khác vẫn còn dư công suất chính là nút cổ chai. Luận văn sử dụng biểu đồ đa trục từ JMeter để hình dung mối quan hệ giữa tải người dùng và mức sử dụng từng loại tài nguyên theo thời gian thực.

5. Doanh nghiệp nhỏ không có đội ngũ kỹ thuật lớn có áp dụng được phương pháp này không?

Hoàn toàn có thể. JMeter là công cụ miễn phí, giao diện trực quan và có sẵn kho tài liệu hướng dẫn bằng văn bản, hình ảnh và video phong phú từ cộng đồng mã nguồn mở. Một kỹ sư được đào tạo cơ bản có thể thiết lập và chạy kịch bản kiểm thử đơn giản trong vài giờ. Với trang web thương mại điện tử quy mô nhỏ, kiểm thử chuẩn (benchmark test) ở mức 15–20% tải mục tiêu là điểm khởi đầu thực tế và ít tốn nguồn lực nhất.

Kết luận

Luận văn đóng góp vào lĩnh vực kiểm thử và đảm bảo chất lượng hệ thống thông tin web qua các kết quả cốt lõi sau:

  • Hệ thống hóa lý thuyết: Tổng hợp toàn diện các loại kiểm thử hiệu năng, khái niệm và phương pháp đánh giá, xây dựng nền tảng lý thuyết thống nhất bằng tiếng Việt cho lĩnh vực còn thiếu tài liệu học thuật nội địa.
  • Quy trình thực nghiệm có thể tái lặp: Quy trình 6 bước kiểm thử với JMeter, từ ghi lại kịch bản đến phân tích đa chỉ số, có thể áp dụng trực tiếp cho bất kỳ hệ thống web thương mại điện tử nào.
  • Bằng chứng thực tiễn định lượng: Dữ liệu thực nghiệm trên hai nền tảng (máy tính và điện thoại) cung cấp cơ sở so sánh khách quan, chỉ ra sự khác biệt hiệu năng theo nền tảng truy cập.
  • Khung ra quyết định nâng cấp: Kết quả xác định ngưỡng tải và nút cổ chai giúp doanh nghiệp ưu tiên đầu tư nâng cấp đúng thành phần, tránh lãng phí chi phí nâng cấp dàn trải.
  • Cảnh báo rủi ro kinh doanh: Các case study thực tế chứng minh tầm quan trọng của kiểm thử trước khi đưa hệ thống vào vận hành quy mô lớn, đặc biệt trong các sự kiện thương mại có lưu lượng đột biến.

Hướng phát triển tiếp theo bao gồm mở rộng nghiên cứu sang kiến trúc microservices và điện toán đám mây, tích hợp kiểm thử hiệu năng vào quy trình CI/CD tự động, và nghiên cứu tác động của CDN đến thời gian đáp ứng cho người dùng địa lý phân tán. Các nhà nghiên cứu, kỹ sư và doanh nghiệp quan tâm đến nâng cao chất lượng hệ thống web được khuyến khích tiếp cận luận văn như một tài liệu thực hành — kết hợp với việc thử nghiệm trực tiếp JMeter trên hệ thống của mình để có đánh giá chính xác nhất về tính khả dụng trong điều kiện thực tế.