Alojamento partilhado: quando é que os processadores rápidos ajudam, apesar do número reduzido de núcleos

Distinguir entre núcleos, threads e tempo de CPU

Um núcleo físico é uma unidade de processamento do processador. O sistema operativo, por outro lado, vê processadores lógicos como unidades executáveis: em caso de multithreading simultâneo, várias delas podem partilhar os recursos de um núcleo físico. Por isso, o seu número não permite determinar imediatamente quantos núcleos independentes estão disponíveis para uma conta de alojamento.

Na hospedagem partilhada, várias contas partilham o hardware de um servidor. Um plano pode limitar o tempo de CPU que os processos de uma conta podem consumir num determinado período. Isto Orçamento de tempo da CPU é algo diferente do compromisso de utilizar um núcleo físico de forma exclusiva. Os cgroups do Linux constituem uma base técnica possível para tais limites, mas não são a única forma possível de os implementar.

Se o plano indicar, por exemplo, „um vCore“ ou „100 por cento da CPU“, deve verificar a definição do fornecedor. Essa indicação pode referir-se a um orçamento de tempo de processamento, sem reservar permanentemente um núcleo específico. Além disso, o número total de núcleos do servidor anfitrião não indica necessariamente qual a capacidade que uma conta individual pode efetivamente utilizar em simultâneo.

A simultaneidade refere-se, neste contexto, ao número de pedidos ou processos que podem ser processados em paralelo. Depende, entre outros fatores, dos limites do processo, da memória e do orçamento de CPU disponível. O CloudLinux pode aplicar os seus próprios limites de recursos para este efeito; para saber se um plano utiliza esta técnica e como está configurada, terá de consultar o fornecedor.

A limitação de recursos e o isolamento de segurança cumprem funções diferentes: um limite controla o consumo, enquanto o isolamento tem como objetivo restringir o acesso entre ambientes. O Análise do CloudLinux Site Isolation e do CageFS explica os mecanismos de segurança correspondentes; por si só, isso não implica uma atribuição específica de CPU.

Por que razão os GHz, por si só, não são determinantes

A frequência de clock indica quantos ciclos de clock um processador executa por segundo. Uma frequência mais elevada pode acelerar as tarefas que dependem da CPU, mas, por si só, não indica em que medida um site beneficia disso. As diferentes arquiteturas de processador realizam quantidades diferentes de trabalho por ciclo de clock; o código específico do programa também influencia o resultado.

Para Desempenho de núcleo único Além disso, a cache e o comportamento da memória também contribuem para isso. Se um processo tiver de aguardar frequentemente pela disponibilização de dados, uma frequência mais elevada pode ter menos impacto do que num cálculo em que os dados já estão rapidamente disponíveis. Uma comparação baseada apenas nos GHz ignora estas diferenças e não substitui um teste de desempenho específico para a aplicação.

Um exemplo de ficha técnica resumida é o AMD EPYC 4564P: para este modelo, a AMD indica 16 núcleos, 32 threads, uma frequência de base de 4,5 GHz e um boost máximo de até 5,7 GHz. Estas especificações descrevem o processador, não o desempenho de um plano de alojamento específico.

O Potência máxima não é nem um valor constante garantido, nem a frequência que está presente em todos os núcleos a qualquer momento. Da mesma forma, os dados do produto não indicam a rapidez com que um determinado plano de alojamento partilhado processa um pedido do WordPress ou do PHP. Para isso, além do hardware, a configuração, a carga de trabalho e os limites do plano também desempenham um papel importante.

Quando os fornecedores com hospedagem de CPU de alta frequência Por isso, quando se trata de publicidade, pergunte qual é o modelo específico do processador e qual é o orçamento disponível para recursos. Para que as comparações de desempenho sejam significativas, são necessárias informações adicionais sobre a versão do software, a configuração do servidor, a carga de trabalho e as condições de teste. Sem estas informações, não é possível traduzir de forma fiável um valor de GHz anunciado num tempo de resposta mais curto.

Solicitações PHP e processamento paralelo

Numa solicitação síncrona típica, um worker PHP processa as etapas individuais do seu trabalho em PHP, na sua maioria, uma a seguir à outra. Um processador mais rápido pode reduzir esta parte, caso seja efetivamente uma tarefa que exija um grande volume de cálculos. Por outro lado, se o worker estiver principalmente à espera de uma resposta da base de dados ou de um serviço externo, o benefício de um processador mais potente para este tempo de espera é limitado.

A formulação da pesquisa PHP de núcleo único Isso não significa, portanto, que um site inteiro só possa utilizar um núcleo. Várias solicitações podem ser processadas em paralelo por vários workers; o servidor web e a base de dados também podem funcionar em simultâneo. O que é determinante é a quantidade desse trabalho paralelo que os recursos disponíveis e a respetiva configuração permitem.

No PHP-FPM, está limitado pm.max_children o número de pedidos atendidos simultaneamente por um pool. Se o limite for atingido, os pedidos adicionais não podem ser processados imediatamente por outro worker desse pool. No entanto, o limite não indica quantos visitantes, no total, podem utilizar um site.

O Gestão de processos O PHP-FPM dispõe de três modos de funcionamento: static mantém um número fixo de trabalhadores. dynamic ajusta o seu número de acordo com a configuração e a procura; ondemand inicia o Worker quando necessário. O modo de funcionamento selecionado determina, assim, também quando os processos ficam disponíveis ou são reiniciados.

Um maior número de workers não implica automaticamente mais tempo de CPU. Além disso, estes requerem memória e, quando executados em paralelo, podem atingir em conjunto o limite de uma conta. Para avaliar uma CPU de alojamento partilhado Por isso, o número de workers e o orçamento de recursos estão interligados. Nem todos os planos utilizam o PHP-FPM ou permitem que os clientes alterem eles próprios as suas configurações.

Quota da CPU em caso de carga paralela

A Quota de CPU define quanto tempo de processamento um grupo de processos pode consumir num determinado período. No Linux, o cgroup v2 descreve cpu.max este orçamento e o período correspondente. Assim, a quota não reserva automaticamente um núcleo físico exclusivo: limita o tempo de CPU total disponível para o grupo.

Exemplo ilustrativo de cálculo, não se trata de uma medição: um grupo recebe 100 milissegundos de tempo de CPU por cada período de 100 milissegundos. Isso corresponde, em média, ao tempo de cálculo de um processador lógico a funcionar a plena capacidade. Se dois processos estiverem a executar-se simultaneamente em dois processadores lógicos disponíveis, podem, teoricamente, esgotar o orçamento comum após cerca de 50 milissegundos de tempo real.

Se o orçamento estiver esgotado, os processos podem ser limitados até ao próximo período. Assim, os dois workers não dispõem, cada um, de um orçamento próprio de 100 milissegundos. Se e quando irão efetivamente funcionar em paralelo depende, entre outros fatores, do agendador, das CPUs disponíveis e do seu comportamento; o exemplo não prevê um tempo de resposta concreto.

Para a análise, o cgroup v2 em cpu.stat entre outros, contadores para Estrangulamento prontos. Se aumentarem durante uma fase de carga representativa, isso indica que a cota foi esgotada. No entanto, uma única leitura do contador não explica ainda qual foi a solicitação afetada nem se existem outros pontos de estrangulamento.

Terás de esclarecer com o fornecedor se esses ficheiros estão acessíveis no plano e se são relevantes para o site. A hospedagem partilhada pode utilizar outros mecanismos: o CloudLinux, por exemplo, documenta os seus próprios limites LVE para a CPU e outros recursos. Por isso, a partir do exemplo do Linux, não é possível deduzir nem a configuração concreta nem o comportamento de cada conta de hospedagem.

CMS, loja online e tarefas em segundo plano

No caso de uma página CMS sem cache, o servidor executa a lógica de aplicação para a chamada e obtém os dados necessários. Se uma grande parte do processamento recair sobre Trabalho da CPU, um maior desempenho por núcleo pode encurtar esta secção. Isto aplica-se, por exemplo, a cálculos complexos no código PHP, mas não automaticamente a todo o tempo necessário até a página estar pronta.

Se, pelo contrário, essa mesma solicitação depender principalmente de uma consulta a uma base de dados ou de uma API externa, o processo PHP só poderá beneficiar de forma limitada de um CPU mais rápido durante esse tempo. Por isso, o que conta para a decisão é a repartição do tempo de resposta do lado do servidor: quanto tempo é dedicado ao cálculo e quanto tempo é gasto à espera de outros serviços?

Uma loja mostra porque é que esta questão pode ter respostas diferentes consoante as páginas. As páginas públicas de produtos podem ser guardadas na cache como respostas prontas, desde que se cumpram as condições adequadas. Um Acessos ao cache pode evitar que o PHP tenha de ser processado novamente na íntegra; por outro lado, o cesto de compras e o checkout têm frequentemente de ter em conta dados específicos e mantêm-se dinâmicos.

Por isso, muitas solicitações simultâneas de checkout podem sobrecarregar os workers ou o orçamento da CPU mais do que um número idêntico de chamadas a páginas armazenadas em cache. O número de visitantes, por si só, não descreve esta carga: o que é decisivo é quais os pontos finais que são solicitados simultaneamente e com que frequência o cache é utilizado. No PHP-FPM, a configuração do pool também limita pm.max_children o número de pedidos atendidos simultaneamente.

Uma importação que exige um grande volume de cálculos no backend pode, por sua vez, beneficiar de um processamento individual mais rápido. Se for executada em paralelo com os pedidos dos visitantes, os processos podem vir a competir pelo mesmo orçamento de tempo de CPU. O facto de uma tarefa cron ou uma importação estar efetivamente atribuída ao mesmo grupo limitado depende do plano de preços e da sua configuração; antes de tomar uma decisão relativa à capacidade, consulte o fornecedor.

Para uma comparação significativa, deves analisar estas cargas de trabalho separadamente: um pedido dinâmico típico, uma fase com vários pedidos simultâneos e, se for o caso, a importação durante o funcionamento normal. Desta forma, será mais fácil perceber se a velocidade de uma etapa específica ou a capacidade total disponível é o fator mais importante a ajustar.

Comparar observações e pontos de estrangulamento

Uma resposta lenta não indica, por si só, uma causa. A visão geral que se segue associa observações típicas a possibilidades que podem ser verificadas. Tem em conta, em particular, os limites de tempo da CPU, o número limitado de workers no PHP-FPM e a diferença entre o código PHP armazenado e uma resposta já gerada.

Cada linha da tabela é uma Hipótese, não é um diagnóstico definitivo. Respostas lentas em situações de paralelismo podem, por exemplo, estar relacionadas com uma limitação da CPU, mas também podem ser causadas por workers ocupados ou por uma base de dados em espera. Por isso, sempre que possível, analisa vários sinais ao mesmo tempo e para a mesma carga de trabalho, em vez de deduzir a necessidade de mudar de tarifa com base num único sintoma.

Na análise, separa os Tempo de resposta uma consulta em termos de débito: uma resposta individual mais rápida não significa automaticamente que, em condições de elevada simultaneidade, sejam processadas mais consultas por segundo. Por outro lado, um sistema pode atingir um bom débito e, mesmo assim, fazer com que as consultas individuais demorem mais tempo a ser respondidas.

O tempo de carregamento da página percebido também não deve ser equiparado ao tempo de resposta do servidor. Após a resposta, por exemplo, podem ser carregados e processados no navegador outros recursos. Uma atualização da CPU no serviço de alojamento aborda apenas a parte afetada do lado do servidor; para uma comparação justa, o estado da cache, a página solicitada e o paralelismo devem permanecer inalterados.

No que diz respeito à cache, vale também a pena fazer uma distinção conceptual: a OPcache armazena código PHP compilado, permitindo assim evitar uma nova compilação. Por outro lado, uma cache de páginas mantém uma resposta já gerada. Um acerto rápido na cache não prova, portanto, nem que as solicitações dinâmicas dispõem de recursos de CPU suficientes, nem que a OPcache substitui a lógica da aplicação.

Detetar congestionamentos e tempos de espera

Começa o diagnóstico com pedidos típicos do teu site: por exemplo, uma página pública do CMS, uma pesquisa e, no caso de uma loja online, o processo de checkout. Verifica se a resposta em questão provém da cache da página. Em seguida, compara as consultas individuais com um número de consultas simultâneas representativo do teu projeto, em vez de te limitares a considerar apenas o número total de visitantes.

Sempre que possível, separa o tempo de CPU da aplicação depende do tempo de resposta total e dos tempos de espera na base de dados ou em serviços externos. Se a parte atribuída à CPU for pequena, um processador mais rápido só poderá reduzir uma parte correspondentemente limitada da chamada. Se não tiveres valores de medição adequados, pede ao fornecedor os registos, métricas ou uma análise adequada disponíveis.

Em caso de carga paralela, verifica se os workers disponíveis estão a funcionar a plena capacidade e se os contadores de limite estão a aumentar. No PHP-FPM, limita pm.max_children as solicitações atendidas simultaneamente por um pool; a possibilidade de visualizar este valor ou a taxa de utilização depende do plano. Os sistemas Linux cgroup v2 podem, em cpu.stat incluindo, entre outros, contadores de limitação. Um contador em aumento é motivo para analisar com mais detalhe o orçamento da CPU e o período de medição.

Se o SSH e o ficheiro em questão estiverem acessíveis, o comando mostra cat /proc/self/cgroup a atribuição ao cgroup do processo que está a chamar. Isso não significa, necessariamente, que os pedidos Web sejam executados no mesmo grupo. Esclareça os caminhos, os direitos e a interpretação com o fornecedor; além disso, os códigos de erro não podem ser atribuídos de forma generalizada a um determinado limite de cada sistema de alojamento partilhado.

Verificar a cache e comparar tarifas

Verifica primeiro quais as páginas públicas que podem ser guardadas em cache com segurança como resposta completa. Uma Cache de páginas pode evitar o processamento dinâmico repetido em caso de correspondência. Por outro lado, os conteúdos personalizados, o cesto de compras e o checkout requerem uma estratégia de cache adequada, para que os visitantes não recebam dados alheios ou desatualizados.

Outra abordagem consiste em reduzir o trabalho em caso de falhas de cache: analisa as consultas lentas à base de dados e elimina o processamento dinâmico desnecessário. No caso de um serviço externo, o seu tempo de resposta pode ser determinante; nesse caso, deve analisar primeiro essa chamada, em vez de assumir que a CPU é a causa. A alteração que ajuda depende do caminho que está efetivamente a ser lento.

É preciso distinguir isto de OPcache: Armazena código PHP compilado, mas não substitui nem o cache completo da página nem a execução da lógica da aplicação. Verifique a disponibilidade e as definições no ambiente de execução web. A CLI possui uma configuração própria para o OPcache; por isso, uma simples verificação na linha de comandos não é suficiente para determinar a configuração para pedidos Web.

Para comparar tarifas, deve comparar as mesmas consultas com as mesmas versões de software, conjuntos de dados comparáveis e estado da cache registado. Repita a comparação com o mesmo nível de paralelismo e tenha em conta os orçamentos disponíveis de CPU, workers e memória em cada caso. Caso contrário, poderá surgir uma diferença devido às condições de teste, sem que isso permita tirar conclusões fiáveis sobre o desempenho do processador.

Além disso, registe separadamente quanto tempo demora cada resposta e quantas solicitações são processadas num determinado período. Um plano tarifário pode parecer económico para uma única chamada, mas, em caso de carga simultânea, pode atingir os seus limites. Os valores resultantes de uma comparação aplicam-se, numa primeira fase, apenas à aplicação analisada e às suas condições.

Um processador mais rápido ou um orçamento maior?

Se uma consulta dinâmica representativa realizar principalmente trabalho de CPU e não houver limitações em termos de workers, memória ou orçamento de tempo, é preferível uma maior Potência por núcleo uma opção de tarifa plausível. Pode reduzir a parte computacional da consulta individual. No entanto, o impacto que isso tem na resposta global continua a depender da aplicação e dos seus tempos de espera.

Se, pelo contrário, os dados indicarem uma limitação de largura de banda ou workers sobrecarregados em caso de várias solicitações simultâneas, verifica-se se é necessário um maior Orçamento de recursos. Um aumento do tempo de CPU pode ajudar quando o limite da quota está esgotado; ao mesmo tempo, os workers adicionais necessitam de memória e tempo de processamento suficientes. Se o estrangulamento for causado pela base de dados ou por serviços externos, um maior orçamento de CPU, por si só, não constitui uma solução fiável.

Antes de mudar, vale a pena comparar com a otimização da instalação existente. Uma cache de páginas adequada ou uma consulta melhorada podem reduzir o trabalho dinâmico, sem que seja necessário optar imediatamente por um plano superior. Repete o diagnóstico após uma alteração, em condições comparáveis, para que possas distinguir o seu efeito de outras influências.

A O VPS como alternativa à hospedagem partilhada Oferece, na maioria das vezes, maior influência sobre o software e a configuração, mas implica também maior responsabilidade pela segurança, pelas atualizações e pelo planeamento da capacidade. As CPUs virtuais não são núcleos físicos exclusivos, salvo indicação expressa do fornecedor. Por isso, verifica também a atribuição concreta de recursos e as condições do contrato.

Antes de tomares uma decisão, pergunta ao fornecedor qual é o modelo do processador, qual é a definição do orçamento de tempo da CPU e como são geridas as picos de carga. Esclarece também quais são os limites de workers e de memória aplicáveis, se as tarefas em segundo plano partilham o mesmo orçamento e quais os contadores de limites a que tens acesso. Só com estas informações é que se pode avaliar o desempenho da CPU anunciado para o teu plano específico.