Website chậm khi traffic tăng: Cách kiểm tra hosting có quá tải không

Website vẫn chạy bình thường khi ít người truy cập nhưng chậm rõ rệt vào giờ cao điểm. Một số trang trả lỗi 503 hoặc 508. Trang bài viết có thể mở nhanh, trong khi tìm kiếm, biểu mẫu hoặc checkout mất nhiều thời gian.

Đừng vội kết luận gói hosting quá yếu từ đó nâng cấp gói nhưng vẫn không giải quyết được vấn đề. Cùng một triệu chứng có thể xuất phát từ cache chưa hoạt động, bot crawl dồn dập, plugin tạo query chậm, tác vụ backup chạy sai giờ hoặc tài nguyên hosting đã chạm giới hạn.

Cách xử lý hợp lý là lấy dữ liệu đúng thời điểm, khoanh vùng request gây chậm rồi mới quyết định tối ưu hay nâng hạ tầng.

Kiểm tra nhanh trong 15 phút khi website đang chậm

Mục tiêu của bước này không phải tìm ra toàn bộ nguyên nhân. Bạn cần đủ bằng chứng để biết vấn đề nằm ở frontend, request động, bot hay giới hạn tài nguyên.

1. Ghi lại thời điểm và URL bị chậm

Hãy ghi giờ bắt đầu, giờ kết thúc và múi giờ. Liệt kê chính xác URL hoặc chức năng gặp vấn đề, chẳng hạn:

• Trang bài viết hoặc trang giới thiệu.
• Tìm kiếm và bộ lọc sản phẩm.
• Đăng nhập, giỏ hàng hoặc checkout.
• Biểu mẫu liên hệ.
• Trang tải tệp.

Nếu chỉ nói “website chậm”, bộ phận kỹ thuật phải kiểm tra toàn bộ hệ thống. Một URL và khung giờ cụ thể giúp đối chiếu log, query và biểu đồ tài nguyên nhanh hơn.

2. Mở Resource Usage đúng khung giờ

Nếu hosting dùng cPanel và CloudLinux, mở Metrics → Resource Usage rồi xem biểu đồ trong thời gian xảy ra sự cố. Tập trung vào:

• CPU và physical memory.
• Disk I/O và IOPS.
• Entry Processes và NPROC.
• Faults xuất hiện lặp lại.

AZDIGI đã có hướng dẫn theo dõi Resource Usage trên cPanel. Ảnh chụp sau sự cố vài giờ thường ít giá trị hơn biểu đồ đúng thời điểm.

3. So sánh trang cache với trang động

Mở một bài viết công khai đã cache và một chức năng động như tìm kiếm, đăng nhập hoặc checkout.

• Nếu cả hai đều chậm, cần xem tài nguyên tổng thể, mạng, DNS, bot và web server.
• Nếu trang cache nhanh nhưng trang động chậm, hãy ưu tiên PHP workers, database query, session và API ngoài.
• Nếu lần đầu chậm nhưng tải lại nhanh, kiểm tra cache miss, cache vừa bị purge hoặc quá trình tạo cache.

4. Kiểm tra mã lỗi và access log

Ghi lại mã HTTP thay vì chỉ chụp màn hình trình duyệt. Lỗi 503 và 508 cung cấp manh mối khác với 404, 429 hoặc timeout.

Trong access log, tìm:

• URL được gọi nhiều nhất.
• IP và user agent tạo nhiều request.
• Bot truy cập tìm kiếm, bộ lọc hoặc URL có query string.
• Tỷ lệ lỗi 4xx và 5xx tăng vào thời điểm nào.

5. Ghi lại thay đổi gần nhất

Plugin vừa cập nhật, chiến dịch quảng cáo, email marketing, import dữ liệu, backup và cron đều có thể thay đổi workload. Ghi lại thay đổi trước khi sự cố xuất hiện để tránh nâng gói trong khi nguyên nhân là một tác vụ bất thường.

Bảng chẩn đoán theo triệu chứng

Bảng trên giúp khoanh vùng, không thay thế việc đọc log hoặc kiểm tra ứng dụng. Một mã lỗi có thể có nhiều nguyên nhân.

Số người online nói gì và không nói gì?

Concurrent users, thường viết tắt là CCU, là số người đang hoạt động trong cùng một khoảng thời gian. Con số này hữu ích để biết mức độ đồng thời, nhưng không cho biết mỗi người đang tạo bao nhiêu công việc cho hosting.

