Cấu hình Redis object cache cho WordPress trên VPS

Redis object cache làm gì cho WordPress

Redis object cache cho WordPress lưu kết quả các truy vấn database trong memory, nên request tiếp theo đọc dữ liệu từ Redis thay vì truy vấn MySQL lại. WordPress vốn đã có object cache trong core, WP_Object_Cache, nhưng cache này nằm trong memory của PHP và bị xóa khi request kết thúc. Một file drop-in thay thế cache đó bằng cơ chế kết nối với Redis, nên cache được giữ lại giữa các request.

Object caching không phải page caching, và sự khác biệt này quyết định hướng dẫn này có phù hợp với bạn hay không. Page cache lưu HTML đã tạo của một URL rồi phục vụ lại mà không chạy PHP. Cách này nhanh hơn mọi cơ chế Redis có thể cung cấp và hoạt động tốt với những visitor chưa đăng nhập. Khi có người đăng nhập, thêm sản phẩm vào cart hoặc mở admin, page cache không còn áp dụng và WordPress phải chạy toàn bộ request: bootstrap, plugin và truy vấn. Object cache giúp request đó tốn ít tài nguyên hơn. Đây là công cụ dành cho loại traffic mà page cache không xử lý được: session đã đăng nhập, cart, checkout và wp-admin. Với một cửa hàng WooCommerce, phần này chiếm phần lớn traffic tốn tài nguyên.

Hai cơ chế này có thể dùng cùng nhau, và trên một site có traffic cao thì cả hai đều cần thiết. Hãy xác định rõ bạn đang giải quyết vấn đề nào. Một site giới thiệu có người đọc chưa đăng nhập sẽ nhận gần như toàn bộ lợi ích tốc độ từ page cache, còn việc thêm Redis chỉ thay đổi rất ít.

Trước khi bắt đầu, cần hiểu một giới hạn quan trọng. Object cache không làm cho một truy vấn chậm chạy nhanh hơn. Nó chỉ loại bỏ việc lặp lại một truy vấn đã chạy. Request đầu tiên sau khi cache miss vẫn phải trả toàn bộ chi phí, nên plugin thực hiện một truy vấn không có index vẫn sẽ chạy truy vấn đó một lần trong mỗi vòng đời của cache.

Những gì cần chuẩn bị

• Một Linux VPS có shell và sudo. Không cần control panel.
• WordPress chạy bằng PHP-FPM, chẳng hạn như stack LAMP trên Ubuntu 24.04.
• WP-CLI đã được cài trên máy. Mọi bước ở đây đều có thể thực hiện tương đương trong giao diện quản trị, nhưng dùng shell nhanh hơn.
• Redis chạy trên cùng máy với PHP. Mục đích chính là giảm latency, và một network hop sẽ làm mất lợi ích đó.

Các lệnh dưới đây dành cho Ubuntu 24.04 với PHP 8.3 và user web www-data. Hãy điều chỉnh phiên bản PHP và user cho phù hợp với máy của bạn. Chạy các lệnh wp từ thư mục WordPress, tức thư mục chứa wp-config.php.

Cài đặt Redis và extension PHP

sudo apt update
sudo apt install -y redis-server php-redis
sudo systemctl enable --now redis-server
redis-cli ping

redis-cli ping phải trả về PONG. Nếu lệnh in ra Could not connect to Redis at 127.0.0.1:6379: Connection refused thì server chưa chạy, vì vậy hãy đọc systemctl status redis-server trước khi tiếp tục.

php-redis là PhpRedis, extension C từ PECL. Nó nhanh hơn Predis, vốn được viết thuần bằng PHP, và plugin sẽ tự động sử dụng PhpRedis khi extension này có mặt. PHP-FPM nạp extension khi khởi động, vì vậy extension mới sẽ chưa có hiệu lực cho đến khi bạn restart pool.

sudo systemctl restart php8.3-fpm
php -m | grep redis

