Dimensionar um servidor para PHP tem uma conta central, e ela é mais simples do que parece: o número de processos que atendem requisições, multiplicado pela memória de cada um, precisa caber na memória disponível.

O que torna isso difícil não é a fórmula — é que os dois números costumam ser estimados em vez de medidos, e o erro custa nos dois sentidos.

Este guia mostra como chegar aos números reais. A arquitetura de execução e os requisitos da linguagem estão no artigo sobre servidor para PHP.

Os dois erros opostos

Processos demais para a memória disponível: quando ela esgota, o sistema operacional encerra processos e a aplicação apresenta falhas intermitentes, sem padrão aparente. É o erro mais difícil de diagnosticar.

Processos de menos: as requisições entram em fila esperando um processo livre. O sintoma é um erro de tempo esgotado ou de serviço indisponível, com o servidor mostrando memória e processador tranquilos.

A conclusão prática: um erro de servidor indisponível em pico, com recursos livres, quase sempre significa poucos processos configurados. É uma correção de configuração, não de contratação.

O que medir

1. Memória por processo em regime, depois de horas atendendo requisições — não logo após iniciar.
2. Tempo médio de resposta, e o das rotas mais lentas.
3. Requisições simultâneas no pico, e não o total diário.
4. Proporção de tráfego que não passa por cache, que é a que efetivamente chega ao PHP.
5. Conexões abertas com o banco, somadas entre todos os processos.
6. Memória livre do servidor durante o horário de maior movimento.

O item 4 é o que mais muda o resultado em sites de conteúdo: se 90% das visitas são servidas por cache, apenas 10% dimensionam a aplicação. Sem essa informação, a estimativa erra por uma ordem de grandeza.

E o item 1 tem uma armadilha: aplicações com frameworks carregam bibliotecas em cada requisição, e o consumo em regime é consideravelmente maior que o inicial.

A conta

Com os números em mãos:

Passo	Cálculo
1	Memória do servidor menos o sistema, o servidor web e o banco, se local
2	O resultado dividido pela memória média de um processo
3	Reduzir esse número para deixar margem
4	Comparar com a simultaneidade medida no pico

Se o número de processos que cabe for menor que a simultaneidade no pico, existem três caminhos — e vale tentá-los nessa ordem:

• Reduzir o tempo das requisições, o que aumenta quantas cada processo atende.
• Reduzir a memória por processo, revisando o que a aplicação carrega.
• Aumentar a memória do servidor, que é a opção com custo.

O primeiro rende mais do que parece: um processo que atende em meio segundo serve dez vezes mais gente que um que leva cinco segundos — com exatamente a mesma configuração.

Os limites escondidos

Conexões de banco

Cada processo mantém a própria conexão. O total precisa caber no limite configurado no banco. O sintoma: a aplicação funciona até certo volume e passa a falhar com erro de conexão, com processador e memória confortáveis.

Limite de memória por requisição

O PHP tem um limite próprio por requisição, independente da memória do servidor. Uma requisição que o ultrapassa é interrompida — e o sintoma é uma página específica falhando enquanto o resto funciona.

Aumentá-lo indiscriminadamente é arriscado: ele multiplica pelo número de processos, e um limite generoso com muitos processos estoura a memória do servidor.

Processos de fila

Se a aplicação usa fila, esses trabalhadores são processos adicionais, com memória e conexões próprias — e frequentemente consomem mais que os de atendimento, porque executam trabalho pesado. O conceito está no artigo sobre o que é uma fila de tarefas.

O que fazer antes de aumentar recursos

1. Ative o cache de código, que evita recompilar a aplicação a cada requisição — ganho grande e custo zero.
2. Verifique as consultas ao banco, que são a causa mais comum de requisições lentas.
3. Adicione cache de página onde for possível, reduzindo o tráfego que chega ao PHP.
4. Sirva arquivos estáticos pelo servidor web, e não pela aplicação.
5. Revise o que a aplicação carrega em cada requisição.
6. Mova trabalho pesado para a fila.

O primeiro item é o de melhor retorno e frequentemente está desativado ou mal configurado — as camadas estão detalhadas no artigo sobre Redis, PHP-FPM e OPcache.

O que muda conforme o tipo de aplicação

A mesma conta produz resultados bem diferentes conforme o que a aplicação faz:

Site de conteúdo com cache

A maior parte das visitas nem chega ao PHP. O dimensionamento é governado pela fração não cacheável — painel administrativo, busca interna, formulários, comentários. Sites assim sustentam volumes altos com configurações modestas, e o erro comum é dimensionar pelo tráfego total.

Loja virtual