Một người đọc bài trong vài phút có thể không gửi thêm request động. Một người tìm kiếm, lọc sản phẩm và checkout có thể tạo nhiều request PHP, session và database query. Bot thường gửi request liên tục, không có khoảng nghỉ như người thật.

Concurrent users khác sessions và traffic tháng

Monthly visitors hoặc sessions cho biết quy mô tổng thể, nhưng có thể che mất giờ cao điểm. Một website có traffic tháng thấp vẫn có thể chịu áp lực lớn nếu phần lớn truy cập dồn vào một khung giờ sau khi gửi email hoặc mở bán.

Theo tài liệu GA4, session mặc định kết thúc sau 30 phút không hoạt động. Một session có thể vẫn tồn tại trong lúc người dùng đang đọc và không tạo thêm request đến PHP.

Concurrent users khác requests per second

Requests per second, viết tắt RPS, là số request hệ thống nhận trong một giây. Một lần mở trang có thể kéo theo HTML, CSS, JavaScript, hình ảnh, font và API.

Nhiều file tĩnh có thể được trình duyệt hoặc CDN phục vụ. HTML lấy từ full-page cache cũng khác hẳn request phải chạy WordPress và database. Vì vậy, không thể đổi một số người online thành RPS hoặc số PHP workers bằng tỷ lệ cố định.

Cache, PHP workers và database tạo hàng đợi thế nào?

Full-page cache giảm request động

WordPress thường tạo trang bằng PHP và database. Full-page cache lưu kết quả thành HTML để phục vụ lại mà không chạy toàn bộ luồng xử lý.

Với nội dung công khai, tỷ lệ cache hit cao có thể giảm đáng kể công việc của PHP và database. Tuy nhiên, tài liệu LiteSpeed cho biết My Account, Checkout và Cart của WooCommerce mặc định bị loại khỏi public cache. Các trang này vẫn cần xử lý riêng theo người dùng.

PHP workers quyết định tốc độ xử lý request động

PHP worker xử lý request PHP. Worker được giải phóng nhanh khi code và database phản hồi nhanh. Nếu plugin, query hoặc API giữ request trong vài giây, worker bận lâu hơn và request mới phải xếp hàng.

Số người online không bằng số PHP workers cần thiết. Mối quan hệ phụ thuộc tỷ lệ cache, số hành động mỗi người, thời gian xử lý request, bot và tác vụ nền.

Redis giảm query lặp lại, không thay thế page cache

WordPress Object Cache lưu dữ liệu thường dùng để giảm số lần truy cập database. Persistent object cache như Redis giữ dữ liệu qua nhiều page load.

Redis hữu ích khi ứng dụng lặp lại cùng một truy vấn. Redis không biến checkout thành trang tĩnh, không sửa query thiếu index và không giải quyết plugin chạy tác vụ nặng.

Đọc Resource Usage để biết tài nguyên nào chạm trần

CloudLinux dùng LVE để giới hạn tài nguyên từng tài khoản hosting. Tài liệu CloudLinux mô tả các giới hạn CPU, physical memory, I/O, IOPS, NPROC và Entry Processes.

Một đỉnh ngắn chưa đủ để kết luận gói hosting quá nhỏ. Fault lặp lại, trùng với URL chậm và traffic hợp lệ mới là bằng chứng mạnh hơn.

Ca giả định: bài viết nhanh nhưng checkout chậm

Một cửa hàng WooCommerce nhận phản ánh rằng bài viết và trang sản phẩm vẫn mở nhanh, nhưng checkout chậm vào buổi tối.

Dữ liệu thu thập

• Trang bài viết có cache hit và TTFB ổn định.
• Checkout không dùng public cache vì có session riêng.
• Entry Processes tăng trong cùng khung giờ.
• Một số request checkout có thời gian xử lý dài.
• Access log không ghi nhận bot spike bất thường.

Cách suy luận

Vấn đề không nằm ở băng thông hoặc file tĩnh. Nút thắt nằm trong luồng động: PHP workers, database query, session hoặc API thanh toán.

Thứ tự xử lý

1. Kiểm tra query và plugin chạy trong checkout.
2. Đo thời gian gọi API thanh toán, vận chuyển và tồn kho.
3. Chuyển cron, backup hoặc đồng bộ khỏi giờ cao điểm.
4. Test lại workload checkout trên staging.
5. Nếu request đã được tối ưu nhưng EP, CPU hoặc memory vẫn fault dưới traffic hợp lệ, mới đối chiếu phương án nâng tài nguyên.

Ca này không phải benchmark và không khẳng định một gói chịu được số người online cụ thể. Nó minh họa cách đi từ triệu chứng đến quyết định.

