Avaliação do desempenho da CPU do servidor para PHP: testes para cargas de trabalho reais de alojamento web

O que um benchmark de PHP deve revelar

Um benchmark de CPU em PHP pode, em primeiro lugar, mostrar quanto tempo um sistema demora a executar uma tarefa de cálculo específica. Isto é particularmente útil quando uma única solicitação demora muito tempo a ser processada devido a cálculos em PHP. Um valor mais elevado Desempenho de um único núcleo pode reduzir o tempo de processamento desse tipo de trabalho; no entanto, não é possível deduzir o tempo de resposta de um site inteiro apenas a partir de um valor da CPU.

Uma segunda questão diz respeito ao comportamento da aplicação em caso de acessos simultâneos: quantas respostas corretas fornece por segundo e quanto tempo os utilizadores têm de esperar? Para isso, é necessário um Comparativo de alojamento web através de HTTP faz sentido. Este mede o percurso através do servidor Web e do PHP, bem como, se for o caso, da base de dados, da cache e da rede. É precisamente esta combinação que o torna prático, mas impede uma avaliação isolada do desempenho da CPU.

A terceira questão diz respeito ao gargalo. Se, por exemplo, um pedido estiver à espera de uma consulta à base de dados, uma operação de cálculo mais rápida pouco diz sobre o seu tempo total. Também a cache altera o resultado: se uma página já for entregue na íntegra antes do PHP, a chamada não mede a execução da aplicação dinâmica.

Além disso, sob carga paralela, o pool do PHP-FPM pode limitar o número de pedidos processados em simultâneo. A sua página de estado fornece, entre outras coisas, informações sobre os processos em execução e os pedidos em espera. Uma fila que vai aumentando é, por isso, um motivo para se proceder a um diagnóstico, e não uma prova direta de que a CPU está demasiado lenta.

Para escolher um serviço de alojamento, é útil analisar estas questões separadamente: primeiro, a unidade de trabalho comparável; depois, o funcionamento em condições de carga baixa e elevada; e, por fim, os recursos que limitam o resultado. A forma como a CPU, a memória RAM e o armazenamento interagem entre si é explicada no artigo sobre Hardware para alojamento web de alto desempenho.

Distinguir pontuações da CPU e testes de aplicações

A Microbenchmark repete uma tarefa pequena e bem definida. Com o PHPBench, por exemplo, é possível analisar uma função de processamento de dados em condições específicas. O resultado ajuda a comparar essa função com o seu ambiente de execução; não descreve automaticamente uma consulta completa nem o desempenho de um CMS ou de uma loja online.

Um teste de aplicação HTTP responde a outra questão: como é que a aplicação selecionada reage através da pilha web efetivamente utilizada? Tem em conta, por exemplo, o PHP-FPM, a base de dados e as caches, na medida em que estejam envolvidos na chamada testada. Assim, é adequado para avaliar uma oferta de alojamento, mas não consegue, por si só, determinar qual o componente responsável por uma diferença.

O SPEC CPU complementa esses testes com cargas de trabalho padronizadas e que exigem grande capacidade de cálculo. O SPEC CPU 2026 inclui conjuntos de testes de inteiros e de ponto flutuante, bem como resultados de «Speed» e «Rate». «Speed» refere-se ao tempo necessário para realizar as tarefas, enquanto «Rate» se refere ao débito. Um valor de velocidade não é automaticamente um valor exclusivamente de um único núcleo: a SPEC indica a existência de paralelismo adicional nos testes de velocidade de números inteiros da suíte 2026.

Para uma comparação SPEC fiável, a suíte, a métrica e o tipo de resultado têm de base ou pico correspondem. Da mesma forma, o sistema testado na íntegra é importante: para além do processador, a memória, o compilador e a configuração, entre outros fatores, influenciam o resultado. Os valores publicados não são, portanto, uma característica isolada do modelo de CPU e não substituem um teste PHP.

O SPEC CPU 2017 e o CPU 2026 utilizam conjuntos de testes diferentes; os seus valores não se enquadram na mesma escala. Quem estiver a fazer uma pré-seleção deve, por isso, comparar o relatório completo dos resultados em vez de uma tabela de classificação resumida. Só um teste de aplicação adequadamente concebido poderá, posteriormente, revelar se um candidato é adequado para a sua própria aplicação.

Definir condições de teste comparáveis

Uma comparação justa começa com a mesma versão da aplicação e um conjunto de dados comparável. A rota escolhida e a resposta esperada também têm de coincidir: uma página de produto com muitos acessos à base de dados responde a uma questão diferente daquela a que uma função API simples responde. Por isso, não verifique apenas se chega uma resposta, mas também se o seu conteúdo corresponde à tarefa prevista.

