Cache de objetos Redis para WordPress em um VPS

O que faz um cache de objetos Redis para WordPress

Um cache de objetos Redis para WordPress armazena em memória os resultados das consultas à base de dados. Assim, o pedido seguinte lê esses resultados a partir do Redis, em vez de consultar novamente o MySQL. O WordPress já inclui um cache de objetos no core, WP_Object_Cache, mas este fica na memória do PHP e é eliminado quando o pedido termina. Um ficheiro drop-in substitui-o por um cache que comunica com o Redis, permitindo que os dados persistam entre pedidos.

O cache de objetos não é um cache de páginas. Esta diferença determina se vale a pena seguir este guia. Um cache de páginas armazena o HTML final de um URL e volta a servi-lo sem executar o PHP. É mais rápido do que qualquer solução baseada em Redis e funciona para visitantes que não têm sessão iniciada. Quando alguém inicia sessão, adiciona um artigo ao carrinho ou abre o painel de administração, o cache de páginas deixa de ser utilizado e o WordPress processa o pedido completo: bootstrap, plugins e consultas. Um cache de objetos torna esse pedido mais barato. É a ferramenta adequada para o tráfego que um cache de páginas não consegue abranger: sessões autenticadas, carrinhos, checkout e wp-admin. Numa loja WooCommerce, esse é o tráfego mais dispendioso.

As duas soluções funcionam em conjunto e, num site com muito tráfego, ambas são necessárias. Identifique claramente o problema que está a corrigir. Um site institucional com leitores anónimos obtém quase todo o seu desempenho de um cache de páginas. Adicionar Redis a esse site produz poucas alterações.

Existe uma limitação importante. Um cache de objetos não torna rápida uma consulta lenta. Remove a repetição de uma consulta que já foi executada. O primeiro pedido depois de uma falha de cache paga o custo total. Por isso, um plugin que execute uma consulta sem índice continuará a executá-la uma vez durante cada período de vida do cache.

O que é necessário primeiro

• Uma VPS Linux com shell e sudo. Não é necessário ter um painel de controlo.
• WordPress servido por PHP-FPM, por exemplo, numa stack LAMP no Ubuntu 24.04.
• WP-CLI instalado no servidor. Todos os passos têm um equivalente no painel de administração, mas a versão na shell é mais rápida.
• Redis na mesma máquina que o PHP. A latência é o objetivo principal, e um salto de rede elimina essa vantagem.

Os comandos abaixo foram escritos para Ubuntu 24.04 com PHP 8.3 e o utilizador web www-data. Ajuste a versão do PHP e o utilizador ao seu servidor. Execute os comandos wp a partir do diretório do WordPress, que contém wp-config.php.

Instale o Redis e a extensão do PHP

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

redis-cli ping deve responder PONG. Se apresentar Could not connect to Redis at 127.0.0.1:6379: Connection refused, o servidor não está em execução. Consulte systemctl status redis-server antes de continuar.

php-redis é o PhpRedis, a extensão C do PECL. É mais rápido do que o Predis, que é escrito apenas em PHP, e o plugin utiliza-o automaticamente quando está disponível. O PHP-FPM carrega as extensões ao iniciar. Por isso, uma nova extensão só fica disponível depois de reiniciar o pool.

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

Tenha cuidado com essa última verificação: php -m lista os módulos do PHP da linha de comandos, e o FPM pode carregar um conjunto diferente. A verificação relevante é a dos diagnósticos do próprio plugin, apresentados mais abaixo.

Em agosto de 2026, o Ubuntu 24.04 fornece o Redis 7.0.15, que é adequado para uma cache de objetos. Se quiser uma versão atual, o Redis disponibiliza o seu próprio repositório APT.

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

Se a sua distribuição fornecer o Valkey, o fork iniciado depois da alteração da licença em 2024, este utiliza o mesmo protocolo e tudo o que segue se aplica sem alterações.

Vincule o Redis para que nada mais consiga aceder a ele

O Redis não tem palavra-passe por predefinição. Qualquer sistema que consiga abrir uma ligação à porta 6379 pode ler todos os valores em cache e executar FLUSHALL. As instâncias expostas à Internet são encontradas por scanners em poucas horas, por isso a configuração de rede vem antes do ajuste de desempenho.

Abra /etc/redis/redis.conf e confirme estas linhas:

bind 127.0.0.1 -::1
protected-mode yes

Depois, verifique o que está realmente a escutar, porque o ficheiro de configuração é apenas uma declaração e ss é a prova.

