Utilizar a página de estado do PHP-FPM para a análise de desempenho

O que a página de estado mostra sobre o pool

A página de estado do PHP-FPM mostra como um determinado piscina Pedidos PHP processados: entre outros, quantos processos estão ativos ou livres e se há pedidos em espera. É necessário que a aplicação seja efetivamente servida pelo PHP-FPM. A versão do PHP apresentada na linha de comandos, por si só, não indica nem isso nem a versão do serviço FPM responsável.

Por isso, determine primeiro a versão do FPM utilizada e o pool para o qual o servidor Web reencaminha a aplicação. Isso inclui o socket Unix ou o listener TCP utilizado e o encaminhamento no host virtual responsável. Esta atribuição é importante para que uma consulta de estado posterior não se refira acidentalmente a outro pool.

Se um servidor gerir vários pools, a informação apresentada aplica-se apenas ao pool em questão e não automaticamente a todas as aplicações PHP. Na hospedagem partilhada, é possível que não tenhas direitos para configurar o pool ou o servidor web. Nesse caso, terás de contar com o facto de o fornecedor disponibilizar a página de estado ou indicadores semelhantes de forma protegida.

Uma consulta é, em primeiro lugar, uma Instantâneo: Podem surgir e desaparecer pequenas filas de espera entre duas consultas. Outros valores contabilizam os eventos desde o arranque do FPM; no caso de um reinício, são reiniciados. Por isso, para obter um histórico significativo, guarde a hora da consulta e a identidade do pool juntamente com os valores.

Esta página não explica todo o tempo de espera no navegador. A rede, o servidor web, a base de dados e os serviços externos também podem contribuir para o tempo de resposta. Por isso, constitui um ponto de partida para o diagnóstico do pool do PHP-FPM, não um teste de desempenho completo do site.

Compreender os «Workers» e os gestores de processos

O gestor de processos determina a forma como o pool disponibiliza os seus trabalhadores. No caso de static o seu número permanece constante. dynamic ajusta o número de acordo com as necessidades, dentro dos limites configurados; ondemand inicia processos conforme necessário. A capacidade disponível que se espera depende, portanto, também do modo de funcionamento definido.

Um processo ativo está neste momento a processar um pedido; um processo livre está disponível para trabalhar. A existência de muitos «workers» ativos não constitui, por si só, um erro: um conjunto de processos em plena atividade pode processar os pedidos rapidamente. A observação torna-se mais significativa quando, ao mesmo tempo, há pedidos em espera, os tempos de resposta aumentam e quase não há processos livres disponíveis.

Mesmo uma reserva temporariamente vazia, por si só, não constitui prova de um estrangulamento duradouro. Compare as chamadas repetidas com a configuração Limite do processo e os momentos em que os utilizadores realmente notam atrasos. É assim que se distingue um pico de carga de curta duração de uma sobrecarga recorrente.

Um maior número de workers permite processar mais pedidos em paralelo, mas requer mais memória e pode sobrecarregar mais as bases de dados ou os serviços externos. Se muitos processos estiverem à espera da mesma dependência lenta, aumentar o limite não resolve a causa. Por isso, verifica os recursos e a duração dos pedidos antes de pm.max_children mudança.

Para definir as responsabilidades na pilha de alojamento, é útil comparar NGINX Unit e PHP-FPM. Complementa a perspetiva arquitetónica; continuas a ter de verificar os valores de estado concretos e as definições do gestor de processos no conjunto de FPM efetivamente utilizado.

Proteger o acesso ao estado e o FastCGI

A apresentação do estado pode revelar informações confidenciais sobre pedidos e recursos. Em particular, os detalhes do processo podem conter URIs de pedido que permitam deduzir quais as funções chamadas ou os parâmetros transmitidos. Por isso, considere esta página como um acesso de diagnóstico e não como um painel de estado público.

Limita o Acesso HTTP para pedidos internos ou endereços IP de clientes expressamente identificados. Verifica, nesse caso, qual o endereço que o servidor Web identifica efetivamente como sendo do cliente, caso exista um proxy intermédio. A proteção deve aplicar-se ao encaminhamento da página de estado e deve ser verificada antes de ser autorizada.

