Existem dois tipos de gerenciamento de processador (PM). dynamic
e static
.
Estático
O método estático é muito simples. Você tem um número definido de filhos e o php-fpm sempre tentará manter esse número de filhos. Então, se você definir pm=static
e pm.max_children = 50
, você sempre terá 50 filhos, não importa o quê.
Isso é bom se você tiver um tráfego muito consistente e bem medido. Isso evita que o desperdício de esforços cresça e encolha os trabalhadores (impacto mínimo com a dinâmica). Também reduz imprevisibilidade. Salvar CPU
Todos os outros campos não são usados se definidos como estáticos.
Dinâmico
Dinâmico permite que seus filhos fiquem com flutuações. É mais fácil entender com o nosso exemplo.
Quando o servidor inicializa, ele começa em pm.start_servers
. Agora temos 25 pelo seu exemplo.
Digamos que 20 deles estejam sendo usados e que outra solicitação tenha sido enviada. Depois disso, ela é veiculada, mas a contagem de seus filhos aumenta em 1, pois atingiu o limite mínimo de reposição. Lembre-se de que o processo de criação é demorado, portanto, você deve manipulá-lo com um processo que já esteja ativo. Digamos que a carga aumenta mais e agora você tem 49 filhos ativos. Então até 50 são feitos porque é o seu máximo. Agora vamos dizer que sua carga diminui e existem 14 ativos. Em seguida, ele descarregará um filho para alcançar um total de 49 crianças, conforme ele atende ao máximo de servidores reserva. Se sua carga cair ainda mais para zero, você terá 35 filhos e nunca conseguirá ir abaixo de 35 (com exceção das solicitações via max, veja abaixo). A contagem de crianças é reduzida para que você obtenha mais memória ram utilizável.
A dinâmica é um pouco "não se preocupe, vou otimizar para você dentro dos limites".
Isso é bom se você precisa manter a memória baixa. Salvar RAM
Solicitações acima do máximo
Se você tiver 50 ativos e receber outra solicitação, ela provavelmente será enfileirada pelo gerente. Embora incerto, acho que também tende a rejeitar se o tamanho da fila for ridiculamente longo. Se ele permanecer na fila por muito tempo, o solicitante, como nginx, retornará 504 para o usuário final quando o gateway tiver expirado. Para evitar algo como todas as solicitações que estão sendo expiradas devido ao congestionamento sem fim (ddos?), O nginx normalmente pára de passar a carga para um servidor inativo por um período de tempo definido em nginx (adivinhando em torno de 30 segundos) quando atingiu certo número de erros do backend.
Solicitações máximas
O valor pm.max_requests define quantos pedidos um filho deve manipular antes de se destruir para um novo processo tomar seu lugar (ou nada se ainda estiver dentro dos limites do status dinâmico atual conforme definido acima). Isso ajuda a combater vazamentos de memória (na própria criança do php-fpm ou em seu aplicativo). Portanto, se houver um vazamento de memória, o uso de memória da criança continuará aumentando. Por que ele continua subindo mesmo depois que a execução do php é concluída e é assim que o php-fpm otimiza seus processos e outras coisas ... Eu sinto que é um ensaio separado.
Para notar a prevenção de confusão indicada pelo seu post (ou falta de clareza). Isso não tem nada a ver com quantos visitantes você tem ou quantas pessoas estão visualizando seu site agora. É tudo sobre quantos php estamos processando simultaneamente. Você esperaria que a maioria dos processos fosse concluída em menos de 300 ms. Abaixo de 100ms como ideal na opinião pessoal. Com um hardware melhor, você pode processar mais rapidamente, para que você possa manipular mais visitantes (ou mais precisamente, solicitações), apesar de não haver alteração na contagem de processos simultâneos.
P.S. Tudo o que eu disse aqui aplica-se também ao apache. Apenas diferentes nomes de variáveis.