Cài 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ủa các truy vấn database trong memory, để request tiếp theo đọc kết quả từ Redis thay vì truy vấn MySQL lần nữa. WordPress vốn đã có object cache trong core, WP_Object_Cache, nhưng cache này nằm trong PHP memory 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 vẫn tồn tại từ request này sang request tiếp theo.

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 hoàn chỉnh 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 thứ Redis có thể làm và hoạt động với visitor chưa đăng nhập. Khi người dùng đăng nhập, thêm item vào cart hoặc mở admin, page cache không còn áp dụng và WordPress chạy toàn bộ request: bootstrap, plugin và query. Object cache làm cho 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 shop WooCommerce, đây thường là phần lớn traffic tốn nhiều tài nguyên nhất.

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

Trước khi bắt đầu, cần nêu rõ một giới hạn. Object cache không làm query chậm chạy nhanh hơn. Nó chỉ loại bỏ việc lặp lại một query đã chạy. Request đầu tiên sau khi cache miss vẫn phải trả toàn bộ chi phí, nên plugin chạy một query không có index vẫn sẽ chạy query đó 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ư một LAMP stack trên Ubuntu 24.04.
• WP-CLI trên máy chủ. Mọi bước ở đây đều có thao tác tương đương trong giao diện quản trị, nhưng dùng shell nhanh hơn.
• Redis 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à web user www-data. Hãy điều chỉnh phiên bản PHP và user cho phù hợp với máy chủ 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à PHP extension

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, 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, C extension từ PECL. Nó nhanh hơn Predis, vốn được viết hoàn toàn bằng PHP, và plugin sẽ tự động dùng nó khi extension này có mặt. PHP-FPM nạp extension khi khởi động, nên 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: 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ả kiểm tra có giá trị là phần diagnostics của chính plugin, nằm ở 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 cho object cache. Nếu muốn dùng bản release mới hơn, Redis có APT repository riêng.

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 distribution 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ộ phầ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 có thể truy cập

Redis không có password theo mặc định. Bất kỳ thành phần nào có thể mở 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ị expose ra Internet thường bị scanner phát hiện trong vài giờ, 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ế process 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à trạng thái 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 kết nối 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 mà sau này bạn có thể thay đổi.

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. Vì vậy danh sách có lệnh restart. Hãy giữ TCP được bật cho đến khi xác nhận socket hoạt động, nếu không một lỗi typo có thể đồng thời làm mất cả hai đường kết nối.

Redis nên được cấp bao nhiêu memory?

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

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 với buffer cho từng connection. PHP-FPM tiêu tốn pm.max_children nhân với resident size thực tế của một worker, thường từ 64 MB đến 128 MB trên site có nhiều plugin. Kernel và web server cần vài trăm megabyte. Phần còn lại là mức trầ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 hạ giới hạn và trả RAM lại cho MySQL, vì MySQL sẽ sử dụng phần RAM đó hiệu quả hơn. Nếu nó 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. Đây cũng là cái bẫy như một sysctl -w trống. Hãy sửa file, sau đó sudo systemctl restart redis-server, rồi đọc lại giá trị. Nên đặt 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 down. Đặ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 process thay vì evict key. Nếu Redis chạy trong một container cùng với WordPress, hãy đặt cùng con số đó trong các memory limit trong file Compose, và cùng cách suy luận này sẽ quyết định việc chạy database trong Docker hay trên host.

Chủ động chọn eviction policy

Redis mới cài đặt mặc định là noeviction. Kiểm tra instance 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'.

Đây là failure mode nghiêm trọng nhất trong hướng dẫn này vì website không bị down. Website chỉ chậm hơn. Mọi thao tác ghi cache đều fail, nên WordPress quay lại database để lấy giá trị, sau đó thử lưu lại giá trị đó ở request tiếp theo và lại fail. Website lúc này phải xử lý toàn bộ workload database ban đầu, cộng thêm một round trip đến Redis cho mỗi key. WordPress admin không hiển thị thông tin cho biết điều này đang xảy ra. Chuỗi lỗi xuất hiện trong PHP error log, nên hãy grep OOM command not allowed khi website chậm hơn sau khi bạn thêm cache.