O oposto: carrinho, checkout e área do cliente não podem ser cacheados, e são justamente as páginas que mais importam. A proporção não cacheável é muito maior, e o dimensionamento precisa considerar a simultaneidade no fluxo de compra, não o número de visitantes do catálogo.

Aplicação com painel de uso interno

Sistemas usados por equipes têm carga concentrada no horário comercial, com todas as telas fora do cache. Uma equipe de vinte pessoas gera uma demanda constante que nenhuma medição de tráfego público captura.

API

Cada chamada chega ao PHP, sem exceção. A conta é direta: simultaneidade de chamadas versus processos disponíveis — e é o cenário em que o tempo médio de resposta tem maior efeito multiplicador sobre a capacidade.

Margem e crescimento

Dois ajustes que evitam redimensionar a cada trimestre.

Margem para variação. Configurar o número de processos exatamente no limite da memória significa que qualquer variação — um pico acima do normal, um plugin novo, um aumento no consumo por processo — derruba o servidor. Uma folga deliberada é mais barata que um incidente.

Projeção de crescimento. Se o tráfego cresce de forma consistente, vale dimensionar considerando os próximos meses, e não apenas o momento atual. O indicador útil é a taxa de crescimento do consumo, comparada mês a mês.

E vale registrar os números da medição em algum lugar: quando chegar a hora de redimensionar, ter a base anterior torna a comparação objetiva em vez de uma nova estimativa do zero.

Sinais de mau dimensionamento

Sintoma	Causa provável
Erro de serviço indisponível em pico	Processos insuficientes
Falhas intermitentes sem padrão	Memória esgotando
Erro de conexão em volume médio	Limite do banco atingido
Uma página falha, o resto funciona	Limite de memória por requisição
Lentidão progressiva no dia	Acúmulo ou vazamento em processos longos
Tarefas de fila atrasando	Trabalhadores insuficientes

Conclusão

A conta é processos vezes memória por processo, cabendo na memória disponível com margem. O que a torna difícil é que os dois fatores precisam ser medidos, não estimados.

E o número que mais muda o resultado é o menos lembrado: a proporção de tráfego que não passa por cache. É ela que chega ao PHP, e sem ela a estimativa erra por uma ordem de grandeza.

Antes de contratar mais recursos, vale a verificação de melhor retorno: cache de código ativo e consultas ao banco revisadas. Conheça o Cloud Server para PHP da TBF Host e avalie a configuração a partir dos seus números.

Perguntas frequentes

Quantos processos PHP devo configurar?

O número que couber na memória disponível, descontando sistema, servidor web e banco se for local, com margem para variações. Depois compare esse número com a simultaneidade medida no pico — se for menor, reduza o tempo das requisições antes de aumentar recursos.

Recebo erro de serviço indisponível em picos com o servidor tranquilo. Por quê?

Quase sempre por poucos processos configurados: as requisições entram em fila esperando um livre, e o servidor mostra memória e processador confortáveis. É uma correção de configuração, não de contratação.

Por que a aplicação tem falhas intermitentes sem padrão?

Provavelmente há mais processos configurados do que a memória comporta. Quando ela esgota, o sistema operacional encerra processos, e as falhas parecem aleatórias porque dependem de quais estavam ativos naquele momento.

Quanta memória cada processo PHP consome?

Depende inteiramente da aplicação, e precisa ser medido em regime — depois de horas atendendo requisições, não logo após iniciar. Aplicações com frameworks carregam bibliotecas em cada requisição e consomem consideravelmente mais que o valor inicial.

Posso simplesmente aumentar o limite de memória por requisição?

Com cuidado. Esse limite se multiplica pelo número de processos: um valor generoso com muitos processos estoura a memória do servidor. Se uma página específica falha enquanto o resto funciona, vale investigar o que ela carrega antes de elevar o limite.

O que mais reduz a necessidade de recursos em PHP?

Ativar o cache de código, que evita recompilar a aplicação a cada requisição, e revisar as consultas ao banco, que são a causa mais comum de requisições lentas. Um processo que atende em meio segundo serve dez vezes mais gente que um que leva cinco.

Por que a proporção de cache importa no dimensionamento?

Porque só o tráfego que não passa por cache chega ao PHP. Se 90% das visitas são servidas por cache, apenas 10% dimensionam a aplicação — e estimar sem essa informação erra o resultado por uma ordem de grandeza.

Trabalhadores de fila entram na conta?

Sim, e são frequentemente esquecidos. São processos adicionais, com memória e conexões de banco próprias, e costumam consumir mais que os de atendimento porque executam trabalho pesado, como gerar relatórios ou processar arquivos.