Estratégias de limpeza de cache que economizam memória para sites grandes?

Um dos meus sites do Drupal 7 possui milhares de campos, vários tipos de conteúdo, mais de 25 visualizações e centenas (em breve milhares) de tipos de perfil. Por causa disso, estou usando um patch principal que armazena em cache melhor as informações do campo da entidade (http://drupal.org/node/1040790) e a versão -dev do Views, que armazena melhor as visualizações por exibição (em vez de ter um ENORME linha de cache de visualizações com todos os dados de visualizações).

Isso ajudou a maioria das páginas do site a carregar com 20 a 30 MB de RAM usada, em vez de 160 MB + (em vez de puxar linhas da tabela cache_ * para campos e exibições com mais de 10 MB, os patches ajudam a manter os dados cache_ * muito mais eficientes).

Isso introduz um problema, no entanto, porque as reconstruções de cache demoram muito tempo . Geralmente mais de um minuto ou dois. E durante esse tempo, o Drupal simplesmente não carrega nenhuma página (já que os caches dos quais está tentando ler ainda não foram criados, outras solicitações precisam esperar).

Durante ciclos de baixo tráfego, isso não é grande coisa; uma centena de usuários precisará esperar um minuto antes de a página carregar. Porém, durante ciclos de tráfego intenso, o servidor Apache começa a enlouquecer, com mais de 40 cargas de CPU, e a memória enche rapidamente porque todos os threads de trabalho ficam esperando e aumentam a memória, causando troca. É uma espécie de espiral da morte. Uma reinicialização do httpd esclarecerá as coisas, mas leva de 5 a 10 minutos para que as coisas voltem ao normal.

Meu objetivo é fazer com que a limpeza do cache não traga o site de joelhos. Por um lado, se eu usar as funções individuais de limpeza de cache do admin_menu (como "CSS e JS", "Menu" e "Registro de temas" etc.), as coisas correm bem até eu clicar na opção "Página e outros". É quando o cache das visualizações é redefinido (uma operação muito intensa da CPU e do banco de dados com o número de visualizações que precisam ser armazenadas em cache) e quando o cache de informações do campo é redefinido (que também é intenso na CPU e no banco de dados neste site).

Então ... minhas perguntas / idéias:

• Usando drush e / ou outros scripts de shell, é possível limpar os caches de uma maneira mais inteligente do que "blast todos os caches de uma só vez, e espero uma reconstrução limpa"?
• Posso bloquear solicitações http enquanto a limpeza do cache está acontecendo para que o apache não fique obstruído com várias solicitações de carimbo de cache?
• Se eu puder limpar caches fora da solicitação do Drupal / httpd normal, presumivelmente, eu poderia definir um PHP_limit de memória mais alto para a operação de limpeza de cache e voltar a usar o memory_limit universal (agora definido como 256MB, caso qualquer thread httpd individual precise limpar os caches ...)

Basicamente: existe alguma maneira inteligente e elegante de limpar todos os caches com o Drupal além de simplesmente clicar no botão na interface do usuário ou usar drush cc all?

[ Editar para esclarecimentos : O principal problema que tenho são as reconstruções de cache , que (a) demoram um pouco e (b) bloqueiam todas as outras solicitações até que as reconstruções sejam concluídas. Eu gostaria de encontrar uma maneira de fazer isso para que as reconstruções não sejam tão mortais durante os períodos de tráfego intenso.]

Existe alguma maneira inteligente e elegante de limpar todos os caches com o Drupal além de simplesmente clicar no botão na interface do usuário ou usar o drush cc all?

O módulo de ações de cache faz isso. Depende da regra. Por exemplo, você pode configurar uma regra para limpar uma exibição específica quando um nó do tipo "x" for adicionado ou atualizado. Confira os documentos para obter mais detalhes.

Também dê uma olhada no módulo gracioso do cache - ainda não tentei, mas parece interessante.

O principal problema é que você está usando o MySQL para armazenar dados em cache - para sites de alta carga, essa é uma solução muito ineficaz.

Eu aconselho a usar o Memcache . Isso aumentará drasticamente o desempenho do sistema de cache e fornecerá 2 grandes benefícios:

1. O Memcache é muito mais rápido para operações de leitura e gravação que o MySQL - todas as operações de cache (e reconstrução do cache completo) funcionarão mais rapidamente.
2. Como os dados do cache não são mais armazenados no banco de dados - a limpeza do cache não bloqueará nenhuma outra consulta do MySQL.

Aqui está um exemplo de configuração do Memcache para o Drupal 7.

Usando drush e / ou outros scripts de shell, é possível limpar os caches de uma maneira mais inteligente do que "blast todos os caches de uma só vez, e espero uma reconstrução limpa"?

Se você não deseja destruir todos os caches, use: drush cc type_of_cachepara limpar um específico ou defina seu próprio.

Como alternativa, limpe manualmente todas as tabelas semelhantes a cache, por exemplo

echo "SHOW TABLES LIKE 'cache%'" | $(drush sql-connect) | tail -n +2 | xargs -L1 -I% echo "DELETE FROM %;" | $(drush sql-connect) -v 

Se você estiver usando o memcached (sintaxe do Bash), tente:

pgrep memcached && echo flush_all > /dev/tcp/127.0.0.1/11211

Posso bloquear solicitações http enquanto a limpeza do cache está acontecendo para que o apache não fique obstruído com várias solicitações de carimbo de cache?

Ative o modo de manutenção ( drush -y vset maintenance_mode 1) para impedir que as pessoas acessem o site. Ou configure o front-end para redirecionar para outro lugar (por exemplo, no Varnish, redirecione no Apache ou altere .htaccess).

Se eu puder limpar caches fora da solicitação normal do Drupal / httpd, presumivelmente, poderia definir um PHP mais alto memory_limitpara a operação de limpeza de cache e retirar meu universal memory_limit(agora definido como 256 MB, caso qualquer thread httpd individual precise limpar caches). .).

A limpeza do cache não consome mais memória, mas a reconstrução do cache após a limpeza leva mais. Você sempre pode aquecer os caches executando cron ou abrindo qualquer página, por exemplo

time php -n -d memory_limit=-1 time $(which drush) cc registry
PHP_OPTIONS='-d memory_limit="2G"' drush cron
php -d memory_limit=1G ./scripts/drupal.sh http://localhost/

^{Especifique -npara ignorar o php.iniprocessamento que também pode acelerar o processo de limpeza de cache.}

Existe potencialmente um custo monetário envolvido, mas você pode usar uma configuração de servidor de cache como o Varnish. A vantagem é que o Varnish servirá seu site enquanto o cache estiver sendo limpo no servidor de produção, sem que o usuário seja o mais sábio.

A desvantagem: dependendo de quantos segundos / minutos de tempo de inatividade do servidor de produção e das configurações de tempo limite da VCL, o Varnish pode ser atualizado durante esse período e você verá uma tela de erro do Varnish 503.

Mas essa abordagem, juntamente com Redis ou Memcache, pode ajudar.