Khi nào nên tối ưu, khi nào nên nâng hạ tầng?

Không có sản phẩm nào đồng nghĩa với cam kết chịu được một số người online cố định. Nếu code, query hoặc bot là nguyên nhân, chuyển sang VPS mà không tối ưu vẫn có thể chậm.

Kiểm tra trước chiến dịch traffic

Nếu sắp chạy quảng cáo, email, livestream hoặc mở bán, hãy load test theo workload thật thay vì chỉ tăng số người dùng ảo.

1. Liệt kê luồng chính: đọc bài, tìm kiếm, xem sản phẩm, thêm giỏ hàng, checkout thử hoặc tải tệp.
2. Test trên staging hoặc theo phạm vi được nhà cung cấp cho phép.
3. Tách cache ấm và cache lạnh.
4. Tăng tải theo từng bậc, không dồn tải lớn ngay từ đầu.
5. Theo dõi p95 response time, error rate, RPS, CPU, RAM, I/O, EP và database.
6. Đặt tiêu chí dừng khi lỗi tăng hoặc response time vượt ngưỡng vận hành của website.
7. Không tạo đơn hàng, gửi email hoặc gọi dịch vụ tính phí thật trong bài test.

Tài liệu k6 phân biệt mô hình closed VU và open arrival rate. Chọn mô hình theo mục tiêu kiểm thử, không coi số virtual users là bản sao trực tiếp của người online trong analytics.

Mẫu dữ liệu gửi bộ phận hỗ trợ

Bạn có thể sao chép mẫu dưới đây khi gửi ticket:

Loại website:
Thời điểm xảy ra sự cố và múi giờ:
URL hoặc chức năng bị chậm:
Mã lỗi HTTP:
Traffic và concurrent users trong khung giờ:
Ảnh Resource Usage đúng thời điểm:
CPU / RAM / I/O / IOPS / EP / NPROC có fault:
TTFB hoặc response time trước và trong sự cố:
Top URL, IP và user agent trong access log:
Cache hit/miss:
Cron, backup, import hoặc chiến dịch đang chạy:
Thay đổi plugin, theme hoặc mã nguồn gần nhất:

Dữ liệu này giúp bộ phận kỹ thuật phân biệt sự cố ứng dụng với giới hạn tài nguyên nhanh hơn.

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

Website chậm có phải do hosting yếu không?

Chưa chắc. Hosting thiếu tài nguyên là một khả năng. Cache, plugin, database, bot, API ngoài, DNS, mạng và tác vụ nền cũng có thể làm website chậm. Cần đối chiếu triệu chứng với Resource Usage và log.

Lỗi 508 có phải do quá nhiều người truy cập không?

Trên CloudLinux, lỗi 508 thường liên quan việc chạm giới hạn Entry Processes. Traffic người thật có thể là nguyên nhân, nhưng bot, request chậm, plugin, cron và database cũng có thể làm tiến trình tích tụ.

Redis có giúp website chịu tải tốt hơn không?

Redis object cache có thể giảm query lặp lại. Hiệu quả phụ thuộc ứng dụng và tỷ lệ cache hit. Redis không thay thế full-page cache và không sửa truy vấn kém.

Khi nào nên chuyển sang VPS hoặc Cloud?

Khi cần quyền root, phần mềm riêng, cấu hình web server riêng, tài nguyên độc lập hoặc kiến trúc mà hosting managed không hỗ trợ. Nếu nguyên nhân là plugin, query hoặc bot, hãy xử lý chúng trước.

Kết luận

Khi website chậm trong giờ cao điểm, đừng bắt đầu bằng câu hỏi “gói này chịu được bao nhiêu người online”. Hãy bắt đầu bằng thời điểm, URL, Resource Usage, mã lỗi, cache và access log.

Nếu cache chưa hoạt động, bot tạo request bất thường hoặc query xử lý lâu, tối ưu đúng nguyên nhân thường hiệu quả hơn nâng gói. Nếu resource faults vẫn lặp lại dưới traffic hợp lệ sau khi đã tối ưu, lúc đó mới chọn Pro Platinum, Business Hosting, VPS hoặc Cloud theo nhu cầu vận hành.

Nếu cần AZDIGI tư vấn cấu hình, hãy gửi loại website, traffic theo giờ, concurrent users lúc cao điểm, ảnh Resource Usage và luồng tạo tải lớn nhất. Đội ngũ kỹ thuật sẽ dựa trên workload và dữ liệu thực tế để đề xuất hướng xử lý phù hợp.