Một shop chạy mượt suốt ngày thường vẫn có thể gục ngã đúng phút khai sale. Lý do nằm ở chỗ phần đông cửa hàng được tối ưu cho lưu lượng đều đặn, chứ không phải cho cú dồn vài nghìn người vào cùng một thời điểm. Bài viết này đi qua những nút thắt hay gặp và cách bố trí hạ tầng để cửa hàng đứng vững qua giờ vàng.
Vì sao WooCommerce dễ nghẽn khi lượng truy cập tăng vọt
Khác với một trang giới thiệu tĩnh, mỗi thao tác mua hàng trên WooCommerce đều phải hỏi cơ sở dữ liệu (database — kho dữ liệu) nhiều lần. Một lần xem sản phẩm, thêm vào giỏ, cập nhật số lượng hay bước thanh toán đều sinh ra hàng loạt truy vấn (query — câu hỏi gửi xuống database). Khi traffic cao, đặc biệt là loại traffic giàu thao tác mua như livestream hay flash sale, số truy vấn này nhân lên theo số người và dồn tải vào MySQL.
Điều đáng lưu ý cho shop Việt là các đợt cao điểm hay đến rất gọn và rất gắt: 12 giờ trưa ngày đôi (9/9, 10/10, 11/11), khung livestream chốt đơn buổi tối, hay mã giảm giá hết hạn trong 60 phút. Lưu lượng không trải đều mà co cụm vào vài chục phút. Nếu hạ tầng chỉ đủ cho ngày thường, đúng lúc cần nhất lại là lúc trang treo.
Bốn nút thắt thường gặp nhất
1. Giỏ hàng và thanh toán không cache được
Cache trang (page cache — lưu sẵn bản trang để trả nhanh) chỉ giúp được phần nội dung giống nhau cho mọi người: trang chủ, trang danh mục, trang sản phẩm. Nhưng giỏ hàng và thanh toán là nội dung riêng từng người, không thể đem bản chung trả cho tất cả. Đây là phần luôn chạy động, và cũng là phần nặng nhất đúng lúc đông khách.
2. Cơ sở dữ liệu quá tải
Khi nhiều người cùng thêm giỏ và đặt đơn, MySQL phải xử lý dồn dập việc đọc lẫn ghi. Theo tài liệu WooCommerce, kho dữ liệu bị nghẽn truy vấn chậm và khóa bảng (table lock — bảng bị giữ chờ) là nguyên nhân hàng đầu khiến thanh toán bị chậm trong các đợt sale.
3. Cấu trúc lưu đơn cũ
WooCommerce trước đây lưu đơn hàng chung bảng với bài viết, nên càng nhiều đơn càng nặng. Nay đã có HPOS (High-Performance Order Storage — kho lưu đơn hiệu năng cao) dùng bảng riêng cho đơn hàng. Theo WooCommerce, HPOS giúp tạo đơn nhanh hơn nhiều và lọc đơn ở trang quản trị nhanh hẳn với shop có hàng chục nghìn đơn.
4. Hạ tầng dùng chung quá yếu
Gói hosting chia sẻ (shared hosting — máy chủ dùng chung nhiều site) thường giới hạn số tiến trình PHP và kết nối database. Đủ cho ngày thường, nhưng vài trăm người đồng thời là chạm trần, request mới phải xếp hàng và khách thấy trang quay vòng.
Bố trí cache đúng lớp
Nguyên tắc cốt lõi là tách phần tĩnh khỏi phần động. Phần ai cũng thấy giống nhau thì cache thật mạnh để không chạm database; phần riêng từng người thì để chạy động nhưng giảm tải bằng object cache.
- Page cache cho trang chủ, danh mục, sản phẩm. Plugin cache (như WP Rocket, LiteSpeed Cache) cần được cấu hình loại trừ giỏ hàng, thanh toán và trang tài khoản để không bao giờ trả nhầm thông tin người này cho người khác.
- Object cache bằng Redis hoặc Memcached cho phần động. Đây là kho đệm trong bộ nhớ giữ lại kết quả truy vấn hay lặp, nhờ đó giỏ hàng, phiên đăng nhập và bước thanh toán không phải hỏi lại MySQL mỗi lần. Theo nhiều nguồn vận hành, object cache có thể cắt giảm đáng kể số lần chạm database trên site động như WooCommerce.
- CDN (mạng phân phối nội dung) để phục vụ ảnh, CSS, JavaScript từ máy chủ gần khách, giảm tải cho máy chủ gốc.
Một điểm hay bị bỏ sót: chỉ bật Redis lên thôi chưa đủ. Cần cài plugin kết nối (như Redis Object Cache) và kiểm tra object cache thực sự hoạt động, đồng thời đặt chính sách dọn bộ nhớ hợp lý để dữ liệu nóng được giữ lại khi bộ nhớ đầy. Nếu cần đi sâu phần này, bài về dùng Redis làm object cache cho WooCommerce sẽ hữu ích.
Hạ tầng đủ mạnh và việc tách dịch vụ
Cache giải quyết được phần lớn áp lực, nhưng giỏ hàng và thanh toán thì luôn cần máy chủ thật xử lý. Vì vậy hạ tầng vẫn phải đủ khoẻ cho phần động.
Với shop dự kiến có đợt cao điểm lớn, nên cân nhắc tách các thành phần ra thay vì gói chung một máy:
- Tách database sang máy chủ riêng để truy vấn nặng lúc sale không tranh tài nguyên với PHP. Cách bố trí này được trình bày kỹ trong bài tách database riêng cho shop WooCommerce.
- Object cache riêng trên một dịch vụ Redis độc lập để dữ liệu phiên không mất khi máy web khởi động lại.
- Tài nguyên co giãn: chọn gói hosting hoặc máy chủ đám mây cho phép tăng RAM, CPU tạm thời quanh ngày sale rồi hạ lại, thay vì trả tiền cấu hình lớn quanh năm.
Bật HPOS cũng là một bước nên làm trước mùa cao điểm, vì nó giảm hẳn gánh nặng ghi đơn khi nhiều người chốt cùng lúc. Với shop đã nhiều đơn, việc chuyển đổi nên chạy qua dòng lệnh WP-CLI thay vì bộ lập lịch trên trình duyệt để tránh hết thời gian chờ.
Chuẩn bị trước đợt cao điểm
Ngày sale không phải lúc để thử nghiệm. Mọi thay đổi hạ tầng nên xong sớm và được kiểm tra trước. Một quy trình gọn:
- Kiểm thử tải (load test — mô phỏng đông người truy cập) trước vài ngày để biết ngưỡng chịu được bao nhiêu người đồng thời, từ đó nâng cấp nếu thiếu.
- Rà cấu hình cache: chắc chắn page cache loại trừ đúng các trang động, object cache đang chạy, CDN đã bật.
- Dọn database: xoá dữ liệu tạm cũ, tối ưu bảng, để MySQL nhẹ trước giờ G.
- Theo dõi thời gian thực trong lúc sale: quan sát truy vấn chậm, số kết nối, khóa bảng để xử lý kịp nếu có dấu hiệu nghẽn.
- Có phương án lui: giữ bản sao lưu mới nhất và biết cách tắt nhanh một tính năng nặng (ví dụ bộ lọc sản phẩm phức tạp) nếu nó thành điểm nghẽn.
Tốc độ tổng thể cũng góp phần quan trọng, vì trang càng nhẹ thì càng chịu được nhiều người. Các đòn bẩy nền tảng được gom lại trong bài tối ưu tốc độ cho WooCommerce.
Câu hỏi thường gặp
Bao nhiêu người truy cập cùng lúc thì gọi là traffic cao?
Không có con số cố định cho mọi shop, vì nó phụ thuộc vào sức máy chủ và độ nặng của thao tác. Điều quan trọng hơn là loại traffic: vài trăm người chỉ xem trang nhẹ hơn nhiều so với vài trăm người cùng thêm giỏ và thanh toán. Cách biết chắc ngưỡng của shop là chạy kiểm thử tải trước.
Bật Redis là đủ để shop chịu được sale lớn chưa?
Redis giúp giảm tải database rất nhiều nhưng không phải toàn bộ câu chuyện. Giỏ hàng và thanh toán vẫn cần máy chủ và database đủ mạnh, page cache phải cấu hình đúng, và hạ tầng cần co giãn được. Redis là một mảnh quan trọng trong bức tranh, không phải lời giải duy nhất.
Có nên tách database ngay từ đầu không?
Với shop nhỏ và đợt cao điểm vừa phải thì chưa cần. Việc tách database hợp lý hơn khi lưu lượng đỉnh lớn và database đang là điểm nghẽn rõ ràng. Nên đo trước rồi mới quyết định, tránh dựng hạ tầng phức tạp khi chưa thực sự cần.
Nếu cần một đội rà soát hạ tầng và chuẩn bị shop cho mùa cao điểm, bạn có thể tham khảo dịch vụ dựng và tối ưu shop WooCommerce của Web22.