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.]