Hãy cẩn thận với bước kiểm tra cuối cùng: php -m liệt kê các module của PHP chạy trên command line, còn FPM có thể nạp một bộ module khác. Kết quả cần tin cậy là chẩn đoán riêng của plugin ở phần bên dưới.

Tính đến tháng 8 năm 2026, Ubuntu 24.04 cung cấp Redis 7.0.15. Phiên bản này phù hợp làm object cache. Nếu muốn dùng bản phát hành mới hơn, bạn có thể dùng APT repository riêng của Redis.

sudo apt install -y lsb-release curl gpg
curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
sudo chmod 644 /usr/share/keyrings/redis-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/redis.list
sudo apt update
sudo apt install -y redis

Nếu bản phân phối của bạn cung cấp Valkey, fork được bắt đầu sau thay đổi giấy phép năm 2024, Valkey sử dụng cùng protocol và toàn bộ hướng dẫn bên dưới vẫn áp dụng nguyên trạng.

Bind Redis để không thành phần nào khác truy cập được

Theo mặc định, Redis không có password. Bất kỳ thành phần nào mở được kết nối đến port 6379 đều có thể đọc mọi giá trị trong cache và chạy FLUSHALL. Các instance bị public Internet phát hiện trong vài giờ bởi các scanner, vì vậy cần cấu hình network trước khi tuning.

Mở /etc/redis/redis.conf và xác nhận các dòng sau:

bind 127.0.0.1 -::1
protected-mode yes

Sau đó kiểm tra thực tế tiến trình nào đang listen, vì file cấu hình chỉ là khai báo còn ss mới là bằng chứng.

sudo ss -lntp | grep 6379

127.0.0.1:6379 là kết quả cần có. 0.0.0.0:6379 nghĩa là Redis đang trả lời trên public interface: sửa dòng bind rồi restart.

Khi PHP và Redis chạy trên cùng một máy, Unix socket tốt hơn loopback TCP. Đường truyền không đi qua TCP stack, và quyền truy cập được quyết định bằng file permission thay vì một firewall rule có thể bị thay đổi sau này.

unixsocket /run/redis/redis-server.sock
unixsocketperm 770

Socket thuộc user và group redis, vì vậy web user phải được thêm vào group đó.

sudo systemctl restart redis-server
sudo usermod -aG redis www-data
sudo systemctl restart php8.3-fpm
redis-cli -s /run/redis/redis-server.sock ping

Lệnh này cũng phải in ra PONG. Could not connect to Redis at /run/redis/redis-server.sock: Permission denied nghĩa là group chưa có hiệu lực. Kiểm tra id www-data và nhớ rằng PHP-FPM đang chạy giữ nguyên các group tại thời điểm khởi động, nên restart mới có trong danh sách. Giữ TCP enabled cho đến khi xác nhận socket hoạt động, nếu không một lỗi gõ sai có thể làm mất cả hai đường truy cập cùng lúc.

Redis nên được cấp bao nhiêu bộ nhớ?

Hãy tính con số này từ chính máy chủ của bạn. Redis không có maxmemory sẽ tăng bộ nhớ sử dụng cho đến khi kernel cạn bộ nhớ và OOM killer kết thúc một tiến trình, thường là tiến trình lớn nhất. Trên server WordPress, tiến trình đó thường là MySQL. journalctl -k | grep -i "out of memory" cho thấy lần kill đó sau khi xảy ra, nhưng lúc ấy website đã ngừng hoạt động.

Hãy bắt đầu từ tổng RAM rồi trừ dần. MySQL hoặc MariaDB dành riêng innodb_buffer_pool_size cùng các buffer cho từng connection. PHP-FPM dùng pm.max_children nhân với kích thước resident thực tế của một worker, thường là 64 MB đến 128 MB trên website có nhiều plugin. Kernel và web server cần vài trăm megabyte. Phần còn lại là giới hạn của bạn, và Redis chỉ được cấp một phần trong đó.

