Em primeiro lugar, isso não é uma resposta, mas uma abordagem de diagnóstico.
Isso não é de forma alguma abrangente - ou mesmo algo próximo, é apenas um ponto de partida.
Hora do primeiro byte
O tempo até o primeiro byte (TTFB) possui vários componentes:
- Pesquisa de DNS: encontre o endereço IP do domínio (possível melhoria: mais servidores DNS distribuídos / responsivos)
- Tempo de conexão: abra um soquete para o servidor, negocie a conexão (o valor típico deve ser em torno do tempo 'ping' - geralmente é necessário um ida e volta - o keepalive deve ajudar nas solicitações subsequentes)
- Aguardando: o processamento inicial necessário antes que o primeiro byte possa ser enviado (o local onde deve estar sua melhoria - será mais significativo para o conteúdo dinâmico.
Quando você olha para uma saída do ApacheBench, também vê:
- Processamento: é a soma da espera + transferência completa do conteúdo (se o tempo de transferência for significativamente maior do que o esperado para baixar a quantidade de dados recebidos, ocorrerá um processamento adicional (após o primeiro byte recebido) (por exemplo, a página é liberando o conteúdo conforme disponível)
Comparações para eliminar componentes
Com poucas exceções, seu problema está no processamento de back-end, que geralmente se resume a código excessivamente complexo / ineficiente ou MySQL mal configurado.
Uma boa maneira de abordar esse problema é através de uma série de comparações que eliminam vários aspectos da sua instalação. Uma boa comparação deve manter-se o mais constante possível para ajudar a diminuir o problema. Atualmente, você forneceu as seguintes comparações:
- Site idêntico (clonado) em execução no servidor antigo e no novo servidor:
- Diferença: Servidor
- Resultado: o servidor antigo é rápido; novo servidor está lento
- Notas: O que você precisa aqui é quantificar as diferenças entre esses servidores - tanto em termos da pilha usada (Nginx, etc) quanto do hardware (o servidor antigo é mais rápido porque é uma máquina mais poderosa?)
- Conclusão: o código pode ser executado rapidamente na configuração correta
- Site de teste x site completo no novo servidor
- Diferença: conteúdo, temas, plugins, etc
- Resultado: o site de teste é rápido, o site completo é lento
- Notas: em teoria, esse teste deve ajudá-lo a eliminar muitos aspectos da sua configuração - DNS, rede, até mesmo a sua configuração nginx / php / mysql - no entanto, não é muito "justo".
- Conclusão: o conteúdo extra está tendo um impacto significativo no desempenho
O teste ideal faria você duplicar seu site completo, mas excluir todo o conteúdo, exceto um artigo e os comentários associados. O objetivo deste teste seria determinar conclusivamente se a grande quantidade de conteúdo é o problema ou se outros aspectos de sua configuração (plugins wordpress, tema, etc.) são a causa. Você compararia essencialmente o desempenho de sites idênticos, no mesmo servidor (novo) - carregando a mesma página (mesmo comprimento etc.) - com a única diferença no conteúdo total do site (por exemplo, há uma boa chance de que algum plug-in não dimensionar bem com o aumento do conteúdo).
Sem alterar nada, existem outras comparações que você pode fazer:
- Teste de um local remoto versus local - isso ajudará a identificar se a rede, latência, DNS, etc. é a causa
- Você já (um pouco) fez isso e principalmente concluiu que não tem um problema de rede.
- Teste via Varnish (porta 80) vs nginx diretamente (porta 8080) - tente não alterar sua configuração entre os testes - use a porta correta. Isso mostrará o impacto do verniz. Como o Varnish é uma camada de armazenamento em cache, ele deve atender a todas as solicitações após a primeira muito rapidamente - essencialmente, deve ignorar o back-end e o processamento necessário para gerar uma página dinâmica e servir a cópia em cache muito rapidamente.
- Você fez isso (embora não localmente) e demonstrou que o verniz tem um impacto positivo significativo no seu desempenho.
Ajustando seu back-end
A essa altura, você já deve ter encontrado o problema ou concluído que está no seu back-end. Isso deixa você Nginx, PHP ou MySQL.
(Devo mencionar aqui, que é sempre útil saber se o seu gargalo é CPU, RAM, ou I / O - entre sar, top, iostat, vmstat, free., Etc você deve ser capaz de chegar a alguma conclusão sobre isso)
Nginx
O Nginx está apenas recebendo solicitações e servindo conteúdo estático ou transferindo as solicitações para PHP-FPM - geralmente não há muito o que otimizar com o Nginx.
- Definir trabalhadores = # núcleos da CPU
- Ativar keepalive (um valor entre 10 e 15 é bom)
- Desativar registro desnecessário
- Aumente o tamanho do buffer, se necessário
- Evite as instruções if (use nomes estáticos em vez de expressões regulares sempre que possível, elimine extensões desnecessárias)
Idealmente, o seu blog de teste e o blog clonado têm configurações idênticas; nesse caso, você efetivamente eliminou o Nginx como o problema.
Inscrição
No caso em que você está tentando identificar um problema no seu código (por exemplo, um plug-in lento, etc.), os logs lentos são o ponto de partida.
- Habilite o log lento do MySQL e o log lento do PHP-FPM execute seu benchmark e veja o que está acontecendo como lento.
MySQL
- Aumente seus caches e execute mysqltuner.pl para obter um bom ponto de partida.
PHP
- desativar extensões desnecessárias,
- desabilite register_globals, magic_quotes_ *, expose_php, register_argc_argv, always_populate_raw_post_data
- aumentar o memory_limit
- open_basedir e safe_mode têm implicações significativas de desempenho, mas também podem fornecer uma camada adicional de defesa. Teste com e sem eles, para determinar se o impacto no desempenho é tolerável.
PHP-FPM
- Ajuste os valores pm. * - aumente-os para lidar com alta carga
Vale ressaltar que os resultados de seu htop mostram php-fpm consumindo a maior parte da CPU - e seu problema parece estar diretamente relacionado a isso.
Armazenamento em cache
Depois de otimizar cada provável gargalo, inicie o cache.
- Você já possui um cache opCode (APC) - verifique se ele está funcionando (vem com um arquivo de teste) - verifique as taxas de acertos do cache e, se possível, tenha o cache do APC na memória em vez de no disco.
- Configure seu código para armazenar em cache (por exemplo, usando um plugin para Wordpress, como o W3TC)
- Com o nginx, você pode configurar o cache do FastCGI - mas como você tem o Varnish, é melhor evitar isso.
- Configure uma camada de armazenamento em cache, como o Varnish (que você já fez) - e garanta que ela esteja funcionando (por exemplo, use varnishstat, leia Alcançando um alto Hitrate )
- Adicione mais cache aos componentes do seu site - por exemplo, MemCached, se aplicável
Às vezes, dadas as limitações de seu aplicativo e hardware, talvez você não consiga melhorar o desempenho do back-end - no entanto, esse é o ponto do cache - para minimizar o uso do back-end.
Leitura adicional
if -fdiretiva que você está usando nolocationcontêiner na configuração do nginx. Com base no que estou lendo aqui , wiki.nginx.org/Pitfalls , sinto que-festá fazendo uma pesquisa ineficiente pelo arquivo, o que poderia causar um problema de tempo até o primeiro byte, especialmente se você tiver diretórios com um grande número de arquivos.