VPS 4 GB chạy được bao nhiêu website WordPress?

"Server này chứa được bao nhiêu website?" là câu hỏi đầu tiên của mọi công ty hosting, và những câu trả lời quen thuộc ("còn tuỳ", hoặc một con số không kèm phương pháp) chẳng giúp được bao nhiêu khi bạn cần định giá gói dịch vụ. Vì vậy chúng tôi đã đo: trên VPS bình thường, với các bản cài WordPress thật và lưu lượng truy cập mô phỏng thực tế, rồi tiếp tục tăng tải cho tới khi server sụp.

Bài viết này trình bày chúng tôi đã thử những gì, kết quả ra sao và ý nghĩa đối với server của bạn. Tóm gọn: trên VPS 4 GB, page cache tạo ra khác biệt giữa khoảng 100 và khoảng 250 website WordPress.

Kết quả

Server	Không page cache	Có page cache
Ubuntu 24.04, RAM 4 GB, 4 vCPU	100 website WordPress	250 website WordPress
Debian 12, RAM 3 GB	50 website WordPress	200 website WordPress

Ở mọi dòng, server đồng thời chạy thêm 30 ứng dụng khác. Một con số chỉ được tính khi toàn bộ server vẫn chạy mượt: các website WordPress, các ứng dụng, và cả mail, database, panel xung quanh.

Khi chúng tôi cố tình đẩy server quá tải vượt xa các con số này rồi rút tải, server trở lại bình thường trong 2 đến 5 phút.

Phương pháp đo

Số liệu năng lực chỉ có ích khi bạn biết nó được tạo ra như thế nào, vì vậy đây là phương pháp.

Server. Hai VPS cloud phổ thông: Ubuntu 24.04 với RAM 4 GB và 4 vCPU, Debian 12 với RAM 3 GB. Cả hai chạy ZoPanel với cấu hình mặc định tự điều chỉnh theo máy và đầy đủ dịch vụ (web, PHP, MariaDB, PostgreSQL, mail, DNS). Server Debian dùng kernel 6.12 mới hơn từ Debian backports, vì tính năng nén bộ nhớ mô tả bên dưới cần Linux 6.8 trở lên.

Website. Mỗi website WordPress là một bản cài thật, nằm trong tài khoản hosting riêng, có pool PHP và database riêng, được tạo qua panel giống hệt cách khách hàng làm.

30 ứng dụng còn lại. Server hosting hiếm khi chỉ chạy WordPress, nên mỗi bước thử đều kèm 30 ứng dụng: 10 ứng dụng Node.js dùng MariaDB, 5 ứng dụng Python (Flask) dùng PostgreSQL, và 15 ứng dụng PHP (Joomla, phpBB và OpenCart).

Lưu lượng truy cập. Tải được tạo từ một VPS khác bằng bộ sinh tải kiểu open-loop: yêu cầu đến đúng lịch dù server có theo kịp hay không, giống như người truy cập thật. Lưu lượng hosting thực tế rất không đồng đều, nên các website được chia thành ba nhóm:

10% website đông khách, mỗi website 30 lượt tải trang mỗi phút;
30% website ít khách, 1 lượt mỗi phút;
60% website gần như không có khách, 1 lượt mỗi 45 phút.

Tổng cộng khoảng 15 lượt tải trang mỗi giây trên 250 website. Nghe có vẻ khiêm tốn, nhưng lưu lượng này trải trên hàng trăm tài khoản riêng biệt, mỗi tài khoản có pool PHP và database riêng, nặng hơn nhiều so với cùng lưu lượng đổ vào một website duy nhất. Khi tắt page cache, mỗi yêu cầu đều là một lần WordPress dựng trang hoàn chỉnh.

Thế nào là "mượt". Một bước chỉ đạt khi website đông khách trả lời 95% yêu cầu dưới một giây, website ít khách trả lời một nửa số yêu cầu dưới một giây, và tỷ lệ lỗi dưới 0,5%. Chúng tôi tăng số website theo từng bước cho tới khi một bước không đạt, và công bố bước cuối cùng còn đạt.

Vì sao page cache thay đổi tất cả