Bây giờ hãy đo thay vì đoán. Sau một ngày có network traffic thực tế:

redis-cli info memory | grep -E 'used_memory_human|maxmemory_human|maxmemory_policy'
redis-cli dbsize

Nếu used_memory_human thấp hơn nhiều so với giới hạn, hãy giảm giới hạn và trả RAM cho MySQL, vì MySQL sẽ sử dụng phần RAM đó hiệu quả hơn. Nếu giá trị này chạm giới hạn và evicted_keys tăng suốt cả ngày, hãy tăng giới hạn. Đặt giá trị trong /etc/redis/redis.conf.

maxmemory 256mb
maxmemory-policy allkeys-lru

redis-cli config set maxmemory 256mb có hiệu lực ngay lúc này nhưng sẽ mất sau lần restart tiếp theo, giống như trường hợp sysctl -w trống. Hãy sửa file, sau đó sudo systemctl restart redis-server, rồi đọc lại giá trị. Nên có thêm một giới hạn thứ hai: MemoryMax trên systemd unit sẽ ngăn Redis được cấu hình sai làm server ngừng hoạt động. Hãy đặt giới hạn này cao hơn maxmemory, không được bằng nó, vì giới hạn cgroup sẽ kill tiến trình thay vì evict key. Nếu Redis chạy trong container cùng với WordPress, hãy đặt cùng con số đó trong các giới hạn bộ nhớ trong file Compose, và cùng cách suy luận này sẽ quyết định lựa chọn chạy database trong Docker hay trên host.

Chọn chính sách eviction một cách có chủ đích

Redis mới cài đặt mặc định là noeviction. Kiểm tra cấu hình của bạn:

redis-cli config get maxmemory-policy

Với noeviction, instance đầy sẽ ngừng nhận thao tác ghi và trả về lỗi sau:

(error) OOM command not allowed when used memory > 'maxmemory'.

Một dòng lỗi này là chế độ lỗi nghiêm trọng nhất trong hướng dẫn này, vì site không bị ngừng hoạt động. Site chỉ chậm hơn. Mọi thao tác ghi vào cache đều thất bại, nên WordPress quay lại database để lấy giá trị, rồi thử lưu lại giá trị đó ở request tiếp theo và lại thất bại. Lúc này site phải xử lý toàn bộ truy vấn database như trước, cộng thêm một round trip đến Redis cho mỗi key. Không có thông báo nào trong WordPress admin cho biết sự cố này đang xảy ra. Chuỗi lỗi xuất hiện trong PHP error log, vì vậy hãy grep OOM command not allowed khi site chậm hơn sau khi bạn thêm cache.

allkeys-lru là giá trị mặc định phù hợp trong trường hợp này. Khi bộ nhớ gần đầy, Redis sẽ xóa key ít được sử dụng gần đây nhất. Đây chính xác là hành vi object cache cần, vì mọi giá trị trong đó đều là bản sao của dữ liệu vẫn còn trong MySQL. Mất một key chỉ tốn một truy vấn. Từ chối một thao tác ghi làm phát sinh chi phí của mọi truy vấn, trên mọi request, cho đến khi có người phát hiện ra.

Tránh các chính sách volatile-* cho mục đích này. Các chính sách này chỉ xét những key có thời hạn hết hạn, và Redis ghi rõ rằng chúng hoạt động như noeviction khi không có key nào có thời hạn. WordPress lưu phần lớn các mục trong object cache mà không có TTL, nên volatile-lru trên object cache có thể đầy và bắt đầu từ chối thao tác ghi. allkeys-lfu là một lựa chọn thay thế hợp lý nếu traffic của bạn thường xuyên truy cập một nhóm nhỏ key, vì chính sách này eviction theo tần suất thay vì theo độ gần đây. Hãy chọn một chính sách có chủ đích và ghi lại lý do.

Persistence: tắt nếu không có lý do cần giữ