sudo ss -lntp | grep 6379

127.0.0.1:6379 é o resultado pretendido. 0.0.0.0:6379 significa que o Redis está a responder na interface pública: corrija a linha bind e reinicie o serviço.

Quando o PHP e o Redis estão no mesmo servidor, um socket Unix é melhor do que TCP através do loopback. Não há uma pilha TCP no caminho, e o acesso é controlado pelas permissões do ficheiro, em vez de uma regra de firewall que pode ser alterada mais tarde.

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

O socket pertence ao utilizador e grupo redis, por isso o utilizador do serviço web tem de ser adicionado a esse grupo.

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

Esse comando também tem de apresentar PONG. Could not connect to Redis at /run/redis/redis-server.sock: Permission denied significa que o grupo não foi aplicado. Verifique id www-data e lembre-se de que um processo PHP-FPM em execução mantém os grupos que tinha no arranque, razão pela qual o reinício aparece na lista. Mantenha o TCP ativado até confirmar que o socket funciona; caso contrário, um erro de digitação pode remover os dois caminhos ao mesmo tempo.

Quanto de memória o Redis deve receber?

Calcule o valor com base no seu próprio servidor. O Redis sem maxmemory cresce até o kernel ficar sem memória e o OOM killer encerrar um processo, normalmente o maior. Num servidor WordPress, esse processo costuma ser o MySQL. journalctl -k | grep -i "out of memory" mostra esse encerramento depois de ele ocorrer, mas nessa altura o site já está indisponível.

Comece pela RAM total e faça as deduções. O MySQL ou MariaDB reserva innodb_buffer_pool_size, além dos buffers por ligação. O PHP-FPM consome pm.max_children multiplicado pelo tamanho residente real de um worker, normalmente entre 64 MB e 128 MB num site com muitos plugins. O kernel e o servidor Web precisam de algumas centenas de megabytes. O que sobra é o seu limite máximo, e o Redis recebe uma parte dele.

Agora faça medições em vez de adivinhar. Depois de um dia de tráfego real:

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

Se used_memory_human ficar bem abaixo do seu limite, reduza o limite e devolva a RAM ao MySQL, que a utilizará melhor. Se atingir o limite e evicted_keys continuar a aumentar durante todo o dia, aumente-o. Defina o valor em /etc/redis/redis.conf.

maxmemory 256mb
maxmemory-policy allkeys-lru

redis-cli config set maxmemory 256mb aplica-se imediatamente e é perdido no reinício seguinte, a mesma armadilha que um sysctl -w isolado. Edite o ficheiro, depois execute sudo systemctl restart redis-server e leia novamente o valor. Vale a pena ter um segundo limite: um limite MemoryMax na unidade systemd impede que um Redis mal configurado derrube o servidor. Defina-o acima de maxmemory, nunca com o mesmo valor, porque um limite de cgroup encerra o processo em vez de expulsar uma chave. Se o Redis for executado num contentor junto do WordPress, o mesmo valor deve ser definido em os limites de memória no seu ficheiro Compose, e o mesmo raciocínio orienta a escolha entre executar a base de dados no Docker ou no host.

Escolha conscientemente a política de expulsão

Uma instalação nova do Redis usa noeviction por predefinição. Verifique a sua:

redis-cli config get maxmemory-policy

Com noeviction, uma instância cheia deixa de aceitar escritas e responde com isto:

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

Essa única linha representa o pior modo de falha neste guia, porque o site não fica indisponível. Fica mais lento. Todas as escritas na cache falham, pelo que o WordPress volta à base de dados para obter o valor, tenta armazená-lo novamente no pedido seguinte e falha outra vez. O site passa a suportar todo o trabalho original da base de dados mais uma ida e volta ao Redis por cada chave. Nada na administração do WordPress indica que isto está a acontecer. A mensagem aparece no log de erros do PHP, por isso procure OOM command not allowed com grep quando um site ficar mais lento depois de adicionar uma cache.

allkeys-lru é a predefinição correta neste caso. O Redis remove a chave usada menos recentemente quando a memória fica limitada. É exatamente isso que uma cache de objetos precisa, porque cada valor armazenado é uma cópia de dados que continuam a existir no MySQL. Perder uma chave custa uma consulta. Recusar uma escrita custa todas as consultas, em todos os pedidos, até alguém detetar o problema.

