Romperemos el servidor web y lo llenaremos con un montón de solicitudes HTTP. Llene lentamente todo a su alrededor con la inundación HTTP y observe la degradación completa. ¡Prepárate, Azure, no habrá motivo de risa!
Si es un poco más serio, mientras realizaba laboratorios estándar familiarizados con Azure como parte de AZ-900, Microsoft Azure Fundamentals decidió ver de qué es capaz una de las configuraciones mínimas de las máquinas virtuales estándar B1 (1 GiB de RAM, 1 vCPU).
En los laboratorios estándar, se instala un servidor web como Apache o IIS en la máquina virtual, se lanza un sitio simple y aquí es donde todo termina. Me pareció que un conocimiento así no era suficiente y se volvió interesante ver cómo el servidor responderá a una gran cantidad de solicitudes, qué pasará con el tiempo de respuesta y, lo más importante, si cambiar el tamaño de la máquina virtual ayudar a mejorar la calidad del trabajo. Además, para agregar preocupaciones al servidor, WordPress (Apache, MySQL, PHP) se creó en una máquina virtual con Ubuntu. Para la prueba, se utilizó un script de Python que generaba continuamente solicitudes GET a la misma dirección.
En el caso de solicitudes únicas, el tiempo de respuesta del servidor no excedió los 300-400 ms, lo que parecía bastante aceptable para tal configuración.
Otra cosa es cómo reaccionará el servidor a las solicitudes masivas cuando los GET lleguen en lotes. En Python, estas solicitudes paralelas se pueden implementar utilizando el módulo "concurrent.futures", que proporciona acceso a una interfaz de alto nivel para llamadas asincrónicas. La idea de implementación se inspiró en el recurso creativedata.stream . Como resultado, para la prueba, el servidor fue atacado por una ola de solicitudes GET con un número cada vez mayor de solicitudes simultáneas. Para mayor claridad, el tiempo de respuesta para cada solicitud se limitó a 10 segundos. Por cada intento, se enviaron 5000 solicitudes. Hay un tiempo de espera de 3 minutos entre intentos.
Los resultados de la prueba para VM Standard B1 se muestran en la tabla
Número de solicitudes GET paralelas |
Tiempo de prueba (s) |
Tiempo medio de respuesta (s) |
Tiempo máximo de respuesta (s) |
Número de negativas |
diez |
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 .
Espacio para conclusiones
Esta prueba con HTTP flood y la implementación actual no pretende conquistar el espacio y seguir los estándares de oro. Sin embargo, las pruebas mostraron la relación directa esperada entre el número de solicitudes simultáneas y la carga en la CPU, la memoria y los tiempos de respuesta promedio y máximo.
Aparentemente, un servidor con una gran cantidad de RAM (4Gb frente a 1Gb) hace frente mejor a este tipo de carga, e incluso con un aumento de 5 veces en el número de solicitudes (160 frente a 30), normalmente responde con 200 ¡OK!
PD
Un ejemplo de una utilidad de prueba está disponible en mi repositorio en github