redis.conf đi kèm bật snapshot RDB bằng các dòng như save 900 1 và tắt append-only file. Với object cache thuần túy, snapshot không mang lại lợi ích gì. Theo định nghĩa, dữ liệu có thể tạo lại được. Cache được khôi phục từ một file cũ hơn hai mươi phút sẽ chứa các giá trị đã lỗi thời mà WordPress vẫn tin dùng.

Snapshot cũng tốn tài nguyên. BGSAVE fork process, và cơ chế copy-on-write có thể khiến mức sử dụng bộ nhớ tăng mạnh trong khi process con ghi dữ liệu. Trên VPS nhỏ, điều này sẽ xuất hiện trong Redis log:

Can't save in background: fork: Cannot allocate memory

Khi khởi động, thường cũng có cảnh báo sau. Đây là cách Redis cho biết thao tác fork có thể sẽ thất bại về sau:

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition.

Để tắt snapshot, đặt lịch save rỗng trong /etc/redis/redis.conf, restart, rồi xác nhận giá trị đã trở lại rỗng.

save ""

sudo systemctl restart redis-server
redis-cli config get save

Chỉ giữ persistence nếu cùng instance chứa dữ liệu không thể tạo lại, chẳng hạn job queue hoặc bộ đếm rate limit. Khi đó, hãy tách hai loại dữ liệu này. Cache cần cho phép evict key, còn dữ liệu bền vững cần giữ key. maxmemory và eviction áp dụng cho toàn bộ instance, không áp dụng riêng cho từng database index. Chạy hai instance trên hai socket là cách phù hợp nhất.

Cài plugin và hiểu drop-in

wp plugin install redis-cache --activate
wp redis enable
wp redis status

wp redis enable in Object cache enabled. khi thành công. Thực tế, lệnh này sao chép wp-content/plugins/redis-cache/includes/object-cache.php vào wp-content/object-cache.php. Bản sao đó là drop-in, và drop-in mới là phần thực hiện công việc. WordPress tải wp-content/object-cache.php rất sớm, trước khi bất kỳ mã plugin nào chạy. Nhờ đó, cache có sẵn trong toàn bộ request. Plugin đang active nhưng không có drop-in sẽ không cache gì.

Các thông báo lỗi cho biết phần nào bị lỗi. Object cache could not be enabled. nghĩa là thao tác sao chép thất bại, vì vậy wp-content không cho phép user chạy WP-CLI ghi dữ liệu. A foreign object cache drop-in was found. nghĩa là một plugin cache khác đã dùng filename đó. Cách xử lý là wp redis update-dropin. Nếu thông báo kết thúc bằng Redis server is unreachable: rồi xuất hiện lỗi từ client, các thiết lập kết nối bị sai. Hãy quay lại redis-cli ping.

Nếu thao tác sao chép thất bại do permission, hãy chép file bằng tay rồi đặt owner là web user.

cp wp-content/plugins/redis-cache/includes/object-cache.php wp-content/object-cache.php
sudo chown www-data:www-data wp-content/object-cache.php

Gỡ plugin không xóa drop-in. Trước tiên chạy wp redis disable. Lệnh này in Object cache disabled. rồi xóa file. Nếu xóa thư mục plugin nhưng để lại drop-in, site vẫn tiếp tục chạy mã cache cũ mà không có plugin để cập nhật mã đó.

Cài đặt kết nối trong wp-config.php

Thêm các dòng này bên trên dòng có nội dung /* That's all, stop editing! */, vì các constant được định nghĩa sau dòng đó sẽ không còn có hiệu lực kịp thời.

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'shop_prod:' );

Đối với Unix socket, đặt scheme và đường dẫn. Khi đó, host và port sẽ bị bỏ qua.

define( 'WP_REDIS_SCHEME', 'unix' );
define( 'WP_REDIS_PATH', '/run/redis/redis-server.sock' );
define( 'WP_REDIS_PREFIX', 'shop_prod:' );

