Vamos quebrar o servidor web e preenchê-lo com um monte de solicitações HTTP. Lentamente, preencha tudo ao redor com inundação de HTTP e observe a degradação completa. Prepare-se Azure, não haverá motivo para risos!
Se um pouco mais a sério, ao realizar laboratórios padrão sobre familiaridade com o Azure como parte do AZ-900, os Fundamentos do Microsoft Azure decidiram ver o que uma das configurações mínimas de máquinas virtuais Standard B1s (1 GiB RAM, 1 vCPU) é capaz.
Em laboratórios padrão, um servidor web como Apache ou IIS é instalado na máquina virtual, um site simples é iniciado e é onde tudo termina. Pareceu-me que tal conhecimento não era suficiente e tornou-se interessante ver como o servidor responderá a um grande número de solicitações, o que acontecerá com o tempo de resposta e, o mais importante, se mudar o tamanho da máquina virtual irá ajudar a melhorar a qualidade do trabalho. Além disso, para adicionar preocupações ao servidor, o WordPress (Apache, MySQL, PHP) foi criado em uma máquina virtual com Ubuntu. Para o teste, foi usado um script Python que gerou continuamente solicitações GET para o mesmo endereço.
No caso de solicitações únicas, o tempo de resposta do servidor não excedeu 300-400 ms, o que parecia bastante aceitável para tal configuração.
Outra coisa é como o servidor reagirá a solicitações em massa quando GETs chegarem em lotes. Em Python, essas solicitações paralelas podem ser implementadas usando o módulo “concurrent.futures”, que fornece acesso a uma interface de alto nível para chamadas assíncronas. A ideia de implementação foi inspirada no recurso creativedata.stream . Como resultado, para o teste, o servidor foi atacado por uma onda de solicitações GET com um número linearmente crescente de solicitações simultâneas. Para maior clareza, o tempo de resposta para cada solicitação foi limitado a 10 segundos. Para cada tentativa, 5.000 solicitações foram enviadas. Há um tempo limite de 3 minutos entre as tentativas.
Os resultados do teste para VM Standard B1s são mostrados na tabela
Número de solicitações GET paralelas |
Tempo (s) de teste |
Tempo médio de resposta |
Tempo (s) máximo (s) de resposta |
Número de recusas |
dez |
246 |
0,482504 |
1.393406 |
0 |
20 |
183 |
0,716227 |
1.775027 |
0 |
30 |
158 |
0.925803 |
2.239563 |
0 |
40 |
133 |
1.028995 |
10.389413 |
4773 |
40 , , “200” 100%.
. . .
, . B1s Standard B2s (4GiB RAM, 2 vCPU). ?
, . 10000.
VM Standard B2s
- GET |
() |
() |
() |
|
20 |
198 |
0.387310 |
1.377070 |
0 |
40 |
171 |
0.660414 |
1.481950 |
0 |
60 |
140 |
0.808657 |
1.674038 |
0 |
80 |
130 |
1.001915 |
2.142157 |
0 |
100 |
119 |
1.163476 |
2.252231 |
0 |
120 |
119 |
1.417223 |
2.703418 |
0 |
140 |
119 |
1.654639 |
2.98774 |
0 |
160 |
119 |
1.901040 |
5.622294 |
0 |
. , . , .
160 5Mb/s .
Espaço para conclusões Este teste com inundação de HTTP e a implementação atual não pretende conquistar espaço e seguir os padrões ouro. No entanto, os testes mostraram a relação direta esperada entre o número de solicitações simultâneas e a carga na CPU, memória e tempos de resposta médio e máximo.
Aparentemente, um servidor com uma grande quantidade de RAM (4 Gb versus 1 Gb) lida melhor com esse tipo de carga e mesmo com um aumento de 5 vezes no número de solicitações (160 contra 30), ele responde regularmente com 200 OK!
PS
Um exemplo de utilitário de teste está disponível em meu repositório no github