Independentemente disso, assegure o Acesso FastCGI por si próprio. No caso de um socket Unix, o proprietário e as permissões são relevantes; no caso do TCP, é necessário verificar a ligação de rede e os clientes autorizados. Um bloqueio no servidor Web não protege uma porta FastCGI que seja acessível separadamente a partir de uma rede não fiável.

O projeto PHP documentou, com o código CVE-2026-6735, uma vulnerabilidade XSS na saída de estado do FPM. As versões corrigidas incluem o PHP 8.4.21 e o 8.5.6. No caso de outros ramos de versão e pacotes de distribuição, verifique o respetivo nível de segurança ou os patches retroativos, em vez de concluir que a proteção está garantida apenas com base no número de versão apresentado.

Uma atualização não substitui a restrição de acesso: mesmo uma página de estado corrigida pode continuar a revelar detalhes operacionais. Mantém tanto o acesso HTTP como o listener limitados ao grupo de utilizadores previsto e tem em conta estas duas camadas de proteção em alterações posteriores ao encaminhamento.

Publicar a página de estado de forma protegida

Em primeiro lugar, determine qual o conjunto FPM que processa a aplicação em questão e através de que socket ou endereço TCP o servidor Web acede a ele. No caso de existirem vários conjuntos, a consulta de estado pertence ao conjunto para o qual é reencaminhada. A versão PHP da linha de comandos, por si só, não indica qual o serviço FPM responsável pela aplicação.

No ficheiro de configuração do pool em questão, o seguinte excerto ativa o Percurso de estado. Não se trata de um ficheiro PHP que tenhas de criar no diretório de documentos. O trecho é uma sugestão de configuração e pressupõe que tens permissão para editar a configuração do pool.

pm.status_path = /fpm-status

Configure no servidor Web uma rota adequada que reencaminhe as solicitações para este caminho diretamente, através do FastCGI, para o conjunto de servidores identificado. O encaminhamento normal da aplicação não deve interceptar a solicitação. Limite o acesso HTTP a pedidos internos ou a endereços IP de clientes conhecidos e proteja o socket FastCGI independentemente disso, através de permissões, ligação de rede e clientes autorizados.

Antes da implementação oficial, verifica tanto a configuração do servidor Web como a do FPM utilizando os procedimentos de verificação previstos no teu ambiente. Certifica-te de que estás a alterar o serviço e o pool corretos e de que a restrição de acesso também se aplica ao caminho de estado. O simples facto de definir um caminho não torna a saída acessível via HTTP.

Num ambiente já configurado e protegido localmente, o seguinte comando de terminal lê a saída JSON. Pressupõe que existe um host virtual HTTP local adequado acessível na morada indicada. Caso contrário, terás de adaptar o endereço, o encaminhamento do host e, se for o caso, o TLS ao teu ambiente; a consulta não altera nenhuma configuração.

curl --fail --silent --show-error 'http://127.0.0.1/fpm-status?json'

Na resposta, verifica, em particular, o nome do pool. Uma mensagem de erro ou uma saída inesperada da aplicação pode indicar um encaminhamento incorreto; um bloqueio de acesso também pode impedir a recuperação dos dados. Verifica, então, a configuração do servidor Web em questão e os registos, em vez de remover a proteção precipitadamente.

Como interpretar e calcular corretamente os indicadores

Os valores de estado descrevem diferentes períodos: alguns indicam o estado no momento da consulta, outros contabilizam eventos ou registam um valor máximo desde o início. Para um diagnóstico, esta distinção é mais importante do que um único valor anómalo. A tabela seguinte classifica os dados essenciais.

Para um Taxa de ligaçãosubtrais dois valores de accepted conn subtrai uma da outra e divide a diferença pelo tempo decorrido. Exemplo de cálculo hipotético, sem medição: se o contador passar de 12 000 para 12 600 no espaço de 60 segundos, obtém-se uma média de dez ligações estimadas por segundo. A partir disso, não é possível deduzir diretamente nem as visualizações de páginas nem a latência da aplicação.

