Promedio, desviación estándar y percentiles: métricas para testing de performance

Hay ciertas métricas para testing de performance que es fundamental entenderlas bien. Requieren cierto entendimiento básico de matemática, quizá estadística, pero nada muy complicado. El tema es que si no se entiende bien qué significa o qué representa cada una, se puede llegar a conclusiones muy erradas. En este post me quiero centrar en el promedio, desviación estándar y percentiles, sin entrar en mucha matemática sino en su utilidad para el momento de analizar resultados de performance.

 

Ejemplo de Scott Barber, importancia de las gráficas

La primera vez que razoné sobre el tema fue en un curso que nos dio Scott Barber en el 2008 (cuando recién comenzábamos con Abstracta), en su visita a Uruguay. Mostró una tabla con valores como esta:

De ahí nos preguntó ¿cuál creíamos que tenía mejor performance? lo cual no es fácil de mirar, como cuando uno mira las gráficas de cada prueba:

 

En el Set A, se observa que hubo un pico, pero luego recupera.

 

En el Set B, parece que comenzó con tiempos muy malos, y probablemente a los 20 segundos de prueba el sistema colapsó y comenzó a responder una página de error, la cual se resuelve en un segundo.

 

Por último, en el Set C, se observa claramente que a medida pasa el tiempo el sistema continúa degradándose.

 

Su foco en el ejercicio estaba en mostrar que es mucho más fácil analizar información cuando está en una gráfica. Además, en la tabla la información está sumarizada, en cambio en las gráficas están todos los puntos, o sea, muchos más datos, que nos pueden llevar a obtener otro tipo de información y análisis.

 

Entendiendo las métricas para testing de performance

Veamos qué significa cada una de las métricas para testing de performance, una por una, y la importancia en el análisis.

Promedio (o media)

Para calcular el promedio sumo todos los valores de las muestras y lo divido sobre la cantidad de muestras. Puedo decir entonces que el tiempo de respuesta promedio es de 3 segundos. El problema de esto es que da la falsa sensación de que todos los tiempos de respuesta están alrededor de los tres segundos, algunos un poco más y otros un poco menos, pero eso no es así. Imaginemos un ejemplo muy simple, donde tengo 3 muestras, las dos primeras con tiempo de respuesta de 1 segundo, la tercera con tiempo de respuesta de 7.

1+1+7=9

9/3=3

Este es un ejemplo muy simple y con pocas muestras, en el que se ve que tres valores muy diferentes pueden dar como promedio 3, y los valores no están cercanos al 3.

La analogía que me explicó Fabián hace unos días, muy bueno para explicar esto es, “pongo una mano en -200 Celsius, otra mano en lava ardiendo. En promedio estoy re bien de temperatura, pero en realidad estoy muriendo”. 

Eso puede pasar al analizar los tiempos de respuesta y el promedio da un resultado dentro de los niveles aceptables, cuidado con las conclusiones a las que llegamos…

Por eso los SLA’s siempre tienen un valor de porcentaje, tal como “El servicio debe responder en menos de 1 segundo para el 99% de los casos”. Esto lo vamos a ver luego con el percentil.

Esa idea de que los valores “están alrededor de tres segundos” que mencionaba antes, está determinada por la siguiente medida: la desviación estándar.

Desviación estándar

La desviación estándar es una medida de la dispersión con respecto al promedio, qué tanto varían los valores con respecto a su promedio, qué tan alejados o concentrados están. Si el valor de la desviación estándar es pequeño, esto indica que todos los valores de las muestras están cercanos al promedio, pero si es grande, entonces están alejados y se mueven en un margen mayor.

Para tener una idea de cómo interpretar este valor, veamos un par de ejemplos. Si todos los valores son iguales, la desviación estándar es 0. Si tengo valores muy dispersos, por ejemplo, consideremos 9 muestras con valores de 1 a 9 (1, 2, 3, 4, 5, 6, 7, 8, 9), la desviación estándar es de ~2,6 (pueden usar esta calculadora online).

Si bien el valor del promedio se puede mejorar mucho dando el valor de la desviación estándar, los que a mí me resultan mucho más importantes para analizar, son los valores de los percentiles.

Percentiles

El percentil es una medida muy útil, dando una medida bajo la cual se encuentra un porcentaje de la muestra. Por ejemplo, el percentil 90 (abreviado como p90) indica que el 90% de la muestra se encuentra por debajo de ese valor y el resto de los valores (o sea, el otro 10%) están por encima.

Es incluso recomendado analizar más de un valor de percentiles (como lo hace JMeter o Gatling en sus reportes de resultados), mostrando cuánto es el p90, p95 y p99. Si esto lo complementamos con el mínimo, máximo y promedio, ahí tendremos una visión muy completa de cómo se comportaron los datos.

Algunos percentiles tienen nombres particulares, como el p100 que es el máximo (el 100% de los datos están por debajo de este valor), y el p50 que es la mediana (la mitad de los datos están por debajo y la mitad por arriba).

Se suele usar el percentil para establecer criterios de aceptación, indicando que el 90% de la muestra debería estar por debajo de cierto valor. Esto se hace así para descartar los outliers (valores mentirosos).

 

Conclusión

Las conclusiones a las que llego son las siguientes:

  • Nunca considerar el promedio como una medida aislada, como “el” valor a observar, ya que “es un valor muy mentiroso”, puede ocultarnos información fácilmente.
  • Considerar la desviación estándar para darnos cuenta qué tan mentiroso es el promedio, a mayor desviación estándar más mentiroso es el promedio.
  • Observar los valores de los percentiles, y definir el criterio de aceptación en base a eso, teniendo en mente que si elijo el percentil 90 estoy diciendo que “no me importa que el 10% de mis usuarios tengan malos tiempos de respuesta”.

¿Qué otras conclusiones o cuidados consideras al momento de analizar métricas para testing de performance?

7 thoughts on “Promedio, desviación estándar y percentiles: métricas para testing de performance

  1. Gustavo Vázquez says:

    No descarten nunca el máximo como una medida. Si bien como dice Barber “user experience, not metrics”, hay veces que tenemos que cumplir con SLA y allí tenemos que ver lo que nos pide el SLA para decir cual es la métrica clave a utilizar.

    1. Federico says:

      Muy buen punto Gus!!!!
      Gracias por compartir 🙂

  2. Excelente post Federico!, es muy claro y conciso. Ahora estoy explorando en pruebas de performance y tus posts me estan ayudando mucho. Gracias

    1. Federico says:

      Cuánto me alegra José, a la orden!

  3. Facundo says:

    Excelente explicación, muchas gracias !!

  4. Flor Paucar says:

    Gracias por la publicación Sr Federico, estoy entrando al tema de pruebas no funcionales y su post me fue de gran ayuda

Leave a Reply

Your email address will not be published. Required fields are marked *