En este artículo compartiremos nuestra propia experiencia práctica que obtuvimos al probar la aplicación de aplicaciones web (tienda en línea) que se ejecuta en la nube de MS Azure, así como también describiremos qué herramientas utilizamos para resolver este problema y las conclusiones que se hicieron en base a los hallazgos resultados.
Objeto de prueba
Elegimos VirtoCommerce Storefront (una aplicación web utilizada como interfaz de las aplicaciones creadas en la plataforma VirtoCommerce) como objetos de prueba.
Para obtener una imagen real de las capacidades del sistema, necesitamos simular las solicitudes de los usuarios lo más cerca posible de la realidad. No tiene sentido verificar la página principal, que puede estar en el caché, y luego afirmar que nuestra velocidad fue de 1k req / seg. No tiene sentido en una métrica de rendimiento en la vida real.
Por lo tanto, para que los resultados de nuestras pruebas sean estadísticamente significativos y reflejen los indicadores de rendimiento del tráfico real lo más cerca posible, se decidió utilizar consultas lo más cercanas posible al comportamiento real del usuario en la tienda en línea.
Detengámonos en las siguientes acciones, en las cuales consistirá nuestra prueba "real":
Acción del usuario (tipo de prueba)
| Porcentaje de solicitudes totales
|
Ver una página de categoría única con sus productos.
| 30%
|
Ver una tarjeta de producto única
| 40%
|
Agregar artículos al carrito
| 10%
|
Busque productos por una palabra clave o atributo único
| 20%
|
Fig. 1. Las principales acciones de los usuarios y su frecuencia específica de uso.Preparación de datos de prueba
La fase más importante para cualquier prueba es la preparación de datos. Los datos de prueba deben seleccionarse de tal manera que corresponda lo más posible a los datos en un sistema real, tanto en cantidad como en calidad (comunicación, estructura, etc.). Si es posible, la cantidad total de datos debería ser suficiente para que, al realizar la prueba, haya la menor cantidad posible de llamadas repetidas a los mismos datos, lo que evitará el uso frecuente de la memoria caché y, como resultado, obtendrá la imagen más pesimista del rendimiento del sistema.
Los datos principales de la tienda en línea, por regla general, son: un catálogo de productos y categorías con precios, descuentos e información sobre saldos.
Como relleno del entorno de prueba, se utilizaron datos de catálogo reales, que se utilizarán en el entorno de producción principal:
Fig.2. Datos utilizados para poblar el sistema bajo prueba.Está claro que para un lector que no está familiarizado con la estructura del catálogo de VirtoCommerce, algunos tipos de datos pueden no significar nada, pero los presentaremos para al menos tener una idea del orden cuantitativo.
Preparación de proyectos y pruebas de grabación.
Como herramienta principal para las pruebas de carga, usaremos MS Visual Studio Enterprise 2017 (otras ediciones de estudio pueden no ser compatibles con este tipo de proyecto) y el tipo de proyecto
Proyecto de prueba de carga y rendimiento web .
Fig.3. Crea un nuevo proyecto.Después de crear el proyecto, necesitaremos crear pruebas para cada una de las acciones del usuario definidas previamente. Nos limitamos a crear una prueba para una acción de usuario como ejemplo, ya que el resto de las acciones se crean por analogía.
Para las pruebas, utilizaremos el tipo estándar de prueba Web Performance Test, integrado en Visual Studio.
Nuestra primera prueba que crearemos será una prueba que revela los detalles del producto en una tienda en línea.
Para crear una prueba, seleccione el tipo de prueba
"Prueba de rendimiento web" de la lista que ofrece Studio, establezca el nombre
"Storefront-ProductDetail" .
Fig.4. Elegir un tipo de prueba en Visual Studio.Para este tipo de prueba, Visual Studio intentará inmediatamente abrir un navegador, donde será posible hacer clic de forma interactiva en las acciones necesarias directamente en el sitio, pero no haremos esto, pero cerraremos inmediatamente el navegador y dejaremos de grabar. Como resultado, obtenemos una prueba de
Storefront-ProductDetail.webtest vacía.
A continuación, necesitamos agregar una fuente de datos para esta prueba, de modo que podamos usar diferentes parámetros de consulta dentro de la misma prueba, para esto, la
prueba de rendimiento web de V
S Studio brinda esa oportunidad.
Como fuente de datos para nuestra prueba, utilizaremos una tabla en la base de datos donde se almacenan los registros del producto. Después de eso, podremos usar los datos de la fuente conectada en la solicitud, que debería abrir los detalles del producto en la aplicación probada. Esto se logra insertando la construcción
"{{Nombre de fuente de datos. Nombre de tabla. Nombre de columna}}"Como resultado, después de todas las manipulaciones, nuestra primera prueba tomará esta forma.
Fig. 5. Contenido de la prueba.Es hora de la primera ejecución, intente ejecutar nuestra prueba y asegúrese de que funcione correctamente.
Fig. 6. El resultado de una sola pruebaPor analogía, crearemos pruebas para todos nuestros otros escenarios.
Fig. 7. El conjunto de pruebas resultanteDespués de eso, casi todo está listo para crear una prueba combinada que emulará el comportamiento real del usuario en el sitio.
Para hacer esto, agregue un nuevo
LoadTest a nuestro proyecto
.
Fig.8. Crea una nueva prueba de cargaEn el asistente que aparece, seleccione el tipo
Prueba de carga local .
Fig. 9. Elegir un tipo de pruebaEste artículo requiere alguna aclaración, porque usted pregunta con razón: "¿Y qué en el local?" El tema del artículo trata sobre las pruebas con Teams Services y MS Azure, pero hay un matiz, ya que utilizamos fuentes de datos en forma de tablas u otros servicios externos para las pruebas, esto puede causar algunas dificultades cuando intentamos ejecutar esta prueba en la nube.
Después de intentos inútiles de hacer que tales pruebas funcionen en la nube, abandonamos esta empresa y decidimos usar las llamadas pruebas "grabadas" para las pruebas, que se obtienen al registrar las solicitudes generadas por las pruebas que se ejecutan localmente y conectadas a las fuentes de datos.
Para grabar pruebas, utilizamos Fiddler, que tiene la capacidad de exportar solicitudes al formato de
Pruebas web de Visual Studio . Un poco más adelante describiremos con más detalle el procedimiento para registrar dicha prueba.
En los siguientes pasos, seleccionamos la duración de la prueba, el número de usuarios y, lo más importante, indicamos en qué pruebas consistirá nuestro
MixedLoadTest y en qué proporciones se utilizarán.
Fig.10. Componentes de pruebaComo resultado, después de todas las acciones, obtenemos un
MixedLoadTest combinado configurado para ejecutarse en una aplicación implementada localmente.
A continuación, debemos ejecutar esta prueba e intentar registrar con
Fiddler todas las solicitudes que se generarán como resultado de la prueba, así como obtener un "registro" que podamos ejecutar directamente en la nube.
Primero ejecute
Fiddler y nuestra prueba
MixedLoadTest .
Fig. 11. El resultado de la prueba.Después de procesar todos los datos, obtenemos esta imagen en Fiddler
Fig. 12. Sesión de prueba en FiddlerA continuación, en Fiddler, guarde todas las sesiones en el formato de
Pruebas web de
Visual Studio ,
Archivo -> Exportar sesiones -> Todas las sesiones -> Pruebas web de Visual Studio y agregue el archivo resultante al proyecto. Permítame recordarle que esta acción es necesaria para que podamos obtener la prueba sin referencia a fuentes de datos externas, ya que comenzar este tipo de pruebas puede causar problemas en la nube.
Fig. 13. Detalles de la prueba "grabada"Ahora casi todo está listo para ejecutar nuestra prueba en la nube, el último paso para preparar la prueba es abrir el
MixedLoadTest "grabado" en cualquier editor de texto y reemplazar
localhost : 8888 (dirección proxy, Fiddler) con la dirección de nuestra tienda en la nube.
Ejecutando una prueba en la nube
Para ejecutar las pruebas en la nube, necesitamos una cuenta válida en
Visual Studio Team Services .
Cree un nuevo LoadTest, solo que esta vez seleccione
Prueba de carga basada en la nube con Visual Studio Team Services .
En los próximos pasos, seleccionamos el centro de datos desde el que se generará el tráfico al recurso probado, así como el número máximo de agentes (usuarios) para el patrón constante, o si queremos usar un aumento gradual de la carga, necesitamos establecer los parámetros apropiados.
En el paso de seleccionar pruebas, seleccionamos la única prueba que grabamos anteriormente usando
Fiddler , emulará la carga "real" en el recurso probado.
Una vez completada la creación, lanzamos una prueba, durante la cual el estudio mostrará algunas métricas clave, como el rendimiento y el ancho de banda, así como también construirá gráficos en tiempo real.
Fig. 14. El proceso de ejecutar la prueba en la nubeUna vez completada la prueba, también puede ver el informe web guardado en VSTS:
Fig. 15. Informe web sobre el portal de Visual Studio Team ServicesAnálisis de resultados
El punto más importante es el procesamiento y análisis de los resultados de la prueba. Para la tarea en cuestión, fue necesario evaluar el rendimiento de una aplicación que se ejecuta en varias configuraciones de las tarifas de Azure Web Apps B2 y B3.
Para hacer esto, volvimos a ejecutar la prueba "grabada" para la aplicación en diferentes configuraciones y registramos los resultados en un documento de Excel.
Como resultado, obtuvimos este informe:
Figura 16. Informe de resultados de la pruebaDespués de analizar los datos obtenidos, fue posible descubrir la carga máxima que nuestra aplicación puede soportar: son aproximadamente 60 usuarios simultáneos o 9 solicitudes / segundo. con un tiempo promedio de retorno de página de 2.5 segundos. El gráfico muestra que los problemas de rendimiento comienzan abruptamente después de un cierto valor umbral para el número de solicitudes.
Como resultó más tarde, la razón de esto fue una carga del procesador del 100%, debido al hecho de que utilizamos una biblioteca de terceros para el procesamiento de páginas del servidor, que utiliza expresiones regulares para tokenizar y analizar el marcado.
Conclusiones
La productividad de una aplicación en desarrollo activo siempre tiene una fuerte tendencia a la degradación, porque cualquier cambio, incluso el más insignificante desde el punto de vista del desarrollador, puede tener consecuencias dramáticas para el rendimiento de la aplicación. En este sentido, las pruebas de rendimiento periódicas son un procedimiento importante que debe llevarse a cabo regularmente y ser parte de los procesos de Integración Continua.
El proyecto en sí y los informes recibidos como resultado de las pruebas están disponibles en GitHub .