Guarde a hora e a identidade do pool em cada ponto de medição. Após um reinício do FPM, os valores de estado são reiniciados; por isso, uma diferença que ultrapasse esta interrupção não constitui uma taxa válida. Detete uma redução no contador ou uma alteração na hora de início e reinicie o cálculo para o novo período.

Em max children reached o gestor de processos é fundamental: a configuração de exemplo do PHP 8.4.21 descreve o contador para «dynamic» e «ondemand». No caso de «static», não se deve considerar um valor nulo como prova de capacidade disponível. Para slow requests O limiar e o Slowlog têm de estar configurados de forma adequada; o limiar determina quais as consultas longas que são efetivamente registadas.

Comparar formatos de saída e detalhes do processo

A versão resumida é adequada para uma visão geral de toda a piscina. O fator decisivo na escolha do formato é se pretendes ler os valores manualmente ou processá-los regularmente através de um sistema de monitorização. O parâmetro full alarga a saída com detalhes do processo; não é um formato de intercâmbio autónomo.

O Manual do PHP também documenta XML e HTML. Em caso de consultas automatizadas, verifica a versão do FPM efetivamente instalada e a sua saída antes de dependeres de determinados campos ou detalhes do processo. Em particular, deves ter em conta a combinação de OpenMetrics e full verificar na própria versão, em vez de partir do princípio de que existem dados de processos individuais.

O Duração do pedido Na versão completa, o valor é expresso em microsegundos. No caso de um processo ativo, refere-se à duração do pedido que está a ser processado nesse momento; no caso de um processo inativo, refere-se ao último pedido processado. Um valor elevado num worker livre não significa, portanto, que este ainda esteja a processar o pedido.

Os campos last request cpu e last request memory são apresentados como zero nos processos ocupados, porque a sua avaliação só ocorre após a conclusão da consulta. Estes valores nulos não indicam, portanto, uma falta de consumo de CPU ou de memória. Consultas repetidas podem revelar se um processo permanece ocupado durante mais tempo; no entanto, não substituem um rastreio completo da aplicação.

Analisar filas de espera e pedidos lentos

Se o fila de espera Se isso se repetir, enquanto muitos processos estão ativos e apenas alguns estão livres, um conjunto sobrecarregado é uma hipótese de trabalho plausível. Uma única consulta não é suficiente para isso: compare vários momentos e observe se, ao mesmo tempo, os tempos de resposta às consultas aumentam. O valor máximo da fila, por si só, não indica se ainda há pedidos em espera.

Compare esse período com os registos do FPM, a utilização da CPU e a memória disponível. Considere também a base de dados, a cache e os serviços externos: se o PHP estiver à espera de uma dependência lenta, os workers permanecem ocupados, embora o aumento da capacidade da CPU, por si só, não resolva necessariamente o problema. A página de estado mostra a ocupação, mas não indica de forma fiável a sua causa.

Consulte repetidamente a versão completa protegida durante uma fase que se destaque. Uma duração prolongada da solicitação no mesmo processo ativo pode indicar um worker ocupado por um período mais longo; verifique o estado do processo, pois, no caso de um processo inativo, a duração refere-se à sua última solicitação. O PID, o URI e o script ajudam na identificação, mas não fornecem um rastreio completo.

Especialmente no caso de um controlador frontal, o mesmo nome de script pode abranger muitas funções diferentes da aplicação. Por isso, complementa essa observação com o rastreio da aplicação e uma configuração adequada de Slowlog. O seu limiar determina quais as solicitações longas que são registadas; a ausência de uma entrada não significa que todas as solicitações tenham sido rápidas. Para saberes como interpretar os resultados de forma mais aprofundada, consulta o artigo sobre o Análise do registo de lentidão do PHP-FPM.