Registe a versão do PHP e as extensões, bem como o servidor web, a configuração do PHP-FPM e a base de dados. O percurso de rede entre o gerador de carga e a aplicação também deve constar do registo. Percursos diferentes ou localizações distintas da base de dados podem alterar o tempo de resposta medido, mesmo que a execução do PHP tenha a mesma velocidade em ambos os sistemas.

É particularmente importante a separação entre CLI e PHP-FPM: Um teste na linha de comandos não analisa automaticamente a mesma configuração de tempo de execução que uma solicitação HTTP. Documente as definições do OPcache e do JIT efetivamente utilizadas em ambos os contextos. O seu efeito e as definições predefinidas dependem, entre outros fatores, da versão do PHP; uma suposição genérica não é suficiente para a comparação.

O Estado da cache tem de ser comparável. Uma cache fria e uma cache já aquecida respondem a questões diferentes; ambas podem ser relevantes, mas devem ser avaliadas separadamente. O mesmo se aplica ao volume de dados e aos dados de teste: se o âmbito do trabalho se alterar, uma diferença de tempo já não pode ser atribuída com precisão ao sistema.

Anote também o modelo da CPU, as vCPUs atribuídas e os limites de recursos visíveis, bem como a carga selecionada e o número de repetições. Se forem comparados deliberadamente dois pacotes de alojamento diferentes, o resultado fornece uma indicação sobre a respetiva configuração global. As diferenças ao nível do processador, dos limites, da base de dados ou do cache não devem, por si só e sem um diagnóstico mais aprofundado, ser interpretadas como uma vantagem da CPU.

Selecionar cargas de trabalho e indicadores adequados

A escolha do teste depende da pergunta a que pretendes responder. Um Microbenchmark analisa uma tarefa de cálculo limitada; um teste HTTP inclui o percurso pela pilha da Web. Os resultados do SPEC complementam a comparação com testes de sistema padronizados que exigem um uso intensivo da CPU, mas não substituem um teste da própria aplicação PHP.

Para uma única solicitação dinâmica, escolhe uma página ou rota API representativa e começa com um baixo nível de paralelismo. A rota tem de executar efetivamente o PHP: uma resposta fornecida inteiramente a partir de uma cache de páginas a montante seria, embora, um teste de cache válido, mas pouco revela sobre o processamento do PHP.

No caso de visitantes simultâneos, deve testar o mesmo ponto final em vários níveis de carga definidos. Desta forma, é possível verificar se os tempos de resposta e a taxa de transferência bem-sucedida se alteram à medida que o paralelismo aumenta. Numa rota com utilização intensiva da base de dados, o conjunto de dados, a localização da base de dados e o estado da cache devem permanecer inalterados entre as execuções comparativas.

Podes analisar isoladamente, com o PHPBench, uma função da aplicação que exija um grande uso da CPU, como, por exemplo, um processamento de dados sem acesso à rede. Um resultado melhor indica, numa primeira fase, apenas uma vantagem para essa função nas condições de execução selecionadas. O teste da aplicação terá de demonstrar se isso se traduz numa vantagem percetível para uma página completa.

Realizar um teste de staging com o wrk

Realize os testes apenas com autorização expressa, num ambiente de teste isolado. Configure um percurso de leitura seguro e representativo e utilize dados de teste adequados. Antes de iniciar, defina uma carga máxima, bem como critérios de interrupção, tais como erros que possam ocorrer, tempos de espera ou impacto noutros serviços.

O comando seguinte destina-se a um terminal numa instância de staging local expressamente configurada para o efeito. A rota preparada deve estar acessível na porta 8080; o comando gera, de facto, carga e não se destina a um sistema desconhecido ou em produção.

wrk -t2 -c4 -d30s --latency http://127.0.0.1:8080/

A chamada utiliza dois threads do gerador de carga, quatro ligações abertas e um tempo de execução de 30 segundos. A opção --latency solicita uma saída detalhada sobre a latência. Quatro ligações constituem um ponto de partida escolhido para este exemplo, não sendo uma recomendação geral quanto ao número de visitantes ou à capacidade de um servidor.

No entanto, a saída normal de percentis do wrk não inclui o p95. Para uma análise reproduzível do p95, guarde o seguinte script Lua no gerador de carga como percentiles.lua. Os valores p50 e p95 da estatística de latência são expressos em microssegundos; quando divididos por 1 000, resultam em milissegundos.

