Nous casserons le serveur Web et le remplirons de paquets de requĂȘtes HTTP. Remplissez lentement tout ce qui se trouve autour de HTTP flood et observez une dĂ©gradation complĂšte. PrĂ©parez-vous Azure, il n'y aura pas de quoi rire!
Si un peu plus sérieusement, tout en effectuant des laboratoires standard sur la connaissance d'Azure dans le cadre d'AZ-900, Microsoft Azure Fundamentals a décidé de voir de quoi est capable l'une des configurations minimales des machines virtuelles Standard B1 (1 Gio de RAM, 1 vCPU).
Dans les laboratoires standard, un serveur Web comme Apache ou IIS est installĂ© sur la machine virtuelle, un site simple est lancĂ© et c'est lĂ que tout se termine. Il m'a semblĂ© qu'une telle connaissance ne suffisait pas et il est devenu intĂ©ressant de voir comment le serveur va rĂ©pondre Ă un grand nombre de requĂȘtes, ce qu'il adviendra du temps de rĂ©ponse et, surtout, si la modification de la taille de la machine virtuelle va contribuer Ă amĂ©liorer la qualitĂ© du travail. De plus, pour ajouter des soucis au serveur, WordPress (Apache, MySQL, PHP) a Ă©tĂ© mis en place sur une machine virtuelle avec Ubuntu. Pour le test, un script Python a Ă©tĂ© utilisĂ© qui gĂ©nĂ©rait en continu des requĂȘtes GET Ă la mĂȘme adresse.
Dans le cas de requĂȘtes uniques, le temps de rĂ©ponse du serveur ne dĂ©passait pas 300-400 ms, ce qui semblait tout Ă fait acceptable pour une telle configuration.
Une autre chose est de savoir comment le serveur rĂ©agira aux demandes en masse lorsque les GET arrivent par lots. En Python, de telles requĂȘtes parallĂšles peuvent ĂȘtre implĂ©mentĂ©es Ă l'aide du module «concurrent.futures», qui permet d'accĂ©der Ă une interface de haut niveau pour les appels asynchrones. L'idĂ©e de mise en Ćuvre a Ă©tĂ© inspirĂ©e par la ressource creativedata.stream . En consĂ©quence, pour le test, le serveur a Ă©tĂ© attaquĂ© par une vague de requĂȘtes GET avec un nombre linĂ©airement croissant de requĂȘtes simultanĂ©es. Pour plus de clartĂ©, le temps de rĂ©ponse pour chaque demande Ă©tait limitĂ© Ă 10 secondes. Pour chaque tentative, 5 000 demandes ont Ă©tĂ© envoyĂ©es. Il y a un dĂ©lai d'attente de 3 minutes entre les tentatives.
Les résultats des tests pour les VM Standard B1 sont indiqués dans le tableau
Nombre de requĂȘtes GET parallĂšles |
Temps (s) de test |
Temps de réponse moyen |
Temps de réponse maximal (s) |
Nombre de refus |
Dix |
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 .
Place aux conclusions
Ce test avec HTTP flood et l'implĂ©mentation actuelle ne prĂ©tend pas conquĂ©rir l'espace et suivre les standards de l'or. Cependant, les tests ont montrĂ© la relation directe attendue entre le nombre de requĂȘtes simultanĂ©es et la charge sur le processeur, la mĂ©moire et les temps de rĂ©ponse moyens et maximum.
Apparemment, un serveur avec une grande quantitĂ© de RAM (4 Go contre 1 Go) fait mieux face Ă ce type de charge, et mĂȘme avec une multiplication par 5 du nombre de requĂȘtes (160 contre 30), il rĂ©pond rĂ©guliĂšrement avec 200 OK!
PS
Un exemple d'utilitaire de test est disponible dans mon référentiel sur github