QUE ES PERFORMANCE TESTING?


Para empezar bien este blog es justo y necesario arrancar definiendo que son en si las pruebas de performance.

El mundo ha estado confundido con este tema por tanto tiempo diciendo performance cuando en realidad quieren carga. O peor aun pensando que una prueba de carga es todo lo que hay en el mundo de performance. Incluso lo peor de lo peor, mucha gente que va por el mundo usando la palabra de las pruebas de performance en vano, usándola para referirse a otras cosas como optimización de performance, administración del performance, configuración y muchas otras cosas que son parte de el arte de las pruebas de performance, pero que no son la definición en si.

Así es que ahora vamos a definir bien bien, que son las pruebas de performance.

DEFINICIÓN


La definición de "pruebas de performance" tiene muchas variaciones. No he encontrado una que letra por letra sea universalmente aceptada. Agregado a esto se vuelve mas difícil por que la definición se confunde mucho con otras practicas que rodean a las "pruebas de performance". Algunas están relacionadas o son similares, pero no son LA DEFINICIÓN. Pues hay otras cosas relacionadas con performance como planeación de capacidad, afinación, proyección y muchas mas cosas que acaban en performance.

Aquí, yo les voy a dar una definición que a mi en lo personal me hace sentido. Está basada en la definición que aparece oficialmente en Wikipedia. Pero la voy a re frasear en un modo que ayudara a facilitar el entendimiento de este post.

Entonces, aquí les va:

Pruebas de performance:
Una practica o actividad que consiste en la validación y verificación de la velocidad de respuesta de un sistema computacional  
,********
midiendo a su vez el impacto y reacción de los componentes físicos del sistema 
,
******** 
mientras se le da un uso especifico.
-Yo Mero

Es importante notar que la oración esta sospechosamente dividida a propósito por comas y asteriscos. Esto es para hacer mas evidente las 3 partes que (según yo) siempre componen a una prueba de performance. Sin importar donde, cuando o como, Una prueba de performance siempre va a consistir de esas 3 piezas. Hablemos ahora de cada una de ellas.

VELOCIDAD


Es una de las primeras cosas que la gente piensa al escuchar performance. Que tan rápido voy a recibir respuestas, cuanto tiempo va a tomar o que tanto estamos dispuestos a esperar?
Uno pensaría que el componente importante aquí es la distancia, pues la velocidad es la cantidad de distancia recorrida por unidad de tiempo. Pero en sistemas la distancia es mas bien una medida fija. Algo así como un corredor de los 100 metros. Entonces, que medimos si siempre son 100 metros?




TIEMPO! Medida clave para la velocidad de un sistema. Cuanto tiempo le toma completar un proceso. Generalmente es medido en segundos o mili-segundos.
Medir el tiempo de un sistema informático se puede hacer de muchos modos y con muchos dispositivos.

Ejemplos: contar el tiempo que toma un proceso único en un sistema local, o el tiempo que le toma a la información completar un viaje redondo hasta la base de datos y de regreso, o el tiempo que tomó cada paso en ese viaje, o incluso todas las anteriores y mucho mas.
Para medir ese tiempo existen múltiples y vastas soluciones. Desde contar segundos con los dedos o un vil cronometro de mano cuando un ser humano puede fácilmente medir el tiempo y no desperdiciar recursos cuando fácilmente se puede decir que algo esta lento. También hay mediciones internas de tiempo que el sistema mismo puede, o debería darnos.

Las automatizaciones también nos pueden medir el tiempo de respuesta, pero no debe usarse como única opción pues en ocasiones no pueden dar ese tiempo de respuesta como en el caso de llamadas asíncronas.

Al final también contamos con medios mas avanzados como agentes, sondas, herramientas de análisis externo como APMs, etc.

Para medir tiempos de respuesta no existe un método universal. El mecanismo correcto debe ser elegido dependiendo de la necesidad dada en su momento.

MÉTRICAS









El segundo componente de una prueba de performance son los elementos físicos que pueden ser medidos. La mayoría de tiempo esas mediciones se relacionan a el hardware a cargo de la solución. Estos elementos de hardware son medidos por lo que conocemos como monitores.


El tipo de métricas que se puede obtener del hardware son variadas tambien. Es como medir las funciones corporales durante una prueba física. Se pueden medir muchas cosas, y lo que se mida va a depender mucho de la parte de el cuerpo donde se este monitoerando.

En términos de hardware, el lugar mas común para obtener métricas son los servidores principales de la solución. Algunas de las métricas mas comúnmente obtenidas de ellos son CPU, RAM, demanda en la interfaz de red, procesos en ejecución y muchos mas. La lista de posibilidades puede ser enorme y uno debe elegir las mas relevantes a la aplicación.

Pero esos no son los únicos lugares donde uno puede obtener información o métricas. Uno debe revisar todo componente que pudiera recibir impacto o demanda al estar usando la aplicación. Interfaces de conexión, balanceadores de carga, interfaces en la nube, contenedores, almacenes de servidores, etc.










Del mismo modo, el tipo de métricas que cada uno de esos dispositivos va a arrojar serán muy diferentes y variadas. Pueden incluso ser mediciones de temperatura, si estamos revisando el calentamiento de un CPU, que el cuarto de servidores esté fresco o incluso si esta caliente el platillo que Alexa esta preparando en el microondas de Amazon.

El punto es poder observar y registrar como las métricas brincan y reaccionan a una acción que hagamos. Casi como el brinco de nuestra rodilla después de que el doctor le da el pequeño golpe. Donde revisamos que tan alto sube nuestra pierna o cuanto tarda en brincar después del golpe del doctor.

De el mismo modo debemos estar atentos a la reacción de los usos. Y hablando de...

USO


El ultimo componente de una prueba de performance es un "uso especifico". Un tipo e uso que se puede simular es carga, pero quiero aclarar que no todas las pruebas de performance son pruebas de carga.






Los tipos de uso o escenarios que se pueden cubrir en una prueba de performance son muchos y se refieren a situaciones especificas donde nos preocupa alguna circunstancia, evento o situación. Con una sola prueba de performance no se pueden cubrir todas las circunstancias. Uno debe ser especifico y enfocarse en en un patrón de uso especifico a probarse uno a la vez.

Situaciones donde hay muchos usuarios ejecutando múltiples acciones son solicitadas frecuentemente. Se les conoce como pruebas de carga, durabilidad, estrés y muchos otros nombres definidos por sus características. Todas pruebas que comúnmente requieren la automatización de los procesos pues generar tanta carga manualmente resultaría casi imposible. Este es el único uso para las herramientas de prueba de carga, por favor no las usen solo para obtener tiempos de respuesta.

Los eventos que podemos necesitar simular en una prueba de performance no siempre son pruebas de carga, las cuales se enfocan en generar carga de manera sintética. El tipo de usos que podemos probar puede ser muy variado, desde carga orgánica generada por usuarios reales, ejecución automática de procesos como jobs programados o rutinas disparadas por eventos. Hasta incluso el impacto de un único usuario que uno mismo puede fácilmente simular de manera manual.





Muchos otros tipos de eventos requieren solo una prueba de performance. NO TODOS REQUIEREN PRUEBAS DE CARGA ni usa aplicaciones diseñadas para pruebas de carga. Tenemos que asegurarnos de estar probando o simulando el evento correcto de acuerdo con el factor de riesgo que queremos mitigar con nuestra prueba de performance. Es decir la situación en la que queremos revisar como se desempeña nuestro sistema. Específicamente, en las situaciones que nos da miedo que nuestro sistema no sobreviva.

FINAL


En una oración que son las pruebas de performance. (NO ES PRUEBAS DE CARGA)

Las pruebas de carga se refieren a cualquier acción de medir los TIEMPOS de respuesta y MONITOREAR los componentes de una solución de TI durante un EVENTO en particular.

Cualquier otra definición podría estarse refiriendo a una sub-familia de las pruebas de performance o incluso podría ser completamente otra área de acciones relacionadas con el performance (como afinación, optimizan, predicción, etc.)

Ahora ya sabemos!
Besos <3










-Señor Performo

Comentarios