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

Triệu chứng	Dữ liệu cần xem	Khả năng thường gặp	Hành động đầu tiên
TTFB tăng nhưng Resource Usage không có fault	TTFB trang cache và trang động, query time, API latency	Plugin, database hoặc API ngoài xử lý lâu	Khoanh vùng URL động, kiểm tra query và API
CPU hoặc EP fault trùng với bot spike	Access log, user agent, top URL, cache miss	Bot hoặc crawler tạo request dồn dập	Rate limit, chặn URL bất thường, sửa cache key
Trang bài viết nhanh nhưng checkout chậm	PHP workers, query, session, API thanh toán	Workload động, database hoặc dịch vụ ngoài	Tối ưu checkout, query và API trước khi nâng gói
I/O cao đúng lúc backup hoặc import	Lịch cron, backup, import và biểu đồ I/O	Tác vụ nền tranh tài nguyên với traffic thật	Đổi lịch hoặc tách tác vụ nền
Lỗi 508 lặp lại trong giờ cao điểm	Entry Processes, thời gian xử lý request, top URL	Nhiều request động hoặc request xử lý quá lâu	Giảm request động, tối ưu thời gian xử lý, kiểm tra bot
Resource faults lặp lại dưới traffic hợp lệ sau khi đã tối ưu	CPU, RAM, I/O, EP, p95 response time và error rate	Gói hiện tại không còn đủ biên tài nguyên	Đối chiếu phương án nâng hosting hoặc chuyển hạ tầ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.

Workload	Request động	Điểm cần theo dõi
Đọc bài đã full-page cache	Thấp	Cache hit, TTFB và băng thông
Website doanh nghiệp không bật cache	Trung bình	PHP workers, CPU và query time
Tìm kiếm hoặc lọc sản phẩm	Trung bình đến cao	AJAX, database, Redis và I/O
Giỏ hàng và checkout	Cao	PHP workers, session, database lock và API latency
Tải tệp lớn	Có thể thấp ở PHP nhưng cao ở truyền dữ liệu	Băng thông, throughput và I/O
Bot crawl nhanh	Cao và dồn dập	Access log, user agent, RPS và cache miss

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.

Chỉ số	Khi chạm giới hạn thường thấy gì?	Cần kiểm tra thêm
CPU	Website phản hồi chậm, PHP xử lý lâu hơn	Plugin, bot, cron, mã nguồn và query
Physical memory	Tiến trình có thể bị dừng, phát sinh lỗi 500/503	Memory leak, số PHP process và tác vụ nền
I/O và IOPS	Đọc ghi chậm, PHP workers bận lâu hơn	Backup, import, log, session và database
Entry Processes	Request động mới không vào được LVE, có thể trả 508	Request rate, thời gian xử lý và bot
NPROC	Không tạo được thêm process, có thể phát sinh lỗi 500/503	Cron, PHP process và tác vụ bị treo

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?

Tình huống	Hướng xử lý	Lý do
Cache chưa hoạt động trên nội dung có thể cache	Sửa full-page cache và cache key	Nâng gói không loại bỏ request động không cần thiết
CPU hoặc EP tăng do bot, cron hoặc plugin	Kiểm soát bot, đổi lịch cron, tối ưu plugin	Cần xử lý nguồn tạo tải trước
Website WordPress hoặc shop nhỏ vẫn phù hợp shared hosting nhưng cần tài nguyên rõ hơn	Xem Pro Platinum Hosting	Phù hợp khi vẫn muốn môi trường shared hosting được quản lý
Website doanh nghiệp quan trọng, traffic hoặc giao dịch cao hơn và muốn môi trường managed	Xem Business Hosting	Có thể chọn theo CPU, RAM, I/O và workload mà không cần tự quản trị máy chủ
Cần quyền root, phần mềm riêng hoặc cấu hình web server riêng	Xem Pro VPS	Phù hợp khi có người phụ trách vận hành hệ thống
Cần tài nguyên độc lập, HA hoặc kế hoạch mở rộng riêng	Xem Cloud Server	Cần thiết kế và benchmark theo ứng dụ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.