Tối ưu tốc độ website gấp 3 lần với CyberPanel LiteSpeed trên VPS: Liệu có đơn giản như bạn nghĩ?

Nhanh gấp 3? Từ từ đã

Đầu năm nay mình dời blog WordPress từ shared hosting sang một con VPS 2 vCPU / 2GB RAM, cài CyberPanel. Lý do đơn giản: đọc mấy bài benchmark thấy LiteSpeed đè Nginx, kỳ vọng cài xong là site bay. Cài xong, trỏ domain, restore site, chạy PageSpeed.

Chẳng đổi gì mấy.

TTFB vẫn vàng, điểm vẫn lẹt đẹt như hồi còn ở shared hosting. Mình ngồi ngẩn ra một lúc, nghĩ chắc cài thiếu bước nào đó. Hóa ra không thiếu bước nào cả — mình thiếu hiểu biết về chỗ mà LiteSpeed thật sự nhanh. Bài này là những gì mình đúc rút được sau đợt đó, kèm mấy case mình đọc trên forum nước ngoài mà giá như biết sớm hơn.

Tối ưu tốc độ website với CyberPanel LiteSpeed trên VPS: chỗ "gấp 3" nằm ở đâu?

Trước hết phải sòng phẳng với con số. Blog WP Speed Matters từng dựng 2 droplet DigitalOcean $5 giống hệt nhau, cùng theme Astra, một bên Nginx + WP Rocket, một bên OpenLiteSpeed + LiteSpeed Cache. Kết quả đọc kỹ mới thấy hay:

• TTFB: OLS thắng, tiết kiệm 50–150ms ở các region xa.
• Load time tổng: Nginx lại nhanh hơn… 0.1 giây. Tác giả tự nhận khó chọn kẻ thắng.
• Stress test 10k requests/giây: Nginx timeout gần 50% số request, OLS chỉ dưới 6%. Response time trung bình lúc quá tải: 5.7 giây với Nginx so với 2.8 giây với OpenLiteSpeed.

Thấy chưa — cái "gấp đôi, gấp ba" là chuyện lúc đông người vào cùng lúc, và chuyện cache. Không phải chuyện một request lẻ loi lúc 3 giờ sáng. Nói thật: nếu site bạn ngày có vài trăm visitor rải đều, chuyển từ Nginx sang OLS bạn gần như không cảm nhận được gì bằng mắt thường. Đừng phức tạp hóa.

TTFB cao thì đổ lỗi cho ai?

Đây là cái bẫy mình dính, và không phải mình mình dính. Một case mình đọc trên forum CyberPanel từ 2021: bạn user tên pheonis migrate site WordPress từ AWS sang Linode (datacenter Ấn Độ), VPS 1 CPU / 1GB chạy CyberPanel. Site đã tối ưu sẵn, LiteSpeed cache plugin đang serve cached, ảnh đẩy qua CDN, page chỉ ~300kb. Vậy mà GTmetrix vẫn báo TTFB gần 1 giây.

Founder CyberPanel vào trả lời một câu gọn lỏn: "Initial TTFB is always related to server and nothing to do with CyberPanel or LiteSpeed." Và một user khác chỉ ra điểm chí mạng: GTmetrix mặc định test từ server bên Canada. Canada bắn request sang Ấn Độ thì TTFB gánh nguyên đường truyền xuyên lục địa, panel nào cứu nổi. Lời khuyên trong thread: đo bằng Chrome Lighthouse từ chính mạng của mình, hoặc chọn location test gần người dùng thật.

Mình học được hai thứ từ case này. Một: đo sai chỗ thì mọi con số vô nghĩa. Hai: cùng thread có gợi ý nếu VPS chỉ host đúng 1 website thì cân nhắc chuyển từ OpenLiteSpeed sang LiteSpeed Enterprise bản free vì nó tối ưu hơn với 1 worker mặc định — cái này tùy khẩu vị, mình vẫn dùng OLS.

Mở DevTools ra, nhìn đúng một cái header thôi

Đây là phần quan trọng nhất bài, chịu khó đọc chậm. Bạn mở site của mình lên, bấm F12, sang tab Network, F5, click vào request document đầu tiên, kéo xuống Response Headers. Tìm dòng x-litespeed-cache.

• Thấy hit: trang này được trả thẳng từ cache ở tầng web server. PHP không chạy một dòng nào, WordPress không thức dậy, database ngủ yên. Đây chính là lúc TTFB xuống vài chục ms.
• Thấy miss: cả cỗ máy WordPress phải khởi động — load core, load plugin, query database, render — rồi mới trả HTML.

Cùng một trang, hit và miss có thể chênh nhau cả chục lần. Trên forum OpenLiteSpeed có case một bạn (nick kowalski215) chạy 2 website trên con Hetzner CPx11 2 vCPU / 2GB: visitor đầu tiên xem trang chưa có cache, header trả về x-litespeed-cache: miss, TTFB nhảy lên 2-3 giây. Bạn ấy làm cái việc mà đa số chúng ta sẽ làm: nâng server mạnh hơn, nhiều core hơn, nhiều RAM hơn. Nguyên văn kết quả: "I tried upgrading to a more powerful server (more cores and more ram), but the situation did not change."

