Quy trình kiểm thử chịu tải (Load Testing và Stress Testing) hạ tầng website trước các chiến dịch mở bán Mega Sale

1. Phân biệt Load Testing, Stress Testing, Spike Testing và Soak Testing trong thương mại điện tử

Trong kỹ thuật kiểm thử hiệu năng hệ thống giao dịch, mỗi phương pháp kiểm thử trả lời một câu hỏi vận hành khác nhau. Kiểm thử tải mục tiêu (Load Testing) đánh giá xem hạ tầng có duy trì được thời gian phản hồi mục tiêu khi lưu lượng đạt mức kỳ vọng của chiến dịch hay không (ví dụ 5.000 người dùng hoạt động đồng thời và 200 đơn hàng khởi tạo mỗi giây). Trong khi đó, kiểm thử giới hạn chịu đựng (Stress Testing) chủ động đẩy lưu lượng vượt xa mức thiết kế cho đến khi hệ thống bắt đầu phát sinh lỗi để xác định chính xác thành phần nào sẽ gãy đầu tiên (CPU máy chủ ứng dụng, bộ nhớ Redis hay đĩa I/O của cơ sở dữ liệu) và kiểm tra khả năng tự phục hồi khi lưu lượng giảm xuống.

Đặc thù nổi bật của các chương trình mở bán Flash Sale đúng 00:00 hoặc tung mã giảm giá trên sóng phát trực tiếp (Livestream) là lưu lượng không tăng từ từ trong 30 phút mà nhảy vọt từ mức nền vài trăm người lên hàng chục nghìn người chỉ trong vòng 3 đến 5 giây. Để mô phỏng hiện tượng này, đội ngũ kỹ thuật phải thực hiện kiểm thử xung kích (Spike Testing). Nếu bộ tự động mở rộng máy chủ (Auto-scaling Group) cần tới 3 phút để khởi động xong một nút máy chủ mới, thì ở giây thứ 10 của đợt Spike, các máy chủ hiện hữu đã bị đánh sập hoàn toàn trước khi máy chủ mới kịp tham gia nhận tải.

Ngoài ra, với các chiến dịch kéo dài liên tục từ 24 đến 72 giờ, hệ thống còn cần trải qua kiểm thử độ bền (Soak / Endurance Testing). Nhiều lỗi kỹ thuật tinh vi như rò rỉ bộ nhớ (Memory Leak), không giải phóng kết nối cơ sở dữ liệu sau khi gặp ngoại lệ hoặc đầy phân vùng ổ cứng ghi nhật ký (Disk Full do Access Log) thường không bộc lộ trong bài kiểm thử ngắn 15 phút mà chỉ làm sập hệ thống sau 8 đến 12 giờ chạy liên tục ở mức tải trung bình cao.

Vuốt ngang để xem đủ bảng →

3. Phân tích chỉ số phân vị (p95, p99) và xử lý các điểm nghẽn cổ chai điển hình

Khi đọc báo cáo kết quả kiểm thử chịu tải, quản trị viên không nên đánh giá dựa trên chỉ số thời gian phản hồi trung bình (Average Response Time). Ví dụ, nếu 90% yêu cầu trang danh mục được phục vụ từ bộ nhớ đệm trong 20ms, nhưng 10% yêu cầu thanh toán giỏ hàng mất tới 8.000ms mới xong, thì con số trung bình cộng vẫn chỉ khoảng 818ms — trông có vẻ chấp nhận được nhưng thực tế toàn bộ khách hàng ở bước trả tiền đang bị treo màn hình. Do đó, thước đo bắt buộc phải sử dụng là độ trễ ở phân vị thứ 95 (p95) và phân vị thứ 99 (p99), đặc biệt tách riêng cho nhóm API giỏ hàng và thanh toán.

Qua quá trình thực hiện kiểm thử chịu tải trên nhiều dự án thương mại điện tử, Uptech ghi nhận ba điểm nghẽn cổ chai xuất hiện thường xuyên ở tầng máy chủ: một là hiện tượng truy vấn N+1 khi tải danh sách sản phẩm kèm biến thể và chương trình khuyến mãi; hai là việc tính toán lại toàn bộ điều kiện giỏ hàng đồng bộ trong cùng một giao dịch cơ sở dữ liệu kéo dài; và ba là cấu hình số lượng kết nối tối đa (Connection Pool) giữa máy chủ ứng dụng và cơ sở dữ liệu chưa đồng bộ khiến các kết nối chờ nhau gây hiệu ứng dây chuyền.

• Tối ưu hóa tầng Cơ sở dữ liệu: Bổ sung các chỉ mục ghép (Composite Indexes) cho các cột lọc trạng thái đơn hàng và sản phẩm; tách luồng đọc báo cáo/danh mục sang máy chủ bản sao (Read Replica) để dành toàn bộ tài nguyên máy chủ chính (Primary DB) cho luồng ghi đơn hàng.
• Tách luồng xử lý bất đồng bộ (Asynchronous Offloading): Khi khách hàng bấm đặt hàng, API chỉ thực hiện kiểm tra tồn kho trên bộ nhớ đệm và ghi nhận đơn hàng cốt lõi để phản hồi ngay trong dưới 200ms; các tác vụ gửi email xác nhận, xuất hóa đơn, đồng bộ ERP và cộng điểm thành viên được đẩy toàn bộ sang hàng đợi chạy ngầm.
• Làm ấm bộ nhớ đệm trước giờ G (Cache Pre-warming): Chạy kịch bản tự động nạp trước toàn bộ dữ liệu trang đích chiến dịch, danh sách sản phẩm Flash Sale và quy tắc khuyến mãi vào Redis và CDN trước thời điểm mở bán 30 phút để tránh hiện tượng Cold Cache Stampede.