Không có page cache, mỗi lượt xem trang WordPress đều chạy PHP: nạp WordPress, nạp plugin, truy vấn database và dựng HTML từ đầu. Đó là việc của CPU, và 4 vCPU sẽ nhanh chóng cạn. Trên server Debian không cache, bước sau mốc 50 website bị giới hạn bởi CPU chứ không phải bộ nhớ.

Có page cache, web server giữ bản sao của trang đã dựng xong và trả thẳng cho người truy cập tiếp theo. PHP hoàn toàn không chạy cho những yêu cầu đó. Một trang lấy từ cache tốn chi phí rất nhỏ so với trang dựng mới, nên cùng một CPU phục vụ được nhiều website hơn hẳn. Trên server Ubuntu, các bước có cache tới 250 website vẫn nằm thoải mái trong ngưỡng, và CPU còn xa mới bão hoà.

Hai chi tiết giúp page cache an toàn khi bật mặc định cho shared hosting:

Xoá tức thì. Khi nội dung một website WordPress thay đổi, các trang cache của nó được xoá, nên người truy cập không thấy bài viết cũ.
Làm mới ở chế độ nền. Trang hết hạn được làm mới phía sau trong khi bản cũ vẫn được phục vụ, nên một đợt khách đổ vào trang vừa hết hạn không biến thành một đợt việc dồn cho PHP.

Page cache không giúp được mọi trường hợp. Người dùng đã đăng nhập, giỏ hàng và trang thanh toán phải bỏ qua cache. Một cửa hàng WooCommerce có nhiều khách đăng nhập sẽ giống cột "không page cache" hơn là cột "có page cache".

Bộ nhớ đi đâu

Khi CPU đã được cache gánh, bộ nhớ trở thành giới hạn. Vài trăm website nghĩa là vài trăm pool PHP, và mỗi worker PHP chiếm hàng chục megabyte khi đang chạy. Ba yếu tố giúp bộ nhớ nằm trong tầm kiểm soát trong các bài thử.

Pool PHP biết ngủ. Trong ZoPanel, pool PHP của mỗi tài khoản khởi động khi có yêu cầu đầu tiên và dừng sau một thời gian rảnh. Với kịch bản lưu lượng ở trên, 60% website chỉ có khách mỗi 45 phút, nên phần lớn pool ngủ gần như suốt thời gian và không tốn chút bộ nhớ PHP nào. Mã PHP đã biên dịch được lưu trên đĩa nên việc đánh thức pool rất nhanh.

Nén bộ nhớ thay vì swap. Trên Linux 6.8 trở lên, bộ nhớ rảnh của khách hàng được nén ngay trong RAM thay vì ghi ra đĩa. Swap ra đĩa trên một VPS đang bận chính là thứ biến server chậm thành server không phản hồi; nén bộ nhớ giữ dữ liệu đang dùng trong RAM với kích thước nhỏ hơn nhiều. Các bản build trước của chúng tôi, với giới hạn bộ nhớ cứng và không swap, chứa được ít website có cache hơn trên cùng server 4 GB. Chính nén bộ nhớ đã đưa kết quả có cache lên 250.

Phần dự trữ cố định cho hệ thống. Panel tự cấu hình theo server và giữ một phần bộ nhớ dự trữ cho MariaDB, mail, web server và chính panel, để một đợt tăng tải của khách không làm đói các dịch vụ mà mọi người cùng phụ thuộc. Bạn có thể xem kế hoạch bộ nhớ này trong phần cài đặt của panel.

Chuyện gì xảy ra khi vượt giới hạn

Server nào cũng có điểm gãy. Điều quan trọng là chuyện gì xảy ra khi chạm tới nó, vì sớm hay muộn một đợt tăng lưu lượng, một con bot hay một plugin lỗi cũng sẽ đưa bạn tới đó.

Chúng tôi thử trực tiếp: vài phút tải nặng, không cache, trên hàng trăm website cùng lúc, vượt xa ngưỡng mượt, rồi trở lại lưu lượng bình thường. Một cấu hình đơn giản sẽ không tự hồi phục khi tải dừng. Các pool PHP tiếp tục xử lý những hàng đợi dài toàn là yêu cầu mà người truy cập đã bỏ đi từ lâu, và bộ nhớ vẫn cạn kiệt.