Evite as políticas volatile-* para esta finalidade. Só consideram chaves que têm uma expiração, e a documentação do Redis indica que se comportam como noeviction quando nenhuma chave tem uma. O WordPress armazena a maioria das entradas da cache de objetos sem TTL, pelo que volatile-lru numa cache de objetos pode ficar cheia e começar a recusar escritas. allkeys-lfu é uma alternativa razoável se o tráfego atingir muitas vezes um conjunto pequeno de chaves, porque remove chaves com base na frequência em vez da recência. Escolha uma política deliberadamente e registe o motivo.

Persistência: mantenha-a desativada, exceto se houver uma razão

O redis.conf fornecido pelo pacote ativa snapshots RDB com linhas como save 900 1 e mantém o ficheiro append-only desativado. Numa cache de objetos pura, os snapshots não trazem benefícios. Os dados podem ser regenerados por definição, e uma cache restaurada a partir de um ficheiro com vinte minutos contém valores obsoletos que o WordPress irá aceitar.

Os snapshots também têm um custo. BGSAVE cria um fork do processo, e o copy-on-write pode aumentar bastante o consumo de memória enquanto o processo filho escreve. Num VPS pequeno, isto aparece no log do Redis:

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

e muitas vezes também surge este aviso no arranque. O Redis está a indicar que é provável que o fork falhe mais tarde:

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

Para desativar os snapshots, defina uma agenda save vazia em /etc/redis/redis.conf, reinicie e confirme que o valor voltou a ficar vazio.

save ""

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

Mantenha a persistência apenas se a mesma instância armazenar algo que não possa ser reconstruído, como uma fila de tarefas ou contadores de limite de pedidos. Nesse caso, separe os dois usos. Uma cache precisa que as chaves sejam removidas por eviction, enquanto os dados persistentes precisam que as chaves sejam mantidas. maxmemory e a eviction aplicam-se à instância inteira, não a um índice de base de dados específico. Duas instâncias em dois sockets são a solução mais simples.

Instale o plugin e compreenda o drop-in

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

wp redis enable imprime Object cache enabled. em caso de sucesso. Na prática, copia wp-content/plugins/redis-cache/includes/object-cache.php para wp-content/object-cache.php. Essa cópia é o drop-in, e é o drop-in que executa o trabalho. O WordPress carrega wp-content/object-cache.php muito cedo, antes de qualquer código de plugin ser executado. É assim que a cache fica disponível durante todo o pedido. Um plugin ativo sem um drop-in instalado não armazena nada em cache.

As mensagens de erro indicam qual das duas partes falhou. Object cache could not be enabled. significa que a cópia falhou. Nesse caso, wp-content não tem permissões de escrita para o utilizador que executa o WP-CLI. A foreign object cache drop-in was found. significa que outro plugin de cache já utiliza esse nome de ficheiro. A correção é wp redis update-dropin. Uma mensagem terminada em Redis server is unreachable:, seguida pelo erro do cliente, significa que as definições de ligação estão erradas. Volte a redis-cli ping.

Se a cópia falhar por causa das permissões, coloque o ficheiro manualmente e atribua-o ao utilizador do servidor Web.

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

Remover o plugin não remove o drop-in. Execute primeiro wp redis disable. O comando imprime Object cache disabled. e elimina o ficheiro. Se eliminar o diretório do plugin enquanto o drop-in permanece instalado, o site continua a executar código de cache antigo, sem um plugin para o atualizar.

Configurações de ligação em wp-config.php

Adicione estas definições acima da linha que contém /* That's all, stop editing! */, porque as constantes definidas depois dela são aplicadas demasiado tarde.

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

Para o socket Unix, defina o esquema e o caminho. O host e a porta são ignorados.

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

WP_REDIS_MAXTTL força uma expiração em cada chave, em segundos. Não precisa desta opção com allkeys-lru. É útil se quiser impor um limite máximo absoluto para a antiguidade de um valor colocado em cache.

Um Redis, vários sites: prefixos e bases de dados

O Redis fornece dezasseis bases de dados numeradas por predefinição, cada uma com um espaço de chaves plano. Duas instalações do WordPress apontadas para a base de dados 0, sem prefixo, escrevem os mesmos nomes de chaves no mesmo espaço. Assim, um site pode ler as opções do outro e apresentá-las. Atribua a cada site o seu próprio prefixo.

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

O prefixo separa os nomes das chaves. O índice da base de dados separa os espaços de chaves, o que é importante ao esvaziar uma base: limpar um índice não afeta os restantes. O plugin também documenta WP_REDIS_SELECTIVE_FLUSH, que elimina apenas as chaves correspondentes ao seu prefixo, em vez de eliminar toda a base de dados, mas precisa de as procurar.

