Uma versão não editada do artigo foi publicada originalmente em haydenjames.io e é publicada aqui com a permissão de seu autor .
Em poucas palavras, falarei sobre a melhor forma de configurar o PHP-FPM para aumentar a taxa de transferência, reduzir a latência e o uso mais estável dos recursos e da memória do processador. Por padrão, a string PM (gerenciador de processos) no PHP-FPM é dinâmica e, se você não tiver memória suficiente, é melhor instalar o ondemand . Vamos comparar duas opções de controle com base na documentação do php.net e ver como meu pm estático favorito difere deles por uma grande quantidade de tráfego:
pm = dinâmico - o número de processos filhos é configurado dinamicamente com base nas seguintes diretivas: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers .
pm = ondemand - os processos são criados sob demanda (diferente da criação dinâmica, quando pm.start_servers são iniciados quando o serviço é iniciado).
pm = estático - o número de processos filhos é fixo e especificado pelo parâmetro pm.max_children .
Veja a lista completa de diretivas globais do php-fpm.conf para obter detalhes .
As semelhanças do gerenciador de processos PHP-FPM com o controlador de frequência do processador
Pode parecer offtopic, mas vou relacionar isso ao tópico de configuração do PHP-FPM. Quem pelo menos uma vez não desacelerou o processador - em um laptop, máquina virtual ou servidor dedicado. Lembra da escala da frequência do processador? Essas opções, disponíveis para nix e Windows, podem melhorar o desempenho e a capacidade de resposta do sistema alterando a configuração do controlador do processador de ondemand para o desempenho *. Desta vez, vamos comparar as descrições e examinar as semelhanças:
Governor = ondemand - escala dinâmica da frequência do processador, dependendo da carga atual. Muda acentuadamente para a frequência máxima e depois a reduz quando períodos ociosos aumentam.
Governador = conservador = escala dinâmica de frequência, dependendo da carga atual. Aumenta e diminui a frequência mais suave do que ondemand.
Governador = desempenho - a frequência é sempre máxima.
Veja a lista completa dos parâmetros do controlador de frequência do processador para obter detalhes.
Veja a semelhança? Eu queria mostrar essa comparação para convencê-lo de que é melhor usar pm static para PHP-FPM.
Para um controlador de processador, o parâmetro performance ajuda a aumentar com segurança o desempenho, porque depende quase inteiramente do limite do processador do servidor. Além disso, é claro, também existem fatores como temperatura, carga da bateria (em um laptop) e outros efeitos colaterais da operação constante do processador a 100%. O ajuste de desempenho fornece o desempenho mais rápido do processador. Leia, por exemplo, sobre o parâmetro force_turbo no Raspberry Pi , com o qual o painel RPi usará o controle de desempenho , onde a melhoria de desempenho será mais perceptível devido à baixa velocidade de clock da CPU.
Usando pm static para maximizar o desempenho do servidor
O parâmetro estático do PHP-FPM pm depende em grande parte da memória livre no servidor. Se a memória estiver baixa, é melhor escolher ondemand ou dinâmico . Por outro lado, se você tiver memória, poderá evitar a sobrecarga do gerenciador de processos PHP configurando pm static para a capacidade máxima do servidor. Em outras palavras, se tudo estiver bem calculado, você precisará definir pm.static para a quantidade máxima de processos PHP-FPM que podem ser executados sem criar problemas com memória ou cache insuficiente. Mas não tão alto que sobrecarregue os processadores e acumule um monte de operações PHP-FPM aguardando execução .
Na captura de tela acima, o servidor possui pm = static e pm.max_children = 100 instalados, e são necessários cerca de 10 GB dos 32. Preste atenção nas colunas destacadas, tudo está claro aqui. Nesta captura de tela, havia aproximadamente 200 usuários ativos (mais de 60 segundos) no Google Analytics. Nesse nível, aproximadamente 70% dos processos filhos do PHP-FPM ainda estão ociosos. Isso significa que o PHP-FPM é sempre definido para a quantidade máxima de recursos do servidor, independentemente do tráfego atual. Um processo inativo aguarda picos de tráfego e responde instantaneamente. Você não precisa esperar o pm criar processos filhos e finalizá-los quando o período pm.process_idle_timeout expirar . Defino um valor muito alto para pm.max_requests , porque é um servidor que funciona sem vazamentos de memória no PHP. Você pode definir pm.max_requests = 0 com static se estiver totalmente confiante nos scripts PHP existentes e futuros. Mas é melhor reiniciar os scripts ao longo do tempo. Instale um grande número de consultas, porque queremos evitar a sobrecarga desnecessária da pm. Por exemplo, pelo menos pm.max_requests = 1000 - dependendo do número de pm.max_children e do número de solicitações por segundo.
A captura de tela mostra o comando top do Linux , filtrado por u (usuário) e nome de usuário do PHP-FPM. Apenas os 50 primeiros processos são exibidos (eu não contei exatamente), mas, na verdade, top mostra as principais estatísticas colocadas na janela do terminal. Nesse caso, classificado por% CPU (% CPU). Para visualizar todos os 100 processos PHP-FPM, execute o comando:
top -bn1 | grep php-fpm
Quando usar pm ondemand e dynamic
Se você usa pm dynamic , você recebe erros semelhantes:
WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total children
Tente alterar o parâmetro, o erro não irá a lugar algum, conforme descrito nesta publicação no Serverfault . Nesse caso, o valor de pm.min era muito pequeno e, como o tráfego da Web muda muito e possui altos picos e quedas profundas, é difícil configurar adequadamente a dinâmica da pm. Isso geralmente usa pm ondemand , conforme recomendado no mesmo post . Mas isso é ainda pior, porque ondemand encerra processos inativos a zero quando há pouco ou nenhum tráfego e, como resultado, você ainda sofrerá com os custos quando o tráfego mudar. A menos, é claro, que você tenha definido um enorme tempo de espera. E então é melhor usar pm.static + um número alto de pm.max_requests .
O PM dynamic e especialmente ondemand podem ser úteis se você tiver vários pools de PHP-FPM. Por exemplo, você hospeda várias contas cPanel ou vários sites em diferentes pools. Eu tenho um servidor no qual, por exemplo, mais de 100 contas cpanel e cerca de 200 domínios, e pm.static ou mesmo dinâmico não me salvariam. Somente ondemand é necessário aqui, porque mais de dois terços dos sites recebem pouco ou nenhum tráfego, e com ondemand todos os processos filhos caem, o que nos poupa muita memória! Felizmente, os desenvolvedores do cPanel perceberam isso e definiram o valor padrão como ondemand . Anteriormente, quando o valor padrão era dinâmico , o PHP-FPM não era adequado para servidores compartilhados ocupados. Muitos usaram o suPHP porque o pm dynamic consumiu memória, mesmo com pools ociosos e contas cPanel PHP-FPM. Provavelmente, com bom tráfego, você não estará hospedado em um servidor com um grande número de pools de PHP-FPM (hospedagem compartilhada).
Conclusão
Se você usa PHP-FPM e possui tráfego pesado, os gerenciadores de processos dinâmicos e sob demanda para PHP-FPM limitarão a largura de banda devido aos custos inerentes. Examine seu sistema e configure seus processos PHP-FPM para corresponder à sua capacidade máxima do servidor. Primeiro defina pm.max_children, dependendo do uso máximo de pm dynamic ou ondemand , e depois aumente esse valor para o nível em que a memória e o processador funcionarão sem sobrecarga excessiva. Você notará que, com pm estático , como tudo é armazenado na memória, os picos de tráfego ao longo do tempo causarão menos picos para o processador, e os valores médios de carga do servidor e do processador serão iguais. O tamanho médio do processo PHP-FPM depende do servidor da web e requer configuração manual; portanto, os gerenciadores de processos mais automatizados - dinâmicos e ondemand - são mais populares. Espero que o artigo tenha sido útil.
UPD Adicionado diagrama de benchmark ab . Se os processos PHP-FPM estiverem na memória, o desempenho será aprimorado consumindo a memória onde eles ficam e esperam. Encontre a melhor opção para si mesmo.
