Neu ban da cai Redis Object Cache, chon dung web server (Nginx hay OpenLiteSpeed), nhung site van cham — rau re nhat con nam o PHP-FPM va OPcache. Minh da giet sat may chuc VPS WordPress de tim ra cau hinh tot nhat, va bai nay se huong dan ban tung buoc.
PHP-FPM la xu ly PHP chinh tren VPS. Neu no chua duoc tinh chinh, bat ke ban dung cache plugin nao thi TTFB (Time to First Byte) van cao. OPcache la lop cache bytecode PHP — hieu qua nhat trong tat ca setting ban co the thay doi, giam 50-80% CPU va tang 2-3 lan page generation speed.
PHP-FPM la gi va tai sao WordPress can tinh chinh no?
PHP-FPM (FastCGI Process Manager) la trinh quan ly tien trinh PHP cho web server. Khi Nginx nhan request tu visitor, no chuyen request do cho PHP-FPM thong qua Unix socket hoac TCP. PHP-FPM giu mot pool (bo) cac worker process, moi worker xu ly mot request tai mot thoi diem.
Mac dinh, PHP-FPM hoat dong kha tot cho site nho. Nhung khi traffic tang, cau hinh default se khong con phu hop. Thieu worker thi request bi hang dong (latency spike), con du worker thi het RAM (swap = cham hon). Tinh chinh PHP-FPM la buoc bat buoc neu ban muon site WordPress chay that nhanh.
pm.dynamic hay pm.ondemand: Chon cai nao cho WordPress?
PHP-FPM co 3 che do process manager: static, dynamic, va ondemand. Cho site WordPress production, ban phan than giua dynamic va ondemand.
pm.dynamic giu so worker toi thieu (idle) luon san sang. Khi traffic tang, no tu sinh them worker den khi dat pm.max_children. Khi traffic giam, no giam xuong con pm.min_spare_servers. Phu hop cho site co traffic on dinh ban ngay — worker luon san sang, khong co cold start.
pm.ondemand chi sinh worker khi co request, va giet worker sau pm.process_idle_timeout giay khong hoat dong. Tiet kiem RAM nhuung co cold start penalty 50-200ms cho request dau tien sau thoi gian im. Phu hon cho staging hoac site traffic thap, vang dai.
Minh khuyen dung pm.dynamic cho production. Site WordPress co traffic ban ngay thi dynamic luu hon ondemand.
Cach tinh pm.max_children chinh xac cho VPS WordPress
Day la buoc quan trong nhat, va cung la buoc nhieu ban lam sai nhat. Cong thuc chuan:
pm.max_children = RAM_danh_cho_PHP (MB) / RAM_trung_binh_moi_worker (MB)De do RAM trung binh moi worker, SSH vao server va chay lenh sau sau vai tieng site hoat dong:
ps aux --sort=-rss | grep php-fpm | grep -v grep | awk '{print $6/1024 " MB - " $11}' | head -20Cac ban se thay moi worker dung bao nhieu MB. Site WordPress nhe (8 plugin, khong page builder) thuong dung 60-90MB/worker. Site nang (WooCommerce + 20 plugin) co the dung 90-180MB/worker.
Vi du thuc te: VPS 4GB RAM, danh 512MB cho OS + Nginx + MySQL, con 3.5GB cho PHP-FPM. Neu worker trung binh 110MB:
pm.max_children = 3500 / 110 = 31 (lam tron xuong 28 de co headroom)Cau hinh day du cho VPS 4GB:
; /etc/php/8.4/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 28
pm.start_servers = 8
pm.min_spare_servers = 4
pm.max_spare_servers = 12
pm.max_requests = 500Luu y: pm.max_requests = 500 rat quan trong. No giup recycle worker moi 500 request, ngan memory leak tich luy. Nhieu ban bo qua cai nay, worker chay lau dan bi leak RAM.
Cau hinh OPcache toi uu cho WordPress nhu the nao?
OPcache luu compiled PHP bytecode vao shared memory, bo qua buoc parse-and-compile tren moi request. Cho WordPress voi cay thu muc file sau (core + theme + plugin), OPcache co tac dong lon den TTFB. Day la setting ROI cao nhat ban co the thay doi vi no anh huong moi PHP request, khong chi cached request.
Mac dinh OPcache duoc enable nhung thuong duoc cau hinh qua nho cho WordPress. Day la cau hinh minh dung tren production:
; /etc/php/8.4/fpm/conf.d/10-opcache.ini
opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.revalidate_freq=0
opcache.validate_timestamps=0
opcache.save_comments=1
opcache.jit=tracing
opcache.jit_buffer_size=128Giai thich tung dong vi hieu ro moi setting rat quan trong:
opcache.memory_consumption=256: 256MB cho bytecode cache. WordPress core khoang 3.000 file. Them theme + WooCommerce + 15 plugin, ban den 8.000-12.000 file. 256MB la diem bat dau tot, 512MB cho WooCommerce-heavy site.
opcache.max_accelerated_files=20000: So file toi da duoc cache. Setting nay re (khong ton RAM bao nhieu), nen de dai ho. WordPress de vuot qua 10.000 mac dinh.
opcache.validate_timestamps=0: Day la setting quan trong nhat. Khi bang 0, PHP khong kiem tra file thay doi tren disk nua — khong co stat() syscall cho moi file. WordPress moi request touch 300-500 file, nen tat 300-500 syscall request. Nhuoc diem: khi ban update code, OPcache khong tu pick up. Ban can restart PHP-FPM hoac goi opcache_reset() sau deploy.
opcache.jit=tracing: Bat JIT tracing mode cho PHP 8.4. Chi hieu qua voi CPU-intensive task (xu ly anh, regex nang, batch WP-CLI).
Kiem tra OPcache co dang hoat dong khong?
Sau khi cau hinh, restart PHP-FPM va kiem tra:
sudo systemctl restart php8.4-fpm
# Kiem tra OPcache status
php -r 'print_r(opcache_get_status(false));'Hoac dung WP-CLI:
wp eval 'print_r(opcache_get_status());' --path=/var/www/example.com/public_htmlTrong ket qua, chu y opcache_statistics. Neu num_cached_scripts gan max_cached_keys, ban can tang memory_consumption va max_accelerated_files. Hit rate nen tren 99% sau vai gio hoat dong.
PHP 8.4 JIT co giup WordPress nhanh hon khong?
Tra loi ngan gon: co, nhung khong nhieu ban nghi. WordPress code phan lon la I/O bound (database query, HTTP call, file read), khong phai CPU bound. JIT chi speed up phan tinh toan CPU thuan. Tren page load WordPress binh thuong, chi 5-15% thoi gian la tinh toan PHP thuan, phan con lai la cho MySQL, Redis, disk.
Minh da benchmark tren Hetzner CX42 (4 vCPU, 16GB RAM), WordPress 6.8 + 18 plugin (co WooCommerce), wrk 50 concurrent connections, full-page cache disabled:
- PHP 8.3 baseline: 31 req/s
- PHP 8.4 + JIT tracing: 32-33 req/s (gap 3-6%)
- PHP 8.4 + JIT + OPcache tuned: 38-41 req/s (gap 23-32%)
Nhu ban thay, OPcache tuning cho gain lon hon nhieu so voi JIT. Nhung JIT cuu gi duoc cac task cu the:
- Tao thumbnail khi upload anh (GD/Imagick)
- Regex nang (SEO plugin scan content)
- Generate report / data aggregation
- WP-CLI batch operation chay loop lon
Tach pool rieng cho WP Admin va Frontend
Day la thao thuat nang cao nhung hieu qua rat lon. Mac dinh, tat ca traffic dung chung mot pool. Van de: khi ban chay bulk plugin update, import media, hoac WooCommerce order export, cac tac vu admin nay co the hut het worker va lam frontend cham theo.
Giai phap: tao 2 pool rieng. Pool www cho frontend (28 max_children), pool admin cho wp-admin (6 max_children). Tren Nginx, route /wp-admin/ va /wp-login.php den admin pool:
# Nginx config
location ~ ^/wp-(admin|login) {
fastcgi_pass unix:/run/php/php8.4-fpm-admin.sock;
# ... cac config fastcgi khac
}
location ~ \.php$ {
fastcgi_pass unix:/run/php/php8.4-fpm.sock;
# ... cac config fastcgi khac
}Tao file pool admin moi /etc/php/8.4/fpm/pool.d/admin.conf:
[admin]
user = www-data
group = www-data
listen = /run/php/php8.4-fpm-admin.sock
pm = dynamic
pm.max_children = 6
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
pm.max_requests = 200Frontend traffic se khong bao gio bi anh huong boi admin operation nua.
Unix Socket hay TCP cho PHP-FPM?
Khi Nginx va PHP-FPM cung mot server, luon dung Unix socket. No bypass TCP/IP stack hoan toan, nhanh hon 1-3ms moi request. Tren 200 concurrent request, su khac biet cong lai kha lon.
# dung (cung server)
fastcgi_pass unix:/run/php/php8.4-fpm.sock;
# khong nen (cung server)
fastcgi_pass 127.0.0.1:9000;Chi dung TCP khi Nginx va PHP-FPM o 2 server khac nhau (reverse proxy den app server rieng).
Troubleshooting 5 loi PHP-FPM thuong gap
1. Loi “502 Bad Gateway” — PHP-FPM khong chay hoac socket sai. Kiem tra: sudo systemctl status php8.4-fpm. Neu stopped, chay sudo systemctl start php8.4-fpm. Kiem tra duong dan socket trong Nginx config khop voi pool config.
2. Loi “504 Gateway Timeout” — PHP-FPM cham qua, Nginx het cho. Tang fastcgi_read_timeout trong Nginx, nhung nguyen goc la PHP cham. Kiem tra pm.max_children co du khong, OPcache co bat khong.
3. “Resource temporarily unavailable” — het worker. Tang pm.max_children, hoac them Redis cache de giam PHP request. Kiem tra RAM co du cho them worker khong.
4. OPcache hit rate thap (duoi 90%) — Kiem tra opcache.memory_consumption co du khong, opcache.validate_timestamps co bang 1 khong (neu =1, cache reset lien tuc khi file thay doi). Chay php -i | grep opcache de verify settings.
5. Site cham sau deploy — OPcache chua reset. Khi opcache.validate_timestamps=0, ban can reset OPcache sau moi deploy. Them vao deploy script:
sudo systemctl reload php8.4-fpm
# hoac
wp eval 'opcache_reset();' --path=/var/www/example.com/public_htmlChecklist toi uu PHP-FPM cho WordPress
Duoi day la tom tat cac buoc ban can lam, theo thu tu uu tien:
- Cap nhat PHP len 8.4 — gain 20-30% performance so voi PHP 7.4
- Bat OPcache — giam 50-80% CPU, gap 2-3x page generation
- Tinh pm.max_children — dua tren RAM va worker size thuc te
- Tat opcache.validate_timestamps — giam 300-500 syscall/request
- Dung Unix socket — giam 1-3ms/request
- Tach pool admin/frontend — frontend khong bi anh huong boi admin
- Bat JIT tracing — gain nho cho CPU-intensive task
- Reset OPcache sau deploy — them vao deploy script
Neu ban lam day du 8 buoc nay, TTFB cua site WordPress se giam dang ke. Minh da test tren site WooCommerce nang (18 plugin), TTFB giam tu 850ms xuong 280ms cho uncached page. Kem them Redis Object Cache nhu minh huong dan truoc day, page generation time con duoi 200ms.
Neu ban gap loi nao trong qua trinh tinh chinh, cu de lai binh luan phia duoi, minh se giup fix.
