resultados linea interpretar informe funcionalidad ejecutar comandos testing jmeter load-testing

linea - jmeter load testing



¿Cómo analizar el resultado de JMeter? (5)

Soy nuevo en la herramienta JMeter. ¿Alguien me puede ayudar con la mejor manera de analizar los informes de JMeter?

A partir de la versión 3.0, JMeter incluye un informe HTML dinámico que se puede generar al final de una prueba de carga o desde un archivo de resultados.

Ver generación-tablero

Además de todas las otras respuestas: hay un buen sitio de BlazeMeter donde puede cargar su archivo de resultados de prueba (.jtl) y generará todo tipo de informes (interactivos) para él. Incluso lo analiza por usted y señala cuándo se produce el primer error, cuál es el punto de saturación, etc. https://sense.blazemeter.com/gui/

Si tiene una infraestructura de grafito / grafana, puedo recomendar agregar el programa de escucha de back-end al proyecto. Le enviará métricas en tiempo real al servidor de grafito y podrá monitorear la prueba en grafito (o grafana).

En palabras simples, si quiere analizar su informe de JMeter ...

  1. Comience con la utilización del CPU y la memoria RAM del servidor. Cuando ejecuta una prueba de rendimiento en su servidor, vea la cantidad de CPU y RAM utilizada por la prueba actual.
    Emita el siguiente comando en el servidor del sitio alojado; creará un archivo de registro del uso de la CPU.

    while true; do ( echo "%CPU %MEM ARGS $(date)" && ps -e -o pcpu,pmem,args --sort=pcpu | cut -d" " -f1-5 | tail ) >> ps.log sleep 1 done

  2. Ver el tiempo de respuesta global, no debe exceder el criterio de tiempo de respuesta esperado. Ver la imagen de abajo. Mi expectativa es que el tiempo de respuesta no supere los 525 microsegundos, pero algunas solicitudes lo están cruzando. Encuentra este tipo de solicitudes que llevan tiempo.

    Tiempos de respuesta global:

  3. Consulte Transacción por segundo, ¿cuántas transacciones se realizan por segundo y hay alguna caída en el marco de tiempo de la prueba?

  4. Inspeccione el informe de resumen, el tiempo promedio y el tiempo máximo para ver qué solicitudes toman más tiempo. Actualmente, muchos oyentes están disponibles en JMeter como complementos o integradas, pero estas son las principales cosas que se deben tener en cuenta para poder adivinar correctamente lo que está sucediendo. Y puedes usar otros informes como ese.

Sigue mi blog para más detalles https://softwaretesterfriend.blogspot.in/

Hay 3 pruebas que son obligatorias cuando se realizan pruebas de rendimiento, siempre debe haber una línea de base, una prueba de pico y una prueba de estrés. Estas pruebas se relacionan entre sí debido a la ley de los pequeños. El número medio de clientes a largo plazo en un sistema estable L es igual a la tasa de llegada efectiva promedio a largo plazo, λ, multiplicada por el tiempo que un cliente pasa en el sistema, W; o expresado algebraicamente: L = λW. .

Jmeter ya proporciona medios para verificar estos valores, el plugin estándar proporciona tramas para tiempos de respuesta, visitas y rendimiento. No hay forma de decir directamente cuántos usuarios estaban activos en el sistema, no son los mismos usuarios concurrentes que los usuarios activos. Los complementos son suficientes para producir los informes, pero no permiten controlar gran parte de la presentación, usaré algunos gráficos producidos con Python (agregan etiquetas y tienen 2 ejes y).

Prueba de línea de base: este caso es un caso especial de la ley, en este caso los usuarios activos son constantes y es uno, entonces:

  • L = λW
  • 1 = λW
  • 1 / W = λ

Si la aplicación ejecuta el mismo código, el tiempo de respuesta se estabilizará con el tiempo, y la tasa de llegada también será constante a lo largo del tiempo.

Hay un servicio que no hace más que esperar un tiempo para ir:

Servicio de 2 segundos: la tasa de llegada fue 1 / 2TPS.

Servicio de 3 segundos: la tasa de llegada fue de 1 / 3TPS.

Prueba máxima: este no es otro caso especial, en este caso, la carga aumenta hasta que supera la salida del sistema, ya que la carga es mayor que el rendimiento, los tiempos de respuesta aumentan. Durante la prueba, el número de subprocesos debe aumentar lo suficientemente rápido como para recuperarse de los tiempos de respuesta largos.

Esta vez, en lugar de correr el pico, presionaré al sistema con más carga de la que puede manejar durante toda la prueba. Para controlar el rendimiento del servicio:

Las transacciones activas son aquellas que han salido del inyector pero no han obtenido una respuesta, son transacciones que están en cola en algún lugar dentro del sistema.

  • λ (t) = c, T (t) = k; tanto la carga como la producción son constantes a lo largo del tiempo.
  • L = Σλ - ΣT = ct - kt; Las transacciones activas es la diferencia entre la carga acumulada y la producción acumulativa.
  • L = (c - k) t
  • λW = (c - k) t
  • CW (t) = (c - k) t
  • W (t) = t (c - k) / c

Debido a que los tiempos de respuesta crecen como lo hacen los usuarios activos, necesitaremos que el inyector cree nuevos subprocesos tan rápido como se requieran nuevas conexiones, la mayoría de los subprocesos de grupo estarán ocupados.

Velocidad de llegada de 2TPS, 1 rendimiento de TPS:

  • La función de tiempos de respuesta es 1 / 2t
  • El inyector tensiona el sistema durante 300 segundos.
  • La prueba duró 600 segundos.

Tasa de llegada de 4TPS, 1 TPS de rendimiento:

  • La función de tiempos de respuesta es 3/4 t
  • El inyector tensiona el sistema durante 300 segundos.
  • La prueba dura 1200 segundos.

Tasa de llegada de 6TPS, 5 TPS de rendimiento:

  • La función de tiempos de respuesta es 1 / 6t
  • El inyector tensiona el sistema durante 300 segundos.
  • La prueba dura 360 segundos.

Simplemente lista de enlaces relacionados que posiblemente pueda encontrar útiles:

Gráficos nativos:

Soluciones de código abierto gratuitas para gráficos automatizados:

Recetas con desarrollo personalizado:

Soluciones de terceros: