VPS cho WordPress: cấu hình chuẩn theo lượng truy cập

Trả lời nhanh: Bảng chọn nhanh theo lượt xem/ngày (đã có page cache tử tế): dưới 3.000, 1-2 vCPU / 2 GB (blog, site giới thiệu); 3.000-20.000, 4 vCPU / 4 GB (doanh nghiệp, tin tức nhỏ); WooCommerce hoặc 20.000-60.000, 6 vCPU / 6-8 GB, bán hàng ăn tài nguyên gấp bội site tin vì giỏ hàng/checkout không cache được; trên nữa, 8-12 vCPU hoặc tách database. Stack đi kèm quyết định không kém cỡ máy: LiteSpeed + LiteSpeed Cache + PHP 8.x OPcache + MariaDB tuned + ổ NVMe.

"Site WordPress của tôi cần VPS bao nhiêu?", câu hỏi thực dụng nhất và hay được trả lời ẩu nhất (thường là 'cứ lấy gói to cho chắc'). Bài này đưa bảng cỡ theo traffic có giải thích vì sao, đặc cách riêng cho WooCommerce, dấu hiệu nhận biết máy chật thật, và lộ trình nâng không đập đi làm lại.

Vì sao traffic không phải con số duy nhất

Hai site cùng 10.000 lượt xem/ngày có thể cần máy chênh nhau ba lần, vì thứ ăn máy là lượt xem không cache: site tin có 95% lượt ăn page cache (máy chỉ phục vụ file sẵn, gần như miễn phí), site thành viên/bán hàng có 40-60% lượt động (mỗi lượt là PHP + database thật). Nên bảng cỡ nào tử tế cũng phải kèm giả định cache, và việc đầu tiên trước khi nâng máy luôn là kiểm tra cache đã ăn chưa (phép thử tĩnh/động của bài WordPress-chậm). Đừng mua RAM để bù cho cache chưa bật.

Bảng cỡ chi tiết - kèm lý do

• Blog/giới thiệu (<3k lượt/ngày): 1-2 vCPU / 2 GB, cache ăn gần hết, máy chủ yếu chạy MariaDB nhỏ + PHP thưa. Gói NVMe entry là dư; đây chính là đất của bài 'VPS 129k được gì'.
• Doanh nghiệp/tin nhỏ (3-20k): 4 vCPU / 4 GB, đủ PHP worker cho phần động (tìm kiếm, bình luận), MariaDB có buffer pool tử tế, và headroom cho giờ nhọn.
• WooCommerce (mọi cỡ có đơn đều): khởi điểm 6 vCPU / 6-8 GB, mỗi khách trong phiên mua là chuỗi trang động + ghi giỏ + fsync đơn hàng; giờ chiến dịch quảng cáo là bài kiểm tra đồng thời thật sự. Xung cao đặc biệt đáng ở đây: checkout là chuỗi đơn luồng dài (bài single-thread).
• Tin lớn/membership (60k+): 8-12 vCPU / 8-16 GB, cân nhắc Redis object cache, và nước cờ tách database ra máy riêng khi một máy bắt đầu tranh chấp nội bộ.

Stack chuẩn đi kèm - cỡ máy chỉ là một nửa

Cùng cỡ máy, stack quyết định nửa còn lại: LiteSpeed (hoặc OpenLiteSpeed) + LiteSpeed Cache, cặp bài trùng thống trị WordPress hiệu năng cao ở VN, cache ăn tầng server và tương thích hệ plugin Việt; PHP 8.x + OPcache (tầng 2 của bài chẩn đoán); MariaDB với innodb_buffer_pool_size theo RAM (bài MySQL chậm); và ổ NVMe, nơi wp_options, postmeta, session ghi đọc dày đặc hạ cánh. Trên nền này, các con số của bảng cỡ mới đúng; trên nền Apache + PHP cũ + ổ chậm, cùng traffic cần máy gấp rưỡi-đôi.

Dấu hiệu chật máy thật - và lộ trình nâng

Dấu thật: TTFB trang động tăng dần theo giờ đông (trang cache vẫn nhanh); log PHP báo hết worker/child; %wa hoặc slow query nở giờ nhọn; RAM ép MariaDB co buffer. Dấu giả: % RAM cao đơn thuần (Linux tận dụng RAM làm cache là tốt), CPU nhọn thoáng qua lúc cron. Lộ trình: nâng gói giữ nguyên máy (resize, vài phút) theo từng nấc bảng trên; nấc lớn đầu tiên khi một máy tới hạn là tách MariaDB sang VPS riêng cùng nhà mạng nội bộ, web và database hết giành nhau, mỗi bên tune riêng; sau đó mới đến chuyện nhiều web node, mà đến tầm ấy, bạn đã có đủ số liệu để tự thiết kế.

Vì sao lượt truy cập không phải con số duy nhất

Cách ước đúng: lấy số lượt xem trang trong giờ cao điểm nhất, không lấy trung bình theo ngày. Một trang 30.000 lượt mỗi tháng nhưng dồn hết vào hai giờ mỗi tối cần máy lớn hơn một trang 100.000 lượt rải đều.

Dấu hiệu chật máy thật

# Bo nho: dau hieu ro nhat
free -h        # cot available thap va swap khac 0
vmstat 2 30    # cot si va so khac 0 lien tuc la dang trao trang

# O dia
iostat -x 2 30 # %util gan 100 la nghen

# Tai trung binh so voi so nhan
uptime && nproc

# Tien trinh bi dung vi het bo nho
dmesg | grep -i "out of memory\|killed process" | tail -10

# So tien trinh PHP dang chay va bo nho moi cai
ps -eo rss,comm --sort=-rss | grep -i php | head -10

Thứ tự nâng cấp đúng khi chạm ngưỡng: bộ nhớ trước, ổ NVMe sau, số nhân cuối cùng. Với WordPress, thiếu bộ nhớ là nguyên nhân số một và cũng dễ sửa nhất.

Bộ phần mềm đi kèm quyết định một nửa

• Bộ nhớ đệm mã PHP phải bật, đây là thứ cho hiệu quả lớn nhất mà nhiều người quên.
• Bộ nhớ đệm trang ở tầng máy chủ tốt hơn hẳn ở tầng plugin.
• Bộ nhớ đệm đối tượng cần khi trang có nhiều khách đăng nhập hoặc nhiều truy vấn lặp.
• Số tiến trình PHP tối đa phải tính theo bộ nhớ, không đặt bừa. Đặt quá cao là máy hết bộ nhớ và chết dưới tải, thay vì chỉ chậm.

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

Shared hosting đang chạy ổn, có nên lên VPS không?

Ổn thật thì chưa cần, VPS đáng lên khi: TTFB hosting tệ, bị hàng xóm shared kéo, cần Redis/cron/quyền chủ động, hoặc WooCommerce nghiêm túc. Bài 'VPS hay hosting' (18014) là bản đồ quyết định đầy đủ.

Một VPS chạy được nhiều site WordPress không?

Rất phổ biến: cộng nhu cầu các site theo bảng cỡ + 30% headroom, mỗi site một database, LiteSpeed phân vhost. Site đông đơn nên ở riêng, đơn hàng của khách không đáng chung số phận với blog thử nghiệm.

Managed WordPress hosting so với VPS tự quản?

Managed = trả thêm để người khác vận hành, hợp người không muốn đụng server. VPS tự quản + bộ bài trong cụm này = chi phí thấp hơn nhiều và toàn quyền; AI agent còn làm phần vận hành nhẹ đi nữa. Chọn theo quỹ thời gian và khẩu vị kiểm soát.

WooCommerce của tôi chậm đúng lúc chạy quảng cáo, nâng máy gấp?

Khoan: kiểm cache/checkout theo bài WooCommerce-chậm (bài kế tiếp) trước, thường nút nghẽn là một plugin hay một query, nâng máy chỉ mua thêm vài tuần. Nâng máy đúng khi số liệu 5 tầng đều sạch mà đồng thời vẫn đuối.

Bài viết liên quan

• WordPress chậm: chẩn đoán 5 tầng
• VPS cần bao nhiêu RAM, CPU và ổ cứng
• VPS ổ Enterprise U.2 NVMe RAID 10 tại TND