Os prefixos e os índices não separam a memória. maxmemory e a política de expulsão aplicam-se à instância inteira. Por isso, um site com muita atividade pode expulsar as chaves de um site pouco utilizado, sem que nenhum dos dois o indique. Os sites que não podem afetar-se mutuamente precisam de instâncias Redis separadas, cada uma com o seu próprio socket e o seu próprio limite.

Mantenha o staging fora do cache de produção

Um site de staging normalmente é uma cópia dos ficheiros e da base de dados de produção. Isto significa que também é uma cópia de wp-config.php, com o mesmo prefixo e o mesmo índice da base de dados. Se apontar para o mesmo Redis, o staging escreve chaves de produção com valores de staging. Um preço de teste ou uma opção alterada aparece então no site em produção, sem deploy nem registo.

Separe cada ambiente manualmente. Em wp-config.php do staging:

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

Melhor ainda, atribua ao staging uma instância própria do Redis ou não use cache de objetos. define( 'WP_REDIS_DISABLED', true ); desativa o cache em tempo de execução e mantém o drop-in instalado. Esta é também a forma mais rápida de confirmar se um problema é ou não causado pelo cache.

Tutoriais antigos definem WP_CACHE_KEY_SALT para este fim. O readme do plugin marca essa constante como obsoleta e indica WP_REDIS_PREFIX como substituta. Use, portanto, o nome novo.

Verifique em vez de confiar

Comece pelos diagnósticos do próprio plugin.

wp redis status

A linha mais importante é Drop-in. Drop-in: Valid significa que o WordPress está a carregar o ficheiro deste plugin. Drop-in: Not installed significa que a cópia nunca foi feita e que o site não tem cache persistente, por muito verde que esteja o ecrã de administração. Status informa sobre a ligação, e Client identifica a extensão em utilização. É aí que confirma PhpRedis em vez de Predis.

Depois, consulte diretamente o núcleo do WordPress, porque ele não depende do que o plugin indica.

wp eval 'var_dump( wp_using_ext_object_cache() );'

bool(true) significa que o núcleo está a comunicar com uma cache de objetos externa.

Em seguida, confirme que as chaves estão a ser criadas, usando o prefixo que configurou.

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

O aumento de dbsize enquanto navega pelo site é a prova. Zero chaves com um drop-in válido significa que a ligação está a falhar silenciosamente ou que o prefixo não é o que pensa.

Por fim, consulte as métricas que o Redis fornece.

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

A taxa de acertos é keyspace_hits / (keyspace_hits + keyspace_misses), e a documentação do Redis apresenta essa fórmula. Interprete-a com duas cautelas. Os contadores abrangem toda a instância desde o último reinício, por isso combinam todos os sites e aplicações que a partilham. Além disso, a taxa imediatamente depois de uma limpeza ou de um reinício não significa nada, porque a cache ainda está a ser preenchida. Deixe o sistema funcionar durante um dia normal de tráfego.

Não compare o seu valor com uma taxa de acertos ou uma contagem de consultas publicada por uma empresa de alojamento. Esses valores descrevem os sites e o conjunto de plugins dessa empresa. O valor relevante é o seu, medido antes e depois numa página que uma cache de páginas não consiga servir.

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

Execute esse teste com um cookie jar de sessão iniciada, várias vezes, primeiro com a cache desativada (WP_REDIS_DISABLED) e depois ativada. Essa diferença é o seu resultado.

Quando o Redis torna o WordPress mais lento

Uma instância completa com a política errada é o principal problema, já abordado acima: OOM command not allowed when used memory > 'maxmemory'. no log, e um site que paga tanto pela base de dados como pela cache.

Ter o Redis noutro host é o segundo problema. O WordPress faz centenas de chamadas à cache de objetos num único pedido. Se um pedido fizer 500 chamadas e cada ida e volta custar 1 ms, isso representa meio segundo de espera que um socket local não teria. Mantenha o Redis no mesmo servidor ou numa rede privada com latência inferior a 1 ms.

Uma tabela de opções carregadas automaticamente demasiado grande é o terceiro problema, e é comum em sites antigos. O WordPress coloca todas as opções carregadas automaticamente numa única chave da cache. Assim, um megabyte de dados atravessa a ligação em cada pedido. Meça o tamanho:

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

O WordPress 6.6 adicionou novos valores de carregamento automático, pelo que uma consulta antiga que corresponda apenas a 'yes' apresenta valores inferiores aos reais numa instalação moderna. Qualquer valor superior a um megabyte é um problema a corrigir na tabela de opções, não no Redis.

Um reinício esvazia tudo. Por isso, os minutos depois de systemctl restart redis-server contêm apenas falhas de cache e trabalho da base de dados. Reinicie quando o tráfego for reduzido. Além disso, uma cache de objetos não impede que wp-cron.php seja executado durante o carregamento das páginas pelos visitantes. Esta é outra fonte de pedidos lentos: mova o WP-Cron para uma tarefa cron real do sistema enquanto estiver a corrigir isto.

Limpeza

Limpe o cache depois de uma implantação que altere opções ou código do tema com wp cache flush. Execute wp redis update-dropin depois de atualizar um plugin se o drop-in não tiver sido atualizado automaticamente, porque um drop-in de uma versão antiga do plugin usado com uma versão mais recente é uma fonte real de comportamento inesperado. Monitorize um servidor ativo com redis-cli --stat, que mostra uma linha por segundo. redis-cli monitor mostra todos os comandos e consome CPU de forma significativa numa instância ocupada. Por isso, use-o durante alguns segundos enquanto reproduz um problema e pare-o em seguida.

Há mais um número que vale a pena conhecer: redis-cli info clients mostra connected_clients. O PHP-FPM mantém uma ligação por worker, por isso esse valor deve acompanhar o seu pm.max_children, sem o exceder em uma ordem de grandeza. Se isso acontecer, há algo a abrir ligações sem as fechar.

FAQ

Ainda preciso de um cache de páginas se usar um cache de objetos Redis?

Sim, para tráfego anónimo. Um cache de páginas entrega HTML armazenado sem executar PHP, o que é sempre mais barato do que executar o WordPress com um cache de objetos aquecido. O cache de objetos trata os pedidos que um cache de páginas tem de ignorar: utilizadores autenticados, carrinhos, checkout e wp-admin. Numa loja ou num site de membros, vale a pena usar ambos. Num site cujos visitantes nunca iniciam sessão, o cache de páginas faz praticamente todo o trabalho.

Quanta memória devo atribuir ao Redis para o WordPress?

Calcule o valor com base no seu próprio servidor, em vez de copiar um número. Pegue na RAM total, subtraia o buffer pool do MySQL e os buffers por ligação, subtraia pm.max_children multiplicado pelo tamanho residente de um worker PHP-FPM e subtraia algumas centenas de megabytes para o kernel e o servidor Web. Atribua ao Redis parte do que resta. Depois, verifique used_memory_human em redis-cli info memory após um dia de tráfego e ajuste o valor. Um único site WordPress normalmente estabiliza em dezenas de megabytes, por isso um maxmemory de 256 MB é um ponto de partida generoso num servidor com 4 GB.

Porque é que o meu site ficou mais lento depois de ativar o cache de objetos Redis?

A causa habitual é uma instância cheia a usar a política noeviction. O Redis recusa novas escritas e devolve OOM command not allowed when used memory > 'maxmemory'.. O WordPress recorre então à base de dados para cada valor e, além disso, suporta uma ida e volta desnecessária ao Redis. Verifique redis-cli config get maxmemory-policy, defina allkeys-lru e confirme que maxmemory não é demasiado baixo. As outras causas comuns são um servidor Redis num host remoto, onde centenas de idas e voltas por pedido se acumulam, e um valor de opções carregado automaticamente com vários megabytes que atravessa a ligação em cada pedido.

Vários sites WordPress podem partilhar um servidor Redis?

Podem, mas é necessário ter cuidado. Atribua a cada site um WP_REDIS_PREFIX exclusivo para impedir colisões entre nomes de chaves e um índice WP_REDIS_DATABASE separado para que limpar um site não esvazie o outro. O que continuam a partilhar é a memória: maxmemory e a expulsão aplicam-se à instância inteira, por isso um site com muita atividade pode expulsar as chaves de um site pouco ativo. Os sites que não podem afetar-se mutuamente precisam de instâncias Redis separadas, com os seus próprios limites.

É seguro eliminar wp-content/object-cache.php?

Sim. É um drop-in, não faz parte do núcleo do WordPress, e removê-lo faz o WordPress voltar ao seu cache integrado por pedido. O site continua a funcionar e simplesmente executa mais consultas à base de dados. Prefira wp redis disable, que elimina o ficheiro de forma limpa e comunica Object cache disabled.. Eliminá-lo manualmente é a medida de emergência correta se o Redis estiver indisponível ou com comportamento incorreto e não conseguir aceder ao painel de administração.