function done(summary, latency, requests)
  io.write(string.format("p50: %.0f us\n", latency:percentile(50.0)))
  io.write(string.format("p95: %.0f us\n", latency:percentile(95.0)))
end

Para a medição propriamente dita, executa o mesmo teste de preparação local utilizando o script. O caminho do ficheiro refere-se a um terminal no diretório onde se encontra o ficheiro do script. Esta execução também gera carga; regista os dois percentis apresentados, juntamente com os erros e a qualidade da resposta verificada separadamente.

wrk -t2 -c4 -d30s --latency -s percentiles.lua http://127.0.0.1:8080/

Planeia uma separação Fase de aquecimento antes de registar as medições propriamente ditas. Em seguida, repete cada nível de carga definido e, na medida do possível, varia a ordem dos sistemas de comparação. Regista a duração do aquecimento e se a cache se encontrava no estado desejado no início da medição.

Aumente o número de ligações apenas dentro dos limites acordados e verifique os critérios de interrupção após cada fase. Observe também o gerador de carga: se este estiver sobrecarregado, pode limitar o resultado. Verifique adicionalmente os códigos de estado e o conteúdo das respostas; uma página de erro apresentada rapidamente ou uma resposta incorreta não conta como uma solicitação de aplicação bem-sucedida.

Registar os níveis de carga e os resultados

Um registo de medição associa os valores às condições em que foram obtidos. Para cada execução, registe o ambiente, o ponto final, o estado da cache e o nível de carga, juntamente com os resultados. O quadro seguinte utiliza, entre outros, valores fornecidos pelo wrk ou pela página de estado do FPM; terás de complementar a verificação do conteúdo da resposta.

A mediana descreve o ponto médio dos tempos de resposta observados. O p95 é o valor que 95 por cento das respostas medidas não ultrapassam. Em conjunto, estes dois indicadores mostram se, para além de uma consulta típica, também se verifica uma alteração na parte mais lenta da distribuição. Interprete-os sempre em conjunto com os erros e os timeouts.

Distinga entre um número fixo de ligações e uma taxa de pedidos predefinida. Num teste baseado em ligações, como o do exemplo, respostas lentas podem fazer com que sejam gerados menos pedidos novos por segundo através das mesmas ligações. A latência medida não descreve, por si só, o comportamento numa taxa de chegada que se mantém elevada.

Por isso, compare apenas pontos de carga suficientemente semelhantes: o mesmo percurso e verificação de resposta, estados de cache comparáveis, bem como o mesmo modelo de carga e o mesmo nível de carga. Um p95 baixo com baixo paralelismo não é diretamente comparável a um p95 em condições de sobrecarga. Relate vários ciclos de teste e a sua dispersão, em vez de apresentar um único valor favorável como resultado.

Analisar o FPM e os limites de recursos

Se, à medida que a carga aumenta, tanto a fila como o tempo de resposta p95 aumentarem, vale a pena dar uma olhadela no pool do PHP-FPM. Compara os valores atuais para active processes, idle processes e listen queue com o limite máximo configurado pm.max_children. Se todos os processos permitidos estiverem ativos, não houver nenhum livre e houver pedidos em espera, isso indica uma Limite da piscina ou a trabalhadores que estão ocupados há muito tempo, mas não significa automaticamente que o processador esteja demasiado lento.

O anúncio max children reached Por outro lado, documenta que o limite de processos foi atingido mais cedo desde o início do pool. Por si só, isso não comprova nem a existência de uma fila atual, nem que todos os processos existentes estejam ocupados neste momento. Da mesma forma, o número máximo de processos existentes não significa que todos estejam ativos.

Os workers também podem estar à espera de consultas à base de dados ou de outros serviços externos. Por isso, compare o estado do pool e a utilização da CPU com os tempos de resposta observados: uma fila cheia com baixa utilização da CPU sugere que se deve, em primeiro lugar, analisar os tempos de espera e a ocupação dos workers. Um número maior de pools não é automaticamente a solução, uma vez que os processos adicionais também necessitam de recursos.

Os valores de estado do FPM aplicam-se ao respetivo conjunto; os contadores são reiniciados aquando de um reinício. Por isso, registe o pool e a hora do reinício no registo de medição e compare os valores dos contadores apenas dentro de um período de tempo adequado. Proteja uma página de estado ativada contra o acesso não autorizado, uma vez que esta revela informações operacionais sobre o pool.

No caso dos VPS e da hospedagem partilhada, uma vCPU atribuída não corresponde necessariamente a um núcleo físico exclusivo. Nos casos em que os dados do cgroup-v2 estão disponíveis, o comando mostra cpu.max o limite de largura de banda da CPU configurado; cpu.stat pode incluir, entre outros, contadores para Estrangulamento incluídos. As alterações nestes contadores durante uma execução ajudam a diagnosticar uma limitação efetiva.

Se possível, verifica também os cgroups de nível superior: um limite definido nesses pode influenciar o tempo de computação disponível, mesmo que a configuração imediatamente visível pareça generosa. Nem todos os contadores refletem na íntegra os limites herdados. Se estas informações não estiverem incluídas no pacote de alojamento, a visibilidade limitada constitui expressamente uma das limitações da análise.

Detetar a dispersão e os erros de medição

Uma única execução pode apresentar um quadro aleatoriamente favorável ou desfavorável. Repita os mesmos níveis de carga em momentos documentados e, sempre que possível, varie a ordem dos sistemas de comparação. Especialmente no caso de recursos partilhados, o desempenho disponível pode variar; por isso, além de um resultado típico, relate também o observado dispersão e o número de corridas.

Certifica-te de que as repetições utilizam o mesmo estado da cache e o mesmo conjunto de dados. Uma execução com a cache de páginas ou de base de dados «aquecida» não é diretamente comparável a uma execução «fria». Se uma resposta aparentemente mais rápida provier inteiramente da cache de páginas, isso pouco diz sobre a rapidez com que o PHP realiza o trabalho dinâmico.

Um microbenchmark da CLI também não constitui um resultado do FPM: é executado num contexto de execução diferente e pode utilizar outras configurações do OPcache ou do JIT. Documenta separadamente as configurações efetivamente ativas de ambos os ambientes de execução, em vez de as deduzir a partir da versão do PHP. Uma vantagem observada no microteste não tem necessariamente de se refletir na mesma magnitude no teste HTTP da aplicação.

Considera apenas as respostas corretas em termos de conteúdo e bem-sucedidas na taxa de processamento. Caso contrário, páginas de erro rápidas ou tempos de espera esgotados podem distorcer significativamente uma comparação. Em caso de desvios notáveis, verifica também os tempos de espera da base de dados, as alterações na cache e os limites visíveis de recursos, antes de atribuir a diferença exclusivamente à CPU.

O Comportamento de sincronização também pode contribuir para a dispersão. A regulação de frequência mais adequada depende da plataforma e da carga; uma configuração genérica não substitui uma comparação realizada nas mesmas condições. A contribuição para o Regulador da CPU em servidores de alojamento explica os contextos para uma análise aprofundada.

Utilizar os resultados para escolher o serviço de alojamento

Para consultas que envolvem principalmente carga de processamento da CPU, a Tempo por unidade de trabalho um critério de seleção importante. Para tal, compara uma função PHP representativa com o tempo de execução documentado e verifica, em seguida, se a vantagem também se verifica na rota HTTP dinâmica. Um microbenchmark descreve, numa primeira fase, apenas o código testado, e não toda a oferta de alojamento.

Se esperares muitos visitantes simultâneos, a consulta única rápida não é suficiente. É também fundamental saber quantas respostas corretas por segundo o sistema fornece num nível de carga definido e como se comporta a latência p95 dentro do intervalo de erro aceitável. Um sistema com maior débito não é automaticamente melhor para o teu projeto se as suas respostas lentas excederem os requisitos.

No caso de aplicações que dependem de bases de dados ou de cache, atribui uma ponderação ao Teste de aplicação é mais revelador do que uma pontuação da CPU. Um percurso típico com um conjunto de dados comparável mostra como funciona a interação da pilha nas condições selecionadas. Um resultado SPEC pode complementar a pré-seleção, mas descreve um sistema testado e não substitui um teste de alojamento web em PHP.

Antes de efetuar a seleção, define quais os tempos de resposta, taxas de erro e níveis de carga que são aceitáveis para a aplicação. Em seguida, compare apenas resultados com um modelo de carga adequado e um estado de cache comparável. Avalie os diferentes pacotes de alojamento como configurações globais; a partir da diferença entre eles, não é possível isolar a percentagem da CPU sem um diagnóstico mais aprofundado.

A decisão aplica-se à situação avaliada, não a todas as versões posteriores da aplicação ou picos de tráfego. Repete os testes relevantes após alterações significativas no PHP, na aplicação, na base de dados, na cache ou nos limites de recursos. Desta forma, poderás verificar se as reservas que antes eram suficientes continuam a existir nas novas condições.