Una de las cosas más difíciles de hacer es definir de antemano, son los criterios aceptables para el rendimiento de un sistema, módulo, webservice o aplicación software. Esto suele ser así porque generalmente quienes definen los requerimientos de sistemas, tienen una visión parcial muy acotada de los elementos intervinientes para el desarrollo de los productos.
Quizás haya que verlo desde varios puntos de vista, tal vez haciendo primar la visión del usuario al cual nuestros sistemas están dirigidos, pero siempre teniendo en cuenta los otros ángulos posibles, como el de los desarrolladores, arquitectos y dueños (responsables) de productos, entre otros. Aún así será una cuestión bastante engorrosa determinar cuando algo está bien o mal para obtener resultados empíricos.
Por qué el Performance Testing es cada vez más relevante?
Cada vez más empresas se están centrando en la realización de las pruebas de rendimiento del software, ya que tiene una influencia directa en los ingresos del negocio, la credibilidad de la organización y la satisfacción del cliente.
Por otro lado los altos costos de reparación de los defectos asociados a falta de performance en producción, obligan a pensar en mejores estrategias de desarrollo de los productos, donde obviamente las pruebas tempranas asociadas a la performance pasan a ser una cuestión crítica.
Cómo es un proceso típico de Performance Testing?
En primer lugar se evalúan los 'requerimientos del negocio', junto con una revisión de las características (features) del sistema a probar y su arquitectura. Así se llega, por ejemplo, a una definición de inicial de alto nivel de los elementos a configurar para los entornos de pruebas. A esta parte del proceso la podemos llamar "Colectar".
Luego como parte de la definición de un plan y la estrategia a seguir, se identifican la métricas de rendimiento, se establece una línea base, se definen las herramientas, tiempos de respuestas aceptables y tipos de pruebas de performance. Todo esto por lo general se plasma en un plan, así que a esta parte del proceso la podríamos llamar "planificar y estratificar".
Inicialmente podríamos hacer una aproximación con pruebas iniciales para establecer la "línea base", es decir conocer cómo son los tiempos de respuesta y rendimiento de nuestras aplicaciones en base a unos parámetros que establecimos como iniciales y mínimos. A esto le llamamos "baseline testing".
Posteriormente hay que hacer algunas definiciones críticas como el tipo de datos a utilizar, la configuración del entorno de pruebas y algo de diseño relacionado a los 'Test Scenarios' para las transacciones críticas. A esta parte del proceso la podríamos denominar "Definir y Diseñar".
Ya en fase de ejecución y con toda la información obtenida de nuestras primeras pruebas para establecer línea base, podremos escalar en alguno de los parámetros que ya sabemos son sensibles, de modo que se nos facilite aumentar la "carga" hasta un punto de "sobrecarga" (sin llegar a un punto de quiebre) del sistema, mientras analizamos el comportamiento general. A esto le llamamos "load testing".
Una vez que encontramos un punto de quiebre en el sistema, modificamos parámetros para tratar de lograr que nuestras aplicaciones "manejen el stress", pero con el objetivo de saber cual es el límite máximo aceptable (considerar eso como una situación extrema en el comportamiento y que el sistema se debe recuperar, o permanecer estable en el mejor de los casos). A esto le llamamos "stress testing".
Finalmente, cuando ya decidimos que valores son aceptables en nuestras métricas de rendimiento bajo distintos escenarios, ejecutamos una serie de casos durante periodos largos de tiempo, orientados a analizar la estabilidad de las aplicaciones. A esto le llamamos "longevity testing".
Un testing muy similar al de longevidad, tiene que ver con mantener nuestro ratio estable en un punto que consideremos óptimo, mientras por su lado vamos incrementando la complejidad y tamaño de los requerimientos a los sistemas. A esto le llamamos "scalability testing".
Habrá observado en este punto, que para llevar adelante todas estas pruebas ya habremos pasado varias veces por lo que llamaremos "Ejecutar y Evaluar", y claro, mientras vamos haciendo los ajustes volveremos muchas veces a repetir esta parte del proceso del performance testing.
Entonces ya tenemos en claro que hay varios tipos de testing-de-performance, ahora tenemos que comprender que todos apuntan a lo mismo, facilitarnos el análisis del comportamiento y rendimiento de nuestros sistemas y de la/s plataforma/s de soporte (disco, memoria, red/conectividad, otros).
| Application / Software Performance Metrics | System / Resource Performance Monitors |
| Percentage Error | Percentage CPU Utilization |
| Average Transaction Response Time (sec) | Percentage Network Bandwidth Utilization |
| Concurrency | Average Wait Queue Size |
| Hits / sec | Connection Pools |
| Page Views /sec | Disk Transfers I/O |
| Ramp Up Rate | Free Memory (Mbytes) |
| Throughput (Bytes / sec) | Page I/O |
| Transactions /sec | Processes
|
Desde el punto de vista de "la teoría del performance testing", hay solo unas cuantas métricas a monitorear, como el 'response-time' (típicamente en milisegundos), que no es más ni menos que el tiempo que demora una aplicación o interfaz en responder a un único requerimiento, considerando la cantidad de hilos de ejecución que están dedicados a atender el requerimiento, y algo un poco más complejo como el 'throughput', que puede tener varias lecturas típicas como:
. la cantidad de operations realizadas por segundo (TPS)
. la cantidad de bytes transferidos por segundo (BPS)
A ésto hay que acompañarlo con otras lecturas como:
. cantidad mínima de operaciones por segundo (o fracción de tiempo)
. cantidad máxima de operaciones por segundo (o fracción de tiempo)
. cantidad de paquetes perdidos por operaciones
. cantidad de operaciones fallidas por periodo de tiempo
. ratio (pass/fail) de acuerdo a assertions que hubiéramos podido declarar en el test plan
Desde el punto de vista técnico, conviene también observar más allá de los resultados obtenidos en la herramienta que hayamos usado para 'performance testing', y podríamos por ejemplo, "husmear" en nuestras plataformas de soporte, tales como los Web Servers o Database Servers, donde seguramente encontraremos que podemos modificar parámetros para mejorar el rendimiento de las aplicaciones. Podemos también "husmear" los paquetes entregados y recibidos, entre otras cosas que podemos hacer.
Y para que nos ha servido todo esto?
Para asegurar que futuras mejoras o mejoras realizadas anteriormente, no impacten negativamente el rendimiento de las aplicaciones y sistemas y en base a los resultados empíricos, se podrán hacer recomendaciones facilitando la toma de decisiones, ayudando orientar el desarrollo del software para optimizar el código acorde a los objetivos.
Pero tengamos en cuenta que principalmente se trata de una cuestión más bien relacionada con la credibilidad de las organizaciones frente a su público objetivo.