Vì sao? Vì lúc cache miss, nút thắt là kiến trúc WordPress chứ không phải phần cứng. Cũng thread đó có câu giải thích mình thấy chuẩn: kiến trúc filter/action của WP khiến gần như mọi thứ bị gọi gần như mọi lúc, page builder và plugin viết ẩu là thủ phạm quen mặt của load time dài. Đổ thêm CPU vào một đống code chậm thì nó vẫn chậm.

Còn vì sao LiteSpeed Cache lại khác các plugin cache thường? Có một blog Nhật đo field data PageSpeed Insights suốt 1 tháng trên cùng một site, lần lượt với LiteSpeed Cache và WP-Optimize: WP-Optimize không kéo nổi TTFB xuống dưới ngưỡng xanh 0.8 giây, LiteSpeed Cache thì được. Lý giải của họ: plugin cache thông thường vẫn phải chạy PHP để đi tìm cache, còn LSCache trả cache ở tầng server, trước khi PHP kịp chạy. Chênh lệch nằm đúng ở đó.

Fix cho cache miss thì forum chốt một hướng: dùng crawler pre-cache (LiteSpeed Cache plugin có sẵn tính năng Crawler) để bò qua các trang và làm nóng cache trước — visitor thật gần như luôn gặp trang đã cache. Đây mới là cái "gấp 3" bạn đi tìm.

Chỉnh đúng mấy chỗ này, đừng táy máy lung tung

Sau đợt đó mình gom được một checklist ngắn, phần lớn khớp với playbook tuning OLS + WordPress mình tham khảo trên GitHub:

• LSCache plugin: áp preset Essentials trước. Public Cache TTL khoảng 120–300 giây là hợp lý với site tin tức/blog, bật Purge All On Upgrade. Món minify/combine JS-CSS rất dễ vỡ giao diện — bật xong phải mở site soát lại từng trang chính, đừng bật rồi đi ngủ.
• PHP LSAPI: vào WebAdmin Console (cổng 7080) > Server Configuration > External App, Max Connections tầm 200 cho site thật, set Environment PHP_LSAPI_CHILDREN khớp đúng số đó, rồi graceful restart. Nhưng đừng tham: worker nhiều gấp mấy lần số CPU thì lúc CPU chạm 100%, mỗi process càng chậm thêm và khách bắt đầu ăn lỗi 503.
• php.ini: opcache.enable=1, production thì opcache.validate_timestamps=0; memory_limit 256M–512M tùy site.

À, một cái nhiều bạn hay quên: docs OpenLiteSpeed khuyến cáo thẳng là không bật cache server-wide — enableCache cố tình không có ở server level. Bật theo từng virtual host, mỗi vhost một storagePath riêng kiểu $VH_ROOT/lscache. Nhiều site chung một kho cache là mời rắc rối vào nhà.

Hôm nào 503 nhảy ra giữa mặt

Dùng LiteSpeed đủ lâu kiểu gì cũng có ngày gặp. Blog chính chủ LiteSpeed nói gọn: 503 thường do PHP crash, thiếu memory, hoặc cả hai. Log đầu tiên nên mở là stderr.log trong /usr/local/lsws/logs/, rồi mới tới error.log. Có một dòng mà nếu thấy thì bạn hiểu ngay chuyện gì đang xảy ra:

[NOTICE] [824] No request delivery notification has been received from LSAPI application, possible dead lock

Kịch bản quen thuộc theo giải thích trên forum CyberPanel: một script PHP chạy quá lâu hoặc dính vòng lặp vô hạn, người dùng thấy trang treo nên F5 liên tục, thế là toàn bộ worker PHP bị chiếm sạch, request mới hết chỗ chen. Lệnh cấp cứu (ví dụ với PHP 8.0):

killall lsphp
rm -rf /var/lib/lsphp/session/lsphp80; mkdir -p /var/lib/lsphp/session/lsphp80; chmod 1733 /var/lib/lsphp/session/lsphp80

Nhưng lưu ý — cũng trong thread đó, có người làm đủ các bước, tăng cả Max Connections, mà "it still giving me this error". Câu chốt của forum: fix cuối cùng vẫn là fix cái script. Muốn tìm thủ phạm thì ps aux | grep lsphp80 rồi strace vào PID đang treo mà xem nó kẹt ở đâu. Cách này không tuyệt đối hoàn hảo, nhưng đủ dùng cho 90% ca mình từng phải đụng tới.

Còn con VPS của mình thì sao

Quay lại câu chuyện đầu bài. Sau khi hiểu ra vụ hit/miss, mình làm đúng ba việc: bật LiteSpeed Cache plugin với preset Essentials, để crawler chạy làm nóng cache, và bỏ thói quen tin điểm số từ server test cách người đọc của mình nửa vòng trái đất — chuyển sang đo Lighthouse từ chính mạng nhà. Các trang được cache giờ trả header hit đều đặn, TTFB nằm gọn dưới ngưỡng xanh 0.8s của PageSpeed. Trang nào miss thì vẫn chậm, đúng như cơ chế nó phải thế.

Vậy "gấp 3 lần" có thật không? Có — khi đông người vào cùng lúc và cache hit, con số stress test bên trên không nói dối. Không — nếu bạn nghĩ cài CyberPanel xong là xong. Panel chỉ dọn sẵn sân. Cache mới là cầu thủ ghi bàn, và bạn phải tự đưa nó vào sân.