allkeys-lru là lựa chọn mặc định phù hợp ở đây. Khi bộ nhớ gần đầy, Redis 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 query. Từ chối một thao tác ghi làm phát sinh mọi query trong mọi request cho đến khi có người phát hiện ra.

Không dùng các policy volatile-* cho mục đích này. Các policy này chỉ xét những key có expiry, và Redis ghi rõ rằng chúng hoạt động như noeviction khi không có key nào có expiry. WordPress lưu phần lớn entry của object cache mà không có TTL, nên volatile-lru trên object cache có thể bị đầ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ì policy này evict theo frequency thay vì recency. Hãy chọn một policy có chủ đích và ghi rõ lý do.

Persistence: chỉ bật khi có lý do

redis.conf đi kèm bật RDB snapshot 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ì. Dữ liệu vốn có thể tạo lại, còn 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ị đã stale mà WordPress vẫn tin dùng.

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

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

Và thường có thêm cảnh báo sau khi khởi động. Đây là cách Redis cho biết lần fork sau có khả năng sẽ fail:

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ở thành rỗng.

save ""

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

Chỉ giữ persistence nếu cùng instance lưu dữ liệu không thể rebuild, chẳng hạn job queue hoặc bộ đếm rate limit. Trong trường hợp đó, 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 cần durable phải giữ key. maxmemory và eviction áp dụng cho toàn bộ instance, không chỉ một database index. Chạy hai instance trên hai socket là cách sạch nhất.

Cài plugin và hiểu cơ chế 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 nạp wp-content/object-cache.php từ rất sớm, trước khi bất kỳ code của plugin nào chạy. Nhờ đó, cache có sẵn cho 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 đã sử 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 đang 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 đặt file bằng tay và cấp quyền sở hữu file cho 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 directory của plugin trong khi drop-in vẫn còn, site sẽ tiếp tục chạy code cache cũ mà không có plugin để cập nhật code đó.

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

Thêm các dòng này phía 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ó tác dụng.

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 hết hạn sau khoảng thời gian tính bằng giây. 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 tối đa mà một giá trị trong cache có thể bị stale.

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

Theo mặc định, Redis cung cấp 16 database được đánh số và mỗi database có một keyspace phẳng. Hai WordPress được trỏ vào database 0 mà không có prefix sẽ ghi cùng tên key vào cùng một keyspace. Vì vậy, một site có thể đọc và phân phối các 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 phân tách tên key. Index của database phân tách 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 phân tách bộ nhớ. maxmemory và eviction policy áp dụng cho toàn bộ instance. Vì vậy, một site có nhiều tải có thể đẩy key của site ít tải ra khỏi cache mà không site nào báo lỗi. Các site không được phép ảnh hưởng lẫn nhau cần chạy trên các Redis instance riêng. Mỗi instance có socket riêng và giới hạn bộ nhớ riêng.

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

Một site staging thường là bản sao của file và database production. Điều đó có nghĩa là 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ị 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 là 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 nhưng 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ũ dùng WP_CACHE_KEY_SALT cho việc này. Readme của plugin đánh dấu constant đó là deprecated và đã được thay thế bằng WP_REDIS_PREFIX, vì vậy hãy dùng tên mới.

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

Hãy bắt đầu bằng các công 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 có nghĩa là WordPress đang load file của plugin này. Drop-in: Not installed có nghĩa là thao tác copy chưa từng xảy ra và site không có persistent cache, dù màn hình admin có hiển thị trạng thái màu xanh. Status báo cáo connection, còn Client cho biết extension đang được 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) có nghĩa là core đang giao tiếp với external object cache.