WP_REDIS_MAXTTL buộc mọi key phải hết hạn sau số giây được chỉ định. Bạn không cần dùng nó với allkeys-lru. Tùy chọn này hữu ích nếu bạn muốn giới hạn cứng thời gian một value trong cache có thể bị cũ.

Một Redis, nhiều site: prefix và database

Redis mặc định cung cấp 16 database được đánh số và một keyspace phẳng trong mỗi database. Hai WordPress cùng trỏ đến database 0 mà không có prefix sẽ ghi các tên key giống nhau vào cùng một không gian. Vì vậy, site này có thể đọc và phân phát option của site kia. Hãy cấp cho mỗi site một prefix riêng.

define( 'WP_REDIS_PREFIX', 'shopA_prod:' );
define( 'WP_REDIS_DATABASE', 1 );

Prefix tách riêng tên key. Chỉ số database tách riêng các keyspace. Điều này quan trọng khi flush: xóa toàn bộ một index không ảnh hưởng đến các index khác. Plugin cũng có tài liệu về WP_REDIS_SELECTIVE_FLUSH. Tùy chọn này chỉ xóa các key khớp với prefix của bạn thay vì xóa toàn bộ database, nhưng phải trả giá bằng việc quét để tìm các key đó.

Prefix và index không tách riêng bộ nhớ. maxmemory và eviction policy áp dụng cho toàn bộ instance. Vì vậy, một site có tải cao có thể đẩy key của site ít tải ra khỏi cache mà cả hai site đều không báo lỗi. Những site không được phép ảnh hưởng lẫn nhau cần các Redis instance riêng. Mỗi instance có socket riêng và giới hạn tài nguyên riêng.

Tách staging khỏi cache của production

Site staging thường là bản sao của các file và database trên production. Vì vậy, nó cũng là bản sao của wp-config.php, dùng cùng prefix và cùng database index. Nếu trỏ staging vào cùng Redis, nó sẽ ghi các key của production bằng giá trị từ staging. Một mức giá thử nghiệm hoặc một option đã thay đổi có thể xuất hiện trên site live mà không cần deploy và không để lại dấu vết.

Tự đặt salt riêng cho từng environment. Trong wp-config.php của staging:

define( 'WP_REDIS_PREFIX', 'shop_staging:' );
define( 'WP_REDIS_DATABASE', 5 );

Tốt hơn nữa, hãy cấp cho staging một Redis instance riêng hoặc không dùng object cache. define( 'WP_REDIS_DISABLED', true ); tắt cache khi runtime và vẫn giữ drop-in, đây cũng là cách nhanh nhất để xác định một bug có phải do cache hay không.

Các tutorial cũ thường đặt WP_CACHE_KEY_SALT cho mục đích này. README của plugin đánh dấu constant đó là deprecated và cho biết đã được thay bằng WP_REDIS_PREFIX, vì vậy hãy dùng tên mới.

Xác minh thay vì tin tưởng

Bắt đầu bằng các chẩn đoán của chính plugin.

wp redis status

Dòng quan trọng nhất là Drop-in. Drop-in: Valid nghĩa là WordPress đang nạp file của plugin này. Drop-in: Not installed nghĩa là thao tác sao chép chưa từng xảy ra và site không có persistent cache, dù màn hình quản trị hiển thị màu xanh đến đâu. Status báo cáo kết nối, còn Client cho biết extension đang được sử dụng. Đây là nơi bạn xác nhận đang dùng PhpRedis thay vì Predis.

Tiếp theo, hãy hỏi trực tiếp WordPress core, vì core không phụ thuộc vào nhận định của plugin.

wp eval 'var_dump( wp_using_ext_object_cache() );'

bool(true) nghĩa là core đang giao tiếp với external object cache.

Sau đó, hãy xác minh các key thực sự được ghi vào, với prefix bạn đã cấu hình.

