Análisis de los resultados de las pruebas de estrés

Cada día en el mundo existen cada vez más herramientas para realizar pruebas de estrés. De hecho, el interés por este tema está comenzando a crecer.

La tarea principal de una herramienta de prueba de carga es aplicar una carga determinada al sistema. Pero además de esto, hay una tarea más, no menos importante: proporcionar un informe sobre los resultados de enviar esta carga. De lo contrario, realizaremos pruebas, pero no podremos decir nada sobre su resultado y no podremos determinar con precisión desde qué momento comenzó la degradación del sistema.



Las herramientas de prueba más populares en este momento son Gatling, MF LoadRunner, Apache JMeter. Todos ellos tienen la capacidad de generar informes listos para usar sobre las pruebas realizadas, así como gráficos individuales o datos sin procesar, a partir de los cuales se construye el informe en sí.







Antes de redactar cualquier informe, debe comprender para quién lo estamos redactando y qué propósito perseguimos. No tiene sentido agregar muchos gráficos del tiempo de respuesta de la aplicación al informe para cada operación si su objetivo es determinar si hay pérdidas de memoria, si se corrigió una operación inestable durante una prueba de confiabilidad o si necesita comparar dos versiones entre sí como parte de las pruebas de regresión. Para responder a estas preguntas, solo necesita un par de gráficos, a menos que, por supuesto, haya solucionado los problemas y no quiera comprenderlos. Por lo tanto, antes de crear un informe, piense si realmente necesita agregarle todos los gráficos o solo los más indicativos y dé una respuesta al propósito de la prueba. Además, el conjunto de gráficos y su análisis para el informe dependen del modelo de carga seleccionado: cerrado o abierto,ya que los diferentes modelos darán diferentes cifras en los gráficos.



En Tinkoff usamos activamente la herramienta Gatling, por lo tanto, usando su ejemplo, le diremos cómo crear un informe de sus sueños y dónde buscarlo al analizarlo. También quiero señalar de inmediato que casi todos los gráficos descritos en el artículo se pueden obtener en línea utilizando un paquete de su herramienta con Grafana. Esta es la herramienta más conveniente para crear informes sobre la marcha, utilizando un panel preconfigurado. Además, le permite crear más rápidamente casi cualquier gráfico basado en los datos que envía. Ya existen paneles de control listos para usar para casi todas las herramientas de prueba de carga. También se darán gráficos para otras herramientas, MF LoadRunner y Apache JMeter, su análisis se construye por analogía con Gatling.

Métricas básicas

Indicadores

Muestra la distribución cuantitativa y porcentual del tiempo de respuesta de la solicitud por grupo. Los gráficos de este tipo son convenientes de usar para proporcionar una evaluación preliminar rápida de los resultados de la prueba sin un análisis más profundo de otros gráficos.



Los umbrales de grupo a grupo están predefinidos en función de la revisión por pares o SLA (requisitos no funcionales). Por ejemplo, puede haber tres grupos:

• excelente - tiempo de respuesta inferior a 50 segundos;
• medio: más de 50, pero menos de 100 segundos;
• terrible - más de 100 segundos.

En Gatling, usted mismo puede configurar los umbrales para pasar de un grupo a otro y su número en el archivo gatling.conf. Es mejor construir gráficos de este tipo basados ​​en la metodología. APDEX (índice de rendimiento de la aplicación)

También puede agregar un indicador con el número / porcentaje de solicitudes fallidas.







El método APDEX le permite utilizar indicadores en las pruebas de regresión para comparar lanzamientos: de esta manera puede ver inmediatamente cuánto peor o mejor se ha vuelto el lanzamiento en general. Desafortunadamente, este gráfico no está listo para usar en MF LoadRunner y Apache JMeter, pero es fácil crearlo usando el panel de Grafana.

Tabla de tiempos de respuesta

De forma predeterminada, Gatling crea una tabla basada en percentiles, tiempos de respuesta promedio y máximo y errores. Realiza un seguimiento más allá del SLA (exceso de requisitos no funcionales). Normalmente, los SLA indican los percentiles 95, 99 y el porcentaje de errores. Por lo tanto, la tabla le permite obtener una evaluación rápida de los resultados de la prueba.



Si agrupa las consultas como transacciones, puede ver en la tabla tanto la puntuación de las consultas individuales como la puntuación de todo el grupo y la transacción a la vez.

Gráfico de usuarios virtuales

Generalmente se mide en piezas y muestra cómo los usuarios ingresan a la aplicación, ilustrando así el perfil de carga real. Cabe señalar de inmediato que para MF LoadRunner y Gatling estos gráficos muestran el número de usuarios virtuales, y para Apache JMeter, el número de subprocesos.



El gráfico se utiliza para controlar la corrección de la aplicación de carga. Es necesario que su escenario de diseño corresponda a lo que envió al sistema en la realidad. Por ejemplo, si ve grandes desviaciones hacia arriba del escenario planificado en el gráfico, significa que algo salió mal: un error en el cálculo, se lanzaron más copias de la herramienta de carga de las necesarias, etc. Quizás no tenga sentido analizar más gráficos, ya que solicitó 100 usuarios más de lo planeado y el sistema fue diseñado originalmente para solo 10 usuarios.

Este gráfico se divide en dos tipos:

• Usuarios activos muestra cuántos subprocesos están activos actualmente por segundo. Cuando los hilos comienzan y se detienen, especialmente en un modelo de carga abierta, esta tasa fluctuará a lo largo de la prueba.
• Total VUsers muestra cuántos subprocesos se iniciaron y se detuvieron desde el comienzo de la prueba en total. Conveniente para un modelo de carga cerrada donde los hilos no mueren.

El tipo de gráfico también depende del modelo de carga:

• Modelo cerrado: los usuarios deben iniciar sesión en el sistema de acuerdo con el perfil de carga planificado. Si el gráfico muestra caídas o picos, esto indica que la carga no fue de acuerdo con el escenario calculado o planificado y requiere más estudio.
• — , . , . , , / . , — .

Response Time

La mayoría de las veces se mide en milisegundos: muestra el tiempo de respuesta a las solicitudes de la aplicación. El tiempo de respuesta no debe exceder el SLA. Este gráfico es la herramienta principal para encontrar puntos de degradación durante las pruebas de carga.



Si los picos son visibles en el gráfico, significa que en ese momento la aplicación no respondió por alguna razón; este puede ser un punto de partida para futuras investigaciones. El tiempo de respuesta debe ser uniforme, sin picos para todas las operaciones a lo largo del paso de carga, y también correlacionarse con el arrastre de carga. Gatling no incluye un gráfico de tiempo de respuesta "neto" (promedio, no agregado), a diferencia de otras herramientas.



Además de la gráfica del tiempo de respuesta de cada solicitud, también es conveniente mostrar una línea con el tiempo total de respuesta (Total Response Time). Al superponer el gráfico de carga aplicada (VU / RPS), puede realizar un seguimiento de la correlación con el aumento del tiempo de respuesta al aumentar la carga aplicada (VU / RPS). Apache JMeter llama a este gráfico Tiempos de respuesta frente a subprocesos.



A continuación, habrá gráficos, en los que puede haber muchas líneas, cada una de las cuales muestra su propio escenario o solicitud. Si tiene una prueba compleja con muchas operaciones y un perfil no lineal, le recomendamos que solo muestre las consultas o grupos de consultas más representativos en el informe. Alternativamente, solo puede reflejar las solicitudes que superen el SLA / SLO, para no saturar la programación y el informe.

Variaciones gráficas

Es posible una modificación en la que se aplican los percentiles de tiempo de respuesta y se agrega una línea del tiempo de respuesta promedio para todas las solicitudes. Usar percentiles aquí será más correcto, ya que el tiempo de respuesta promedio es muy sensible a valores atípicos marcados.



En las pruebas de rendimiento, los percentiles 95 y 99 se utilizan con mayor frecuencia para mayor claridad. Sin embargo, si observa el tiempo de respuesta promedio, debe considerar la desviación estándar (raíz cuadrada media).

Distribución del tiempo de respuesta

También hay excelentes gráficos que muestran la dependencia de la distribución del tiempo en el número de solicitudes.



Este tipo de gráficos es algo similar a los indicadores, pero muestra una imagen más completa de la distribución del tiempo, sin recortes por percentiles u otros agregados. Con el gráfico, puede definir con mayor claridad los límites de los grupos de indicadores. MF LoadRunner no tiene ese horario.

Latency

A partir de esta métrica, también se puede distinguir un parámetro adicional de latencia (milisegundos): el tiempo de latencia (la mayoría de las veces esto se entiende como latencia de red). Este parámetro muestra el tiempo entre el final del envío de la solicitud hasta que se recibe el primer paquete de respuesta del sistema.

Con este parámetro, también puede medir la latencia a nivel de red si el parámetro crece. Es deseable que tienda a cero. Este y el siguiente tipo de gráficos se utilizan principalmente para un análisis profundo y para encontrar problemas de rendimiento. Este gráfico no está listo para usar en Gatling. En MF LoadRunner, este gráfico se denomina Gráfico de latencia promedio en el bloque Gráficos de virtualización de red si ha instalado agentes de supervisión.

Banda ancha

De forma similar a la métrica anterior, puede seleccionar el parámetro Ancho de banda (kilobits por segundo): el ancho de banda del canal. Muestra la cantidad máxima de datos que se pueden transferir por unidad de tiempo.



Al cambiar este parámetro en la herramienta de carga, puede simular diferentes fuentes de conexiones a la aplicación: red 4G móvil o cableada. La versión gratuita de Gatling no tiene este gráfico, solo está disponible en la versión de pago de Gatling FrontLine. Este gráfico está listo para usar solo en MF LoadRunner, está ubicado en el mismo bloque que Latency y se llama Gráfico de utilización de ancho de banda promedio.

Solicitud por segundo gráfico

Medido en piezas por segundo: muestra la cantidad de solicitudes que ingresan al sistema en 1 segundo.



El gráfico muestra cuántas solicitudes puede manejar su sistema bajo carga, y también es el gráfico principal para crear el informe. También rastrea el ir más allá del SLA, ya que con un aumento de la carga al pasar el punto de degradación o los extremos locales, se puede observar una falla y luego un fuerte aumento. La mayoría de las veces esto se debe al hecho de que cuando la aplicación comienza a degradarse, las solicitudes también comienzan a acumularse en la entrada de la aplicación (aparece una cola), luego la aplicación les da algún tipo de respuesta o las solicitudes caen por tiempo de espera, lo que provoca un fuerte aumento en el gráfico - porque la respuesta fue recibida.

1. VU, RPS/TPS , .
2. Response Time, , .

TPS

Se mide en piezas por segundo y muestra el número de transacciones (puede haber muchas solicitudes dentro de una transacción) en 1 segundo.



Por ejemplo, la transacción "ingresar a su cuenta personal" incluye las siguientes solicitudes: abrir la página principal, ingresar un nombre de usuario, contraseña, presionar el botón "enviar", redireccionar a la página de bienvenida - por unidad de tiempo. En Gatling, un gráfico solo se puede obtener usando Grafana, ya que para grupos en un informe HTML, los gráficos se construyen solo por tiempo de respuesta.

Tabla de errores

Por lo general, se mide en tasa (piezas por segundo): el gráfico muestra el aumento en el número de solicitudes erróneas. También es conveniente medir el valor como porcentaje del número total de solicitudes. Este gráfico rastrea los SLA fuera de límites por el número o porcentaje de errores.



Si superpone el gráfico de Tiempo de respuesta, puede ver cómo un aumento en los errores afecta un aumento en el tiempo de respuesta de la aplicación.



Gatling por defecto no tiene un gráfico separado que muestre solo errores. En Gatling, se combina con el gráfico VU e inmediatamente muestra cómo un aumento de carga afecta a un aumento en el número de errores, y ayuda a detectar el umbral a partir del cual se excede el SLA o aparecen errores. Apache JMeter tampoco tiene un horario separado, se combina con los gráficos del número de transacciones.

Estado de las respuestas HTTP

También es posible trazar la distribución del número de errores por códigos de respuesta de la aplicación en un gráfico; es conveniente utilizarlo para clasificar errores.



Por ejemplo, si obtuvo 100% en el gráfico anterior, comienza a analizar qué errores 50x se deben a que el servidor no responde, o errores 403 debido al grupo incorrecto y los usuarios no pueden iniciar sesión, si, por ejemplo, está utilizando el protocolo HTTP.

Inicialmente, la versión gratuita de Gatling no tiene este gráfico, solo está disponible en la versión de pago de Gatling FrontLine. Para que el gráfico aparezca en la versión gratuita, debe reconfigurar el archivo logback.xml para que los registros se recopilen en el registro gris y ya estén en él para generar el gráfico deseado.

Gráfico de rendimiento

Por lo general, se mide en bits por segundo. El gráfico muestra el rendimiento de la aplicación, es decir, la cantidad de datos que envió y procesó la aplicación por unidad de tiempo.

Por lo general, se usa para un análisis profundo de un problema de aplicación. Gatling solo contiene este gráfico en FrontLine, no está en la versión gratuita.

Posibles modificaciones

1. Response Time, , (Throughput). Response Time, Throughput , : - .
2. Bandwidth, , .
3. VU, , , . .

La mayoría de los gráficos se pueden obtener utilizando los informes de Gatling basados ​​en HTML después de la prueba o configurando el paquete de monitoreo Graphite-InfluxDB-Grafana . Para la visualización, puede utilizar un panel de control listo para usar de la biblioteca de paneles de control https://grafana.com/grafana/dashboards/9935 .



Al analizar y compilar sus cuadros de mando para Gatling, debe tener en cuenta que los resultados en InfluxDB se almacenan de forma agregada y son adecuados solo para la evaluación preliminar de los resultados de NT. Se recomienda que después de la prueba, vuelva a cargar el archivo simulation.log en la base de datos, elabore un informe final sobre él y busque problemas de rendimiento del sistema.

Descripción de la matriz de métricas

Todo lo que describimos anteriormente se presenta en forma de una pequeña tableta que resume todo este conocimiento.