Sau đó, hãy xác nhận key đang được ghi vào, cùng 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 click qua lại trên site là bằng chứng xác thực. Nếu số key bằng 0 dù drop-in hợp lệ, connection đang âm thầm thất bại hoặc prefix không phải giá trị bạn nghĩ.

Cuối cùng, hãy xem các số liệu Redis cung cấp.

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 số liệu, cần lưu ý 2 điểm. 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à application 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 lấp đầy. Hãy để hệ thống chạy qua một ngày có traffic bình thường.

Không so sánh con số của bạn với hit rate hoặc query count do một công ty hosting công bố. Các số đó mô tả site và bộ plugin của họ. Con số cần quan tâm là số liệu 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/

Hãy 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ập ở trên: OOM command not allowed when used memory > 'maxmemory'. xuất hiện trong log, và site phải trả phí cho cả database lẫn cache.

Redis đặt 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ẽ mất nửa giây chờ đợi mà local socket không gặp phải. Hãy giữ Redis trên cùng máy, hoặc trên private network có độ trễ dưới 1 ms. Việc cùng máy tận dụng kernel được bao nhiêu là một vấn đề riêng: cơ chế lập lịch nhận biết cache được thêm trong Linux 7.2 cố gắng giữ các process giao tiếp nhiều như PHP-FPM và Redis trên những core dùng chung một cache, nhưng VPS guest tận dụng được cơ chế này ít hơn bare metal.

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

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ẽ báo thiếu trên một cài đặt hiện đại. Bất kỳ giá trị nào vượt quá một megabyte đều là vấn đề cần xử lý trong options table, không phải trong Redis.

Mỗi lần restart đều xóa toàn bộ dữ liệu, vì vậy vài phút sau systemctl restart redis-server sẽ toàn miss và phát sinh toàn bộ công việc trê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 riêng gây request chậm: chuyển WP-Cron sang system cron job thực sự trong lúc bạn đang xử lý việc này.

Bảo trì

Sau khi deploy thay đổi các option hoặc theme code, 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 từ phiên bản plugin cũ chạy với plugin mới là nguyên nhân thực sự gây ra hành vi bất thường. Theo dõi server đang hoạt động 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à tiêu tốn CPU đáng kể trên instance bận, vì vậy chỉ dùng trong vài giây khi tái hiện sự cố, rồi dừng lệnh.

Một giá trị cuối cùng cần biết là redis-cli info clients, lệnh này báo cáo connected_clients. PHP-FPM giữ một connection cho mỗi worker, vì vậy giá trị đó nên tương ứng với pm.max_children, không cao hơn 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 traffic ẩn danh. Page cache phục vụ HTML đã lưu mà không chạy PHP, luôn tốn ít tài nguyên hơn so với chạy WordPress cùng object cache đã được làm nóng. Object cache xử lý những request mà page cache phải bỏ qua: user đã đăng nhập, giỏ hàng, checkout và wp-admin. Trên shop hoặc membership site, nên chạy cả hai. Với site mà visitor 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 máy của bạn thay vì sao chép một con số. Lấy tổng RAM, trừ MySQL buffer pool và các buffer cho 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 số memory 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 lần ghi mới và trả về OOM command not allowed when used memory > 'maxmemory'., nên WordPress fallback về database cho mọi value, đồng thời vẫn phải chịu 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 thường gặp 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, 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ó, 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 để việc flush một site không xóa dữ liệu của site khác. Phần vẫn dùng chung là memory: maxmemory và eviction áp dụng cho toàn bộ instance, nên site có traffic cao có thể evict key của site ít traffic. Các site không được phép ảnh hưởng lẫn nhau cần dùng Redis instance riêng với limit 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ề cơ chế cache tích hợp theo từng request. Site vẫn hoạt động, nhưng sẽ thực hiện nhiều database query hơn. Nên dùng wp redis disable, lệnh này xóa file sạch sẽ và báo Object cache disabled. Nếu Redis đang down hoặc hoạt động bất thường, đồng thời bạn không thể truy cập admin, xóa file thủ công là biện pháp khẩn cấp phù hợp.