Refatorando o Wordpress para melhorar o desempenho da memória [fechado]

Eu dei uma olhada no consumo de memória do Wordpress. No meu site, parece que, para cada página atingida, 20 MB de RAM são alocados, apenas para preparar um ambiente confortável para a execução de todos os plugins.

Não há um único local para otimizar, nenhum bandido que consome a maior parte da memória. O consumo está espalhado por muitos módulos php.

Como podemos fazer com que o Wordpress inicialize seu ambiente na memória apenas uma vez e depois reutilize-o várias vezes para cada ocorrência? Eu não quero que o PHP lento coma 20 MB a cada clique do usuário - mesmo em um servidor com muita memória, leva segundos para que todo o trabalho seja feito. Basicamente, você precisaria de blocos de memória somente leitura que possam ser reutilizados.

Além disso ... por que 20MB? Alguém pode fornecer informações sobre isso?

Edit: Aqui está a saída WinCacheGrind no Wordpress em execução na minha máquina de desenvolvimento (muito mais rápido que a hospedagem compartilhada). Como você pode ver, são necessários mais de um segundo para produzir o HTML da página principal. Retarde isso com hospedagem compartilhada e você terá uma receita para problemas. Eu escolhi o método que leva a maior parte do tempo. Como você otimizaria isso?

Edit: Aqui estão as estatísticas da consulta desta fantástica ferramenta de criação de funções functions.php .

Carga: 12 consultas - 532ms - 19,1MB - 43 ocorrências em cache / 53
Consulta: 15 consultas - 563ms - 19,0MB - 72 ocorrências em cache / 86
Exibição: 21 consultas - 705ms - 19,2MB - 234 ocorrências de cache / 257

Edit: Você quer ver algo garantido para te assustar? Insira estas linhas no final do index.php:

echo "<pre>\n";
print_r(get_defined_vars());
echo "</pre>\n";

Tentei contar quantas vezes o corpo do post atual está armazenado na memória. Eu contei 20 instâncias. Então eu percebi que o PHP tem contagem de referência, então a quantidade de cópias reduzida para apenas três: duas parecem estar no WP_Query, uma no cache do objeto. Estou investigando mais.

É por isso que acho que o WordPress precisa de refatoração visando os problemas de memória. Você não pode mais culpar o consumo de memória pela simples complexidade do que faz. Simplesmente faz um monte de coisas erradas .

Edit: Depois de um dia tentando descobrir isso, aqui estão as minhas conclusões:

1) 88% de toda a memória vem de exigir ou incluir ou incluir um tipo de chamada:

2) O arquivo php inclui acontece principalmente durante a primeira parte do atendimento de uma solicitação (sem surpresa), que também é onde toda a memória é consumida:

3) É bastante interessante plotar todas as funções que estão sendo executadas durante a solicitação. Existem mais de 12000 chamadas no total. Eu os instalei para torná-lo mais visível (o eixo Level é basicamente a profundidade da pilha):

4) O único caminho a seguir em que consigo pensar é em minimizar a quantidade de arquivos .php incluídos. Se eu dividir as funções por arquivo de onde elas vieram, você poderá ver que muitos arquivos são atingidos uma ou duas vezes, no máximo. Precisamos de uma maneira de pular aqueles quando não são necessários. Por exemplo, meu plug-in de backup de banco de dados remoto é carregado e registrado, apenas para nunca ser usado. Aqui está o gráfico acima dividido pelo nome do arquivo:

Estou oferecendo uma recompensa que vale toda a minha reputação :) por refatorações que levariam a reduzir a pegada de memória dos meus blogs em 30% ou mais.

Edit: Eu instalei o WP 3.1, aqui está a comparação com a versão antiga.

Azul é WP 3.1, vermelho é 3.0.4. O novo WP é mais rápido, mas também consome mais memória.

Aqui está uma lista por arquivo de inclusão.

Isso me permite perceber quanta memória é consumida pelo "All In One SEO pack" - uma avenida seria usar apenas uma fração da funcionalidade do plug-in para obter o que eu quero. Além disso, meus próprios plugins parecem muito ruins.

Eu gostaria de tentar o carregamento condicional em, por exemplo, comment.php (não aceito comentários no meu blog) e vários outros. Eu apaguei todo o código obsoleto. Eu reduzi o kses.php para carregar apenas suas tabelas globais sob demanda. Simplifiquei l10n (não localizo), fazendo com que suas funções retornem as strings imediatamente, sem pesquisas. Ainda estou longe da marca de 30% que estabeleci arbitrariamente.

Editar: baixei e habilitei o APC com configurações padrão (32 MB de cache de código de operação). Aqui está a comparação:

Você pode ver que o carregamento do código acelerou enormemente, e o código também ocupa menos espaço na memória (provavelmente porque lidamos apenas com códigos de operação, não com a fonte original). O consumo de memória ainda é bastante alto.

Não vale a pena. O WordPress não consome muita memória apenas porque. Consome muita memória porque executa muitas funcionalidades sob o capô.

É muito mais fácil e eficiente armazenar em cache os resultados (página gerada) com o plug-in de cache estático e atendê-lo. Dessa forma, a maioria dos visitantes nem sequer acessa o próprio WP.

E é por isso que acho que o WordPress precisa ser reescrito. Você não pode mais culpar o consumo de memória pela simples complexidade do que faz. Simplesmente faz coisas erradas.

Que conclusão ingênua. Leia coisas que você nunca deve fazer, Parte I .

Obrigado pelos gráficos de uso de memória, no entanto.

Muito mais tarde, editar: A Autommatic lançou uma biblioteca chamada prefork que parece fazer o que você está pedindo: carregar o código do WordPress na RAM apenas uma vez.

A partir do WordPress 3.2, o PHP 5.2 será o requisito mínimo. Penso que, com isso, nossos bits podem começar a ser reestruturados e usar classes com carregamento automático. Isso evitaria o carregamento de alguns trechos de código, a menos que fossem realmente necessários. Por exemplo, se não houver incorporações ou galerias em uma visualização de página, poderemos evitar o carregamento de muito código de mídia.

No entanto, mesmo que eles decidam seguir esse caminho, eu esperaria que fosse uma evolução lenta (como muitas das outras mudanças ocultas que ocorreram). Isso exigiria a troca de localizações de muitos arquivos e códigos, o que poderia quebrar o compatibilidade de alguns plugins.

Parte do problema (se é que realmente pode ser chamado assim) é que, sem esse tipo de carregamento condicional, a estrutura principal não pode saber antecipadamente qual funcionalidade precisará ou não para gerar a exibição do conteúdo. Portanto, muitas funções precisam ser carregadas, caso sejam necessárias.

Como podemos fazer com que o Wordpress inicialize seu ambiente na memória apenas uma vez e depois reutilize-o várias vezes para cada ocorrência?

É chamado de cache de código de operação.

http://en.wikipedia.org/wiki/PHP_accelerator

você provavelmente não conseguirá reduzir tanto o uso de memória RAM. Mas se você estiver usando mod_php, poderá mod_fcgidoptar por mudar .

enquanto mod_php é um pouco mais lento, carrega php mesmo quando não é necessário, como servir imagens, arquivos estáticos ou até mesmo cache. Se você tem muitos pedidos, isso é muito ram.

Usar o fcgid reduzirá muito isso.

Além disso, o uso de um cache estático (como o cache w3total) evitará chamar php , o que é uma grande vantagem: menos uso de memória ram, menos conexões de banco de dados.

Ha. Estou trabalhando em um aplicativo Web agora que pretendo sobrecarregar os dados e o uso além do que minha conta de hospedagem compartilhada pode suportar, então eu decidi - embora fosse super fácil de criar no WP - tentar trabalhar a partir do BackPress como uma estrutura e crie apenas o necessário para meus casos de uso específicos.

Portanto, consegui reduzir meu ambiente principal das centenas de arquivos PHP no WP para apenas os vinte necessários, enquanto ainda conseguia aproveitar todo o db, HTTP, gerenciamento de usuários, formatação e cron funções que eu amo no WordPress.

O problema é que é muito trabalhoso, e eu nunca confiaria no meu hackjob por algo além do meu uso pessoal. Se você deseja usar o ambiente WP completo, aceite-o como está. É tão bom quanto é por causa de centenas de desenvolvedores ajustando-o ao longo de vários anos. Como todo mundo aqui disse, você vai muito mais longe, encontrando um melhor plano de hospedagem e pesquisando técnicas de cache do que provavelmente invadindo o núcleo.

Sim, o WordPress carrega tudo primeiro e depois faz o que pedimos. Lembro-me de algum lugar em que podemos criar um pool virtual na RAM, onde podemos colocar arquivos. Tive a ideia de colocar todo o WordPress na memória (<10 MB) e, em seguida, podemos economizar muita E / S, o que por si só deve aumentar a velocidade. Mas nunca tive a chance de experimentá-lo e, além disso, não sou realmente tão proficiente em buscar algo assim. Mas parece que vale a pena tentar.

algumas sugestões básicas:

1. plugin de cache total w3 para armazenamento em cache ..
2. instale e habilite o memcache, também ative as configurações de cache total do w3 (o cache do opcode também é uma boa opção, mas não vai bem com o plugin de cache total do w3)
3. minimizar consultas para direcionar links em arquivos de temas.
4. Desative todos os plugins extras não utilizados e remova-os.
5. otimizar banco de dados.

Eu estou executando um site wordpress bem conhecido com enorme tráfego diariamente .. não estou dedicado mesmo, fazendo muito bem para mim :)