ZoPanel giữ hàng đợi yêu cầu PHP ngắn, để quá tải được xử lý nhanh thay vì dồn ứ. Khi bộ nhớ của khách thiếu trầm trọng, các yêu cầu đã chờ quá lâu bị huỷ và người truy cập thấy một trang "đang bận" ngắn gọn; lần truy cập tiếp theo diễn ra bình thường. Nhờ vậy, cả hai server thử nghiệm đều trở lại bình thường trong 2 đến 5 phút sau khi hết quá tải.

Vì sao con số của bạn sẽ khác

Hãy coi kết quả này là một mốc tham chiếu có tài liệu rõ ràng, không phải lời hứa. Server của bạn sẽ khác ở những điểm quan trọng:

Plugin và theme. Một page builder nặng hay plugin chạy truy vấn trên mọi trang có thể nhân chi phí của trang không cache lên nhiều lần.
Lưu lượng đã đăng nhập. Website thành viên, diễn đàn và cửa hàng bỏ qua page cache với nhiều người dùng.
Hình dạng lưu lượng. Kịch bản của chúng tôi có 10% website đông khách. Nếu một phần tư khách hàng của bạn chạy quảng cáo cùng lúc, hãy dự tính ít website hơn.
Bot. Các crawler hung hăng có thể gọi URL không cache (trang tìm kiếm, bộ lọc) suốt cả ngày.
Bản thân VPS. "4 vCPU" của nhà cung cấp này không giống của nhà cung cấp khác, và tốc độ đĩa chênh lệch rất lớn.
Phiên bản kernel. Không có Linux 6.8 trở lên thì không có nén bộ nhớ, và con số có cache sẽ thấp hơn.

Lời khuyên thực tế

Bật page cache cho mọi website WordPress dùng được. Đây là yếu tố lớn nhất. Sau khi cài website, hãy kiểm tra xem trang cache có thực sự được phục vụ hay không.
Dùng kernel mới. Ubuntu 24.04 có sẵn. Với Debian 12, cân nhắc kernel backports và lưu ý rằng nó nằm ngoài phạm vi hỗ trợ bảo mật chính của Debian; Debian 13 là lựa chọn đơn giản hơn cho server mới.
Để server chạy tác vụ định kỳ của WordPress. wp-cron chạy theo lượt truy cập làm nặng thêm mỗi lượt xem và không chạy đúng giờ trên website ít khách. ZoPanel chuyển nó sang bộ hẹn giờ của server cho các bản cài mới.
Chừa khoảng trống. Đừng bán tới đúng con số mà server vừa vượt qua. Đợt tăng tải, backup và cập nhật đều cần chỗ.
Theo dõi đúng chỉ số. Lịch sử tài nguyên theo từng tài khoản cho thấy khách nào đang tăng trưởng; thời gian phản hồi ở phân vị 95 nói nhiều hơn giá trị trung bình.
Tách cửa hàng nặng sang gói hoặc server riêng. Một cửa hàng WooCommerce đông khách có thể tiêu tốn tài nguyên bằng hàng chục website giới thiệu doanh nghiệp.
Đo chính khối lượng công việc của bạn. Gói Free chạy 10 website và 10 database với đầy đủ tính năng, đủ để đo một website điển hình của khách hàng trước khi bạn chốt mật độ.

Kết luận

VPS 4 GB là một server hosting có năng lực. Không có page cache, hãy dự tính vài chục tới khoảng một trăm website WordPress; có page cache, kernel mới và PHP biết ngủ khi rảnh, vài trăm website là con số thực tế, kèm theo các ứng dụng khác. Dù bạn chọn mật độ nào, hãy chắc chắn server tự hồi phục được khi bạn tính sai.

Để thiết lập trên server của bạn, xem hiệu năng PHP và WordPress, yêu cầu hệ thống và hướng dẫn WordPress. Về cache, tài liệu chính thức của WordPress là điểm khởi đầu tốt.

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