Para a comparação, regista o intervalo de tempo e o pool em questão. Desta forma, podes verificar, por exemplo, se uma consulta lenta à base de dados coincide temporalmente com os workers ocupados ou se a fila já estava a aumentar antes disso. Uma correlação restringe a pesquisa, mas ainda não substitui a verificação da solicitação específica.

Monitorização e falhas da página de estado

No caso de picos de carga recorrentes, as consultas regulares e protegidas são mais significativas do que verificações pontuais ocasionais. O JSON é adequado para o processamento automatizado; o OpenMetrics é uma alternativa, desde que a versão de PHP instalada e o cliente de monitorização sejam compatíveis. Guarda, para cada ponto de medição, a hora e a identidade do pool, para que não compares acidentalmente pools diferentes.

Trata consultas em falta como eventos distintos e não como valores nulos. Uma lacuna pode dever-se à rede, à proteção de acesso ou ao serviço de estado; por si só, não indica nem um conjunto vazio nem uma falha da aplicação. Por isso, guarda também os erros e os tempos de espera da consulta, para que a lacuna permaneça visível numa análise posterior.

Identifica também as reinicializações dos contadores acumulados após um reinício do FPM. Uma diferença negativa entre dois valores não corresponde a uma taxa de ligação negativa; reinicie o cálculo após a reinicialização e tenha em conta o intervalo interrompido. A hora de início e a atribuição ao pool também ajudam a contextualizar essa interrupção no histórico.

Se a consulta de estado for executada pelo mesmo pool que a aplicação, pode ela própria aguardar caso os trabalhadores estejam esgotados. Para esta situação, oferece-se pm.status_listen um listener FastCGI separado com um pool interno que funciona de forma independente. Este permite o diagnóstico do estado enquanto o pool principal está ocupado; no entanto, não aumenta a capacidade de processamento deste.

O listener adicional necessita de um encaminhamento do servidor Web protegido e explicitamente atribuído. Proteja também o seu acesso FastCGI e, após uma alteração aprovada, verifique se a consulta fornece efetivamente o estado do pool pretendido. Desta forma, o diagnóstico permanece separado do caminho normal da aplicação, sem tornar os dados de estado acessíveis ao público.

Analisar os resultados e selecionar as medidas a tomar

Um ping do FPM e a página de estado respondem a questões diferentes. O ping indica se o FPM responde à solicitação em questão; não fornece informações equivalentes sobre workers disponíveis ou solicitações em espera. Por isso, um ping bem-sucedido, por si só, não significa que não haja problemas com a carga do conjunto de aplicações.

Se os valores do processo não corresponderem aos registos ou a outras observações, verifica primeiro a atribuição do pool, o momento da consulta e a possibilidade de reiniciar o sistema. Em seguida, compare os valores com outros dados de processo e de funcionamento disponíveis. Trate inicialmente o desvio como um achado em aberto, em vez de deduzir imediatamente uma causa ou uma alteração de configuração necessária.

Se as chamadas «Full» repetidas e as entradas no «Slowlog» apresentarem os mesmos padrões de pedidos demorados, analise primeiro os percursos da aplicação afetados. Se, pelo contrário, o atraso se originar numa base de dados ou num serviço externo, a análise destes pode ser mais eficaz do que alterar o número de workers. O que é decisivo é saber se a medida aborda a causa observada, e não apenas um único sintoma.

Uma adaptação de pm.max_children É uma opção a considerar se for comprovado que o pool está a funcionar no seu limite e se a CPU, a memória e os serviços a jusante tiverem capacidade para suportar um maior nível de paralelismo. Um maior número de workers requer mais recursos e pode aumentar a pressão sobre esses serviços. Por isso, não existe um número universal adequado; o modo de funcionamento do gestor de processos deve ser tido em conta na avaliação.

Após a implementação de uma alteração aprovada, compare novamente o mesmo conjunto de recursos em condições de carga o mais semelhantes possível: a fila de espera, os tempos de resposta, os erros e o consumo de recursos estão interligados. Registe também se uma medida não trouxer melhorias ou se agravar a carga sobre uma dependência. Só isto Comparação antes e depois permite tomar uma decisão fundamentada sobre os próximos passos.