Teste de carga do Apache em um VPS pequeno
Data de Publicação:
Atualizado:
Artigos > Teste de carga do Apache em um VPS pequeno
status 2026 e uso seguro
Conclusão: este artigo registra um experimento VPS, não um limite universal de simultaneidade do Apache. A capacidade depende do trabalho de resposta, do MPM, dos limites de trabalho, do keep-alive, do TLS, da CPU, da memória, do armazenamento, da rede, do posicionamento do cliente e da meta de latência que você define como aceitável.
O que você aprenderá
- Como o teste original foi organizado e o que os números observados mostram (e não mostram).
- Quais métricas do Apache e do sistema operacional ajudam a identificar o primeiro gargalo.
- Como projetar um teste de carga repetível com aquecimento, percentis, erros e telemetria do lado do servidor.
A quem se destina: Engenheiros que planejam um experimento de primeira passagem com um servidor web em um pequeno VPS.
Atualização para 2026: As medidas abaixo são preservadas do ambiente original do autor e não foram executadas novamente para esta atualização. Não os utilize como referência atual do fornecedor ou recomendação de dimensionamento de produção; teste seu próprio aplicativo e limites de falha.
Nota de segurança: os comandos e exemplos de configuração do artigo original não foram novamente executados num ambiente de produção atual. Antes de os aplicar, confirme as versões suportadas, as cópias de segurança, os controlos de acesso e o procedimento de reversão num ambiente de teste isolado.
Fontes primárias oficiais
Visão geral
Medi o número máximo de casos que o servidor web (Apache) pode processar ao mesmo tempo, e gostaria de escrever sobre os resultados. Estávamos curiosos sobre o número máximo de pedidos que podiam ser atendidos, por isso realizámos um inquérito. Use isto como referência para seleccionar as especificações do servidor VPS.
Desta vez, as medições foram efectuadas apenas na WEB (Apache), mas por favor consulte o artigo abaixo para medições nos servidores WEB/AP (Apache e Tomcat).
Tabela de Conteúdos
1. medição
1-1. Ambiente de medição
O seguinte é o ambiente em que as medições serão feitas.
■Informação sobre o servidor de aluguer
| CPU | 2core |
|---|---|
| memory | 1GB |
| SSD | 50GB |
■Informação do servidor
| OS | CentOS 7.4 64bit |
|---|---|
| Servidor Web | Apache HTTP Server 2.4.41 |
1-2. Método de medição
Gostaria de medir isto usando o JMeter. O JMeter é uma ferramenta de medição de carga que funciona em Java. A ferramenta permite que um grande número de pedidos seja lançado ao mesmo tempo. Gostaríamos de aumentar gradualmente o número de pedidos simultâneos utilizando JMeter e aumentar a carga até que o processamento não possa mais ser tratado.
As condições específicas incluem.
- intervalo de pedido: 5 seg.
- Número de pedidos simultâneos: 10 casos. (As medições aumentaram gradualmente em 10 casos cada.)
- Tempo de medição: 60 segundos.
O tempo de medição é de "60 segundos" e o intervalo de solicitação de "5 segundos", pelo que se pretende aceder ao sistema 12 vezes (60÷5) repetidamente.
1-3. resultado da medição
No final, muitas pessoas estão interessadas na conclusão das especificações com que o servidor pode lidar e quanto pode lidar, por isso gostaria de declarar a conclusão primeiro.
| CPU: 2core memory: 1GB SSD: 50GB | Podem ser processados até 120 pedidos simultâneos. |
|---|
Os resultados desta medição mostraram o acima exposto. Os resultados acima referidos sugerem que se pode inferir o seguinte. Tente usar isto como um critério ao escolher as especificações do servidor.
| CPU: 1core memory: 512MB SSD: 25GB | Podem ser processados até 60 pedidos simultâneos. |
|---|---|
| CPU: 2core memory: 1GB SSD: 50GB | Podem ser processados até 120 pedidos simultâneos. |
| CPU: 3core memory: 2GB SSD: 100GB | Podem ser processados até 240 pedidos simultâneos. |
Mesmo com especificações de "CPU: 1core", "memória: 512MB" e "SSD: 25GB", descobriu-se que um sistema de cerca de 60 pessoas podia funcionar sem problemas.
2. Detalhes dos resultados das medições
Descrevemos os resultados de medição mais cedo, mas se estiver interessado no tipo de resultados que descrevemos, por favor verifique também os detalhes dos resultados de medição que serão descritos no futuro.
2-1. Medidas do servidor WEB (Apache)
Pedidos repetidos foram lançados contra páginas criadas em HTML. Esta é uma página simples, sem processamento PHP ou complexidade JavaScript.
As medições mostraram os seguintes resultados.
- Para 10 pedidos simultâneos⇒OK
- Para 20 pedidos simultâneos⇒OK
- Para 30 pedidos simultâneos⇒OK
- Para 40 pedidos simultâneos⇒OK
- Para 50 pedidos simultâneos⇒OK
- Para 60 pedidos simultâneos⇒OK
- Para 70 pedidos simultâneos⇒OK
- Para 80 pedidos simultâneos⇒OK
- Para 90 pedidos simultâneos⇒OK
- Para 100 pedidos simultâneos⇒OK
- 110 pedidos simultâneos⇒OK
- Para 120 pedidos simultâneos⇒OK
- Para 130 pedidos simultâneos⇒NG
O erro ocorreu no 130º caso. A causa foi um erro de ligação ao Apache. O estado do servidor, nesta altura, era o seguinte.
- Utilização da CPU: 26%
- taxa de utilização de memória: 100%
Uma completa falta de memória foi o engarrafamento.
Para o ligeiramente mais totó, a configuração do Módulo Multi-Processamento Apache (MPM) é a seguinte. O MPM é simplesmente explicado como a definição de quanto Apache é permitido processar em paralelo.
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxRequestWorkers 250
MaxConnectionsPerChild 0
</IfModule>
O cenário de interesse é "250" para "MaxRequestWorkers". Este é um cenário para o número máximo de casos que o Apache pode processar ao mesmo tempo. 250", pelo que 250 casos podiam ser processados em paralelo no máximo, mas olhando para a utilização de memória, foram utilizados cerca de 8 MB de memória por caso.
Parecia estar a utilizar 960 MB de memória (8M x 120 processos) e o valor de configuração era de '250', mas parecia que não era possível criar mais de '120' processos.
Nota: A memória do servidor está quase até ao seu limite de 1G.
Quando o servidor está realmente a funcionar, se PHP e Java também estiverem incluídos, o limite é de cerca de 100 casos, e se houver espaço, 80 casos podem ser processados simultaneamente em paralelo.
Quando apenas o Apache está instalado e a funcionar, com especificações "CPU: 2core, memória: 1GB, SSD: 50GB", o número de acessos simultâneos "120" foi considerado como sendo o limite.
2-2. consideração
A partir daqui torna-se uma consideração, mas como a memória é o gargalo, se a memória for alterada, o número de processos que podem ser processados concomitantemente também aumentará.
(Presente. (memory1GB))
- memory: 1GB
- Número de fios Apache: 120 casos
- Consumo de memória por fio no Apache.: 8MB
- Consumo de memória Apache: 960MB(120 casos×8MB)
(após a mudança(memory2GB))
- memory: 2GB
- Número de fios Apache: 240 casos.
- Consumo de memória por fio no Apache.: 8MB
- Consumo de memória Apache: 1920MB(240 casos.×8MB)
Se a memória for aumentada para 2 GB, poderá ser possível duplicar o número de casos para cerca de 240 ao mesmo tempo. Se a memória for aumentada para 3GB, parece que se pode fazer mais processamento simultâneo, mas o "MaxRequestWorkers (número máximo de casos a serem processados simultaneamente)" do MPM do Apache é "250", pelo que também será necessário afinar aqui se a memória for aumentada ainda mais. Inversamente, se a memória fosse reduzida para metade, seria o seguinte.
(após a mudança(memory512GB))
- memory: 512GB
- Número de fios Apache: 60 casos.
- Consumo de memória por fio no Apache.: 8MB
- Consumo de memória Apache: 480MB(60 casos.×8MB)
3. resumo
Medimos o número máximo de casos que o servidor web (Apache) pode processar ao mesmo tempo. Foi descoberto que um sistema de cerca de 60 pessoas podia ser operado sem problemas com "CPU: 1core", "memória: 512MB" e "SSD: 25GB".
O inquérito baseia-se no pressuposto de que nenhum outro software está a funcionar com um desempenho marginal. Recomenda-se a escolha de uma especificação com um pouco de margem de manobra, já que se trata de um valor marginal.