redis-cli -n 0 dbsize
redis-cli -n 0 --scan --pattern 'shop_prod:*' | head

dbsize tăng lên khi bạn thao tác trên site là bằng chứng xác thực. Số key bằng 0 dù drop-in hợp lệ nghĩa là kết nối đang âm thầm thất bại, hoặc prefix không phải giá trị bạn nghĩ.

Cuối cùng, xem các chỉ số Redis ghi nhận cho bạn.

redis-cli info stats | grep -E 'keyspace_hits|keyspace_misses|evicted_keys|expired_keys'

Hit ratio là keyspace_hits / (keyspace_hits + keyspace_misses), và tài liệu Redis đưa ra công thức đó. Khi đọc chỉ số này, cần lưu ý 2 điều. Các counter bao phủ toàn bộ instance kể từ lần restart gần nhất, nên chúng gộp dữ liệu của mọi site và mọi ứng dụng dùng chung instance. Ngoài ra, ratio ngay sau khi flush hoặc restart không có ý nghĩa, vì cache vẫn đang được nạp dữ liệu. Hãy để hệ thống chạy qua một ngày có traffic bình thường.

Không so sánh số của bạn với hit rate hoặc số query do một công ty hosting công bố. Các số đó mô tả site và bộ plugin của họ. Chỉ số quan trọng là số của chính bạn, được đo trước và sau trên một page mà page cache không thể phục vụ.

curl -o /dev/null -s -w '%{time_starttransfer}\n' -b cookies.txt https://example.com/my-account/

Chạy lệnh đó với cookie jar đã đăng nhập, vài lần, khi cache tắt (WP_REDIS_DISABLED) rồi khi cache bật. Chênh lệch đó là kết quả của bạn.

Khi Redis làm WordPress chậm hơn

Một instance đầy với policy không phù hợp là nguyên nhân lớn nhất, đã được đề cập ở trên: OOM command not allowed when used memory > 'maxmemory'. trong log, trong khi website phải trả tiền cho cả database và cache.

Redis chạy trên host khác là nguyên nhân thứ hai. WordPress thực hiện hàng trăm lần gọi object cache trong một request. Nếu một request thực hiện 500 lần gọi và mỗi round trip mất 1 ms, bạn sẽ phải chờ thêm nửa giây so với khi dùng local socket. Hãy chạy Redis trên cùng máy, hoặc trên private network có latency dưới 1 ms.

Bảng options có quá nhiều mục được autoload là nguyên nhân thứ ba và thường gặp ở các website cũ. WordPress cache toàn bộ autoloaded options dưới dạng một key duy nhất, vì vậy mỗi request đều truyền một lượng dữ liệu có thể lên đến megabyte qua connection. Hãy đo kích thước:

wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024) AS kb FROM wp_options WHERE autoload IN ('yes','on','auto','auto-on');"

WordPress 6.6 bổ sung các giá trị autoload mới, nên query cũ chỉ khớp với 'yes' sẽ cho kết quả thấp hơn thực tế trên bản cài đặt hiện đại. Bất kỳ kích thước nào vượt quá một megabyte đều là vấn đề cần xử lý trong bảng options, không phải trong Redis.

Mỗi lần restart sẽ xóa toàn bộ cache, vì vậy những phút sau systemctl restart redis-server đều là cache miss và phát sinh toàn bộ truy vấn database. Hãy restart khi traffic thấp. Object cache cũng không ngăn wp-cron.php chạy khi visitor tải trang, và đây là một nguồn khác gây request chậm: chuyển WP-Cron sang một cron job thực sự của systemd trong lúc bạn đang xử lý việc này.

Dọn dẹp

Sau khi deploy có thay đổi options hoặc mã theme, hãy flush bằng wp cache flush. Chạy wp redis update-dropin sau khi update plugin nếu drop-in không tự cập nhật, vì drop-in của phiên bản plugin cũ khi chạy với plugin mới là nguyên nhân thực tế gây ra các hành vi bất thường. Theo dõi server đang chạy bằng redis-cli --stat; lệnh này in một dòng mỗi giây. redis-cli monitor in mọi command và thực sự tiêu tốn CPU trên instance bận, vì vậy chỉ dùng trong vài giây khi bạn tái hiện lỗi, rồi dừng lại.

Một con số cuối cùng cần biết: redis-cli info clients báo cáo connected_clients. PHP-FPM giữ một connection cho mỗi worker, vì vậy con số này nên tương ứng với pm.max_children, không cao hơn một bậc độ lớn. Nếu cao hơn, có thành phần đang mở connection nhưng không đóng chúng.

FAQ

Tôi có còn cần page cache nếu đã chạy Redis object cache không?

Có, đối với lưu lượng chưa đăng nhập. Page cache phục vụ HTML đã lưu mà không cần chạy PHP, luôn tiết kiệm hơn chạy WordPress với object cache đã được làm nóng. Object cache xử lý những request mà page cache phải bỏ qua: người dùng đã đăng nhập, giỏ hàng, checkout và wp-admin. Với website bán hàng hoặc website thành viên, nên chạy cả hai. Với website mà khách truy cập không bao giờ đăng nhập, page cache gần như xử lý toàn bộ công việc.

Nên cấp bao nhiêu memory cho Redis khi chạy WordPress?

Hãy tính dựa trên chính máy chủ của bạn thay vì sao chép một con số có sẵn. Lấy tổng RAM, trừ buffer pool của MySQL và các buffer theo từng connection, trừ pm.max_children nhân với resident size của một PHP-FPM worker, rồi trừ thêm vài trăm megabyte cho kernel và web server. Cấp cho Redis một phần dung lượng còn lại, sau đó kiểm tra used_memory_human trong redis-cli info memory sau một ngày có traffic và điều chỉnh. Một WordPress site thường ổn định ở mức vài chục megabyte, nên maxmemory 256 MB là mức khởi đầu dư dả trên server 4 GB.

Vì sao site chậm hơn sau khi bật Redis object cache?

Nguyên nhân thường gặp là instance đã đầy và đang dùng policy noeviction. Redis từ chối các write mới và trả về OOM command not allowed when used memory > 'maxmemory'., nên WordPress fallback về database cho từng value, đồng thời vẫn tốn thêm một Redis round trip không cần thiết. Kiểm tra redis-cli config get maxmemory-policy, đặt allkeys-lru và xác nhận maxmemory không quá nhỏ. Các nguyên nhân phổ biến khác là Redis server nằm trên host từ xa, khiến hàng trăm round trip trong mỗi request cộng dồn thành độ trễ lớn, và một options value được autoload có kích thước vài megabyte, phải truyền qua connection trong mỗi request.

Nhiều WordPress site có thể dùng chung một Redis server không?

Có thể, nhưng cần cấu hình cẩn thận. Cấp cho mỗi site một WP_REDIS_PREFIX duy nhất để tên key không bị trùng, và một WP_REDIS_DATABASE index riêng để flush một site không xóa dữ liệu của site khác. Tuy nhiên, chúng vẫn dùng chung memory: maxmemory và eviction áp dụng cho toàn bộ instance, nên một site có traffic cao có thể evict key của site ít traffic. Những site không được phép ảnh hưởng lẫn nhau cần dùng các Redis instance riêng với giới hạn riêng.

Xóa wp-content/object-cache.php có an toàn không?

Có. Đây là một drop-in, không thuộc WordPress core. Xóa file này sẽ đưa WordPress về cache tích hợp theo từng request. Site vẫn hoạt động và chỉ thực hiện nhiều database query hơn. Nên dùng wp redis disable, lệnh này xóa file đúng cách và báo cáo Object cache disabled.. Xóa thủ công là cách xử lý khẩn cấp phù hợp nếu Redis đang down hoặc hoạt động lỗi và bạn không thể truy cập trang quản trị.