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.]
Pergunta interessante. Se você desativar o cache, o desempenho do seu site é adequado? IOW, você otimizou o Apache / PHP / MySQL para rodar tão bem quanto pode sem o cache ativado? Obviamente, eu não vi seu sistema, mas definir apc.stat = 0 e garantir que você tenha memória suficiente para a APC ajudará a reduzir o uso do disco. O uso do mysqltuner.pl também dará uma indicação se o MySQL é o gargalo. Em seguida, você pode ativar o cache e ajustar (isso aumentará o uso de banco de dados, portanto, pode ser necessário ajustar os parâmetros do MySQL).
Uso Redis (semelhante ao memcache) para manter as exibições em cache das tabelas na memória. Isso melhorou drasticamente os tempos de carregamento. Ansioso para ter o recurso "exibições em cache por exibição" em uma versão estável, isso faz muito sentido.
@MPD - Desabilitar o cache mataria rapidamente o site inteiro; normalmente 100-500 usuários autenticados, e algumas seções do site são bastante pesadas. O maior problema para mim não são as leituras de cache (experimentei o cache do usuário Memcached, Redis e APC para isso), mas a reconstrução do cache, que requer muita CPU.
— amigos estão dizendo sobre geerlingguy
Idealmente, você deseja usar dados antigos do cache enquanto o novo cache está sendo reconstruído. Isso está correto?
@ mikeytown2 - correto - esse seria o ideal.
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.
Já estou usando drush cc [type]a limpeza de cache específica (semelhante às ações de cache), mas estou mais interessada em encontrar maneiras de limpar o cache de maneira mais elegante e garantir que outros threads httpd não estejam matando o servidor Apache.
parece que drush cc limpará todos os caches das visualizações. Com ações de cache, você pode simplesmente limpar uma exibição ou exibição específica. Provavelmente existe um erro na versão dev do views, caso contrário não levaria um minuto ou dois para reconstruir os caches. Você tem o mesmo problema ao usar as visualizações 7.x-3.5? Também dê uma olhada drupal.org/project/cache_graceful - não tentei ainda, mas parece interessante
O views dev divide as exibições da view em suas próprias linhas de cache, para ajudar no desempenho de leitura do cache. Isso significa que as visualizações gastam provavelmente 5x mais tempo na criação do cache (mas isso ajuda a reduzir o uso de memória ao ler muito os caches!).
Você poderia adicionar as informações sobre o Cache Graceful à sua resposta original? Aceito, pois esse módulo em particular ajuda um pouco (mas não resolve o problema totalmente para mim). Acho que vou ter que fazer uma pequena pesquisa no site para usar menos campos e tipos de entidade para realmente resolver meu problema.
Está bem. Gostaria de saber sobre sua experiência com cache_graceful. Que parte não consertou?
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:
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.
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.
Eu usei o memcached e o APC de várias maneiras e, embora eles ajudem bastante nas leituras de cache, o principal problema que tenho é a reconstrução real; o banco de dados não está fazendo quase nada enquanto o servidor da web está carimbando o cache durante o processo de reconstrução (muito lento / longo).
A APC e o Memcached fazem coisas diferentes. Eu acho que a configuração correta do Memcached o ajudará. Aliás, se o site for visitado principalmente por usuários anônimos - você pode usar o Varnish. Nesse caso, o Varnish usará seu próprio sistema de cache e o Apache não será executado para solicitações anônimas.
— Eugene Fidelin 15/11/2012
O site tem quase 100% de tráfego autenticado, caso contrário, eu consideraria usar o Varnish. Eu posso olhar para o módulo Cache Graceful neste momento.
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
Se você estiver usando o memcached (sintaxe do Bash), tente:
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
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.
Esta questão refere-se apenas aos caches internos do Drupal; a reconstrução dos caches do Drupal demorou uma eternidade, e camadas adicionais de cache fora / na frente do Drupal não ajudariam muito na reconstrução dos dados do cache (além de descarregar algum tráfego que o servidor da web precisaria manter um pouco enquanto os caches são reconstruídos).