Wir werden den Webserver beschädigen und ihn mit einer Reihe von HTTP-Anfragen füllen. Füllen Sie langsam alles mit HTTP-Flut und beobachten Sie eine vollständige Verschlechterung. Machen Sie sich bereit Azure, es wird keine lachende Angelegenheit geben!
Wenn Microsoft Azure Fundamentals bei der Durchführung von Standardlabors zur Kenntnisnahme von Azure im Rahmen von AZ-900 etwas ernsthafter ist, hat sich Microsoft Azure Fundamentals entschlossen, herauszufinden, wozu eine der Mindestkonfigurationen von virtuellen Standard B1-Maschinen (1 GiB RAM, 1 vCPU) in der Lage ist.
In Standardlabors wird ein Webserver wie Apache oder IIS auf der virtuellen Maschine installiert, eine einfache Site wird gestartet und hier endet alles. Es schien mir, dass eine solche Bekanntschaft nicht ausreichte und es wurde interessant zu sehen, wie der Server auf eine große Anzahl von Anfragen reagiert, was aus der Antwortzeit wird und vor allem, ob sich die Größe der virtuellen Maschine ändert helfen, die Qualität der Arbeit zu verbessern. Um dem Server Sorgen zu machen, wurde WordPress (Apache, MySQL, PHP) auf einer virtuellen Maschine mit Ubuntu gestartet. Für den Test wurde ein Python-Skript verwendet, das kontinuierlich GET-Anforderungen an dieselbe Adresse generierte.
Bei Einzelanforderungen überschritt die Serverantwortzeit 300-400 ms nicht, was für eine solche Konfiguration durchaus akzeptabel erschien.
Eine andere Sache ist, wie der Server auf Massenanforderungen reagiert, wenn GETs in Stapeln ankommen. In Python können solche parallelen Anforderungen mithilfe des Moduls "concurrent.futures" implementiert werden, das den Zugriff auf eine übergeordnete Schnittstelle für asynchrone Aufrufe ermöglicht. Die Implementierungsidee wurde von der Ressource creativedata.stream inspiriert . Infolgedessen wurde der Server für den Test von einer Welle von GET-Anforderungen mit einer linear ansteigenden Anzahl gleichzeitiger Anforderungen angegriffen. Aus Gründen der Übersichtlichkeit wurde die Antwortzeit für jede Anforderung auf 10 Sekunden begrenzt. Für jeden Versuch wurden 5000 Anfragen gesendet. Zwischen den Versuchen liegt eine Zeitüberschreitung von 3 Minuten.
Die Testergebnisse für VM Standard B1s sind in der Tabelle aufgeführt
Anzahl der parallelen GET-Anforderungen |
Testzeit (en) |
Durchschnittliche Antwortzeit (en) |
Maximale Antwortzeit (en) |
Anzahl der Ablehnungen |
zehn |
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 .
Raum für Schlussfolgerungen
Dieser Test mit HTTP-Flut und der aktuellen Implementierung gibt nicht vor, den Weltraum zu erobern und den Goldstandards zu folgen. Die Tests zeigten jedoch die erwartete direkte Beziehung zwischen der Anzahl gleichzeitiger Anforderungen und der Belastung der CPU, des Speichers sowie der durchschnittlichen und maximalen Antwortzeiten.
Anscheinend kommt ein Server mit einer großen Menge an RAM (4 GB gegenüber 1 GB) besser mit dieser Art von Last zurecht, und selbst bei einer Verfünffachung der Anzahl der Anforderungen (160 gegenüber 30) antwortet er regelmäßig mit 200 OK!
PS
Ein Beispiel für ein Testdienstprogramm finden Sie in meinem Repository auf github