Armazenando em cache o bootstrap do Drupal

Estou curioso para saber se alguém tentou "armazenar em cache" o processo de inicialização no Drupal.

Normalmente, o Drupal executará as 7 fases de inicialização em cada solicitação, mas talvez em um sistema de produção implantado, seja possível "eliminar" algumas ou todas elas?

Possíveis sugestões que tenho em mente podem ser

1. Serializando o estado de inicialização e colando-o no memcache
2. Um script pode gerar um patch para o bootstrap.inc que codificará determinadas informações no arquivo.
3. Acredito que David Strauss tentou manter um Drupal com bootstrap rodando no libevent.
4. Outra loucura?

Que tentativas existem e quais são conhecidas como (um pouco) confiáveis?

PHP é uma arquitetura de nada compartilhado. Isso tem suas vantagens e desvantagens.

Uma desvantagem é que não é fácil fazer algo assim. Não há muito estado que possa ser armazenado em algum lugar.

Fiz alguns testes rápidos e, quando logado, o boostrap parece demorar cerca de 17% do tempo total e mais de 50% disso na verdade está carregando todos os arquivos .module e .inc. Isso não é algo que você pode armazenar no memcache. Além disso, não parece importar muito se eu usar o memcache ou o cache do banco de dados.

Tentei obter alguns resultados ao ativar o cache da página, mas o Xhprof não parece retornar resultados confiáveis; a coisa toda simplesmente parece ser muito rápida. Mas mesmo assim, a maior parte envolve a execução de ganchos de inicialização / saída e o carregamento de arquivos que parece. Encontrei um problema interessante: parece que o módulo Usuário está reduzindo a velocidade da resposta da página em cache porque aciona o registro devido ao controlador de entidade no arquivo .module.

Dito isto, David Strauss mostrou alguns trabalhos experimentais em Copenhague, onde criou um instantâneo de memória após a inicialização e depois retornou a ele assim que a página foi veiculada. Ele usou o Drupal 6 para isso. Depois de analisar os números acima, imagino que os ganhos de desempenho ao fazer isso no Drupal 7 seriam um pouco menores. Uma razão para isso é que a conexão com o banco de dados é lenta (e você pode ir muito longe no bootstrap ao usar, por exemplo, o Memcache antes de precisar executar a primeira consulta) e há muito em cache.

O que é realmente ruim no Drupal 7 é a camada de renderização com essas enormes matrizes e infinitas recursões e loops. Isso desfaz praticamente todo o trabalho de desempenho que foi feito no Drupal 7. Vamos ver como fica no Drupal 8, se o Twig faz parte do núcleo.

Por fim, sobre as vantagens mencionadas. Uma grande vantagem é que os alhos franceses da memória são irrelevantes porque tudo é liberado após cada solicitação. Eu já vi muitos aplicativos Java em que o uso da memória aumenta constantemente e precisa de reinicializações regulares.

Não, foi David Strauss que estava experimentando o kargo-event (agora chamado Kellner) em https://code.launchpad.net/~fourkitchens/pressflow/6-evented, mas duvido que algo sério tenha surgido.

Drupal 7 faz ter um monte de inicialização já em cache, há uma cache_bootstrapbin para isso. Você pode colocá-lo no memcached.

Você pode exagerar e diminuir o carregamento de código movendo alguns códigos do Drupal para C. Damien e dhthwy criaram a extensão PHP em http://drupal.org/project/drupal_php_ext, mas não há muito o que fazer. Ou faça hiphop. Não conheço o estado atual do hiphop & Drupal 7.

No final do dia, no entanto, é preciso analisar bem os custos de engenharia, digamos, de trabalhar hiphop com o Drupal 7 (e todo o contrib!) E compará-lo com o aluguel de mais alguns servidores. Se você pode economizar, digamos 5% dos seus servidores e você possui 100.000 servidores, vá em frente, mas você é o Facebook? Seja cuidadoso e econômico com otimizações.

Vi uma apresentação interessante sobre o doh (Dynamic Object Handler) no encontro do High Performance Drupal . Em resumo, ele fala sobre como iniciar o drupal rapidamente usando-o. Fica interessante em torno da marca das 15:30. Autoload em esteróides em curto com runkit funcionalmente bem. Controle de qualidade na marca das 33:00.