Meu servidor de produção é o Windows Server 2012 R2, Apache 2.4, PHP 5.6 e MariaDB (não tenho certeza da versão, provavelmente irrelevante). Tenho um site personalizado rodando no Silverstripe 3.5.
Ultimamente, estou recebendo TTFBs ridículos com certas ações, principalmente fazer login (mais de 30 segundos) ou, às vezes, aleatoriamente enquanto navega no back-end. Curiosamente, isso não acontece em nosso servidor de desenvolvimento que está configurado de forma semelhante, e nosso departamento de TI vai httpd.confverificar php.inise há alguma diferença que possa ser um problema.
Ativei a extensão Zend OpCache na esperança de que ajudasse, mas não estou vendo nenhuma melhoria significativa.
Eu instalei o XDebug e acionei a criação de perfil durante o login (adicionando um campo de formulário oculto chamado XDEBUG_PROFILE através do inspetor DOM), mas a saída quando visualizada no WinCachegrind diz que a execução do PHP não levou mais de 5 segundos cumulativamente - ou seja, o tempo cumulativo total main.phpfoi 4,x segundos. Não parece haver um gargalo notável na lógica da estrutura ou no acesso ao banco de dados.
httpd.exeocupa sólidos 14% da minha CPU durante a solicitação. Observar os logs com o Powershell gci -Waitmostra que a solicitação não é registrada access.logaté que a resposta seja enviada (não tenho certeza se o comportamento é normal) e não há erros aparecendo.
Estou perplexo por que o Apache está demorando tanto para processar uma solicitação que o PHP afirma levar apenas 4 segundos para executar a lógica. Embora possíveis soluções possam ser apreciadas, eu realmente gostaria de saber onde mais posso procurar em termos de diagnóstico para descobrir o que está causando a lentidão do Apache, por exemplo, acesso a arquivos, execução de rastreamento, etc. Não tenho a menor ideia de onde começar a procurar.
Responder1
O banco de dados foinãoo gargalo. Ironicamente, foi oesconderijo- é umproblema conhecido de que Zend_Cache_Backend_Fileos caches baseados em - são terrivelmente lentos se o site tiver muitos dados, modelos e imagens para serem armazenados em cache. Certamente, minha pasta silverstripe-cache no servidor continha mais de 5.000 arquivos.
Adicionar a seguinte linha para ./mysite/_config.phpdesativar o cache resultou em melhorias imediatas e impressionantes (35 segundos de TTFB no login para menos de 0,5 segundos!):
SS_Cache::set_cache_lifetime('default', -1, 100);
No entanto, Isto é um conserto temporário. Estaremos procurando implementar uma solução mais permanente e com melhores práticas para lidar com o cache, como usar um ramdisk em conjunto com o back-end do sistema de arquivos ou aproveitar um back-end que usa pools de memória como XCache ou Memcached, bem como trabalhar para migrar para Silverstripe 4.x, que é descartado Zend_Cacheem favor do symfony/cache.
Mas visto que meu escritório adora deixar a burocracia atrapalhar tudo... pode demorar um pouco antes que isso aconteça.