Pruebas de rendimiento como instrumento para medir eficiencia
Antes de ahondar en los beneficios poco conocidos de las pruebas de rendimiento, debemos comenzar aclarando ciertos puntos sobre el alcance de estas pruebas. Lo primero es que están enfocadas a soluciones transaccionales, que mediante la ejecución de una cantidad “suficiente” de solicitudes, permite analizar hacia donde converge su comportamiento (tasa de error, tiempos de respuesta, carga soportada, entre otros). Es muy común confundir el marco de trabajo de las pruebas de rendimiento con las actividades de optimización de procesamientos por lote, en donde de igual modo se miden tiempos de respuesta, pero están enfocadas en la identificación de cuellos de botella, uso excesivo de recursos y otras actividades que merecen su propio artículo, el cual abordaremos en otra oportunidad.
Pruebas de Rendimiento
Las pruebas de rendimiento, también conocidas como “pruebas de carga” o simplemente “pruebas de estrés”, tienen como objetivo medir como se comportaría una funcionalidad cuando se encuentre disponible a los clientes, sin embargo, al ser bien enfocadas y ejecutadas son capaces de entregar información valiosa dando indicios de problemas y/o errores difíciles de identificar en las pruebas de certificación.
Las pruebas de rendimiento (performance) pueden ser catalogadas en 6 distintos “sabores” en base a lo que se desea validar y la estrategia de las pruebas, las cuales son:
- Pruebas de Carga.
- Pruebas de Escalabilidad.
- Pruebas de Volumetría.
- Pruebas de Peak.
- Pruebas de Estrés.
- Pruebas de Resistencia.
Aunque no es una regla aplicable al 100% de los casos, podemos simplificar los beneficios de las pruebas de performance, en dos grupos bien marcados, la primera enfocada en validar la solución y la segunda enfocada en validar la arquitectura dispuesta para la solución.
Acá es donde nos encontramos con nuestra primera bifurcación ¿Qué pruebas realizar y por qué?, por lo que contar con un buen ingeniero especializado en pruebas de performance, marca la diferencia, acá les presento un resumen simplificado del impacto de cada una de las pruebas de rendimiento.
- Las pruebas de carga miden el estado base del servicio, sin una carga que sobre exija el servidor ni el transporte de datos.
- Las pruebas de escalabilidad miden la evolución en el rendimiento en base a distintos niveles de carga.
- Las pruebas de volumetría miden variaciones en tiempo de respuesta y transporte en base a la volumetría de datos de respuesta y/o volumetría utilizada para resolver una solicitud.
- Las pruebas de peak miden el comportamiento del servidor para abordar una sobrecarga de solicitudes y los tiempos de recuperación.
- Las pruebas de estrés miden la carga máxima del servidor antes de presentar “fisuras” en la arquitectura (aumento de errores, sobrecargas de conexión, uso excesivo de recursos, etc.).
- Las pruebas de rendimiento sirven para medir cómo se comporta un servicio al estar operativo durante un periodo largo de tiempo, además de su interacción con otros servicios y/o procesos que comparten recursos.
Claramente todas entregan un punto de vista que complementa a la visión final del servicio certificado, pero los “recursos son limitados y las necesidades son infinitas” y aunque sería ideal poder realizar todas las pruebas, mucha información puede ser contraproducente y no hay que olvidar que estas pruebas requieren una cantidad importante de tiempo en planificación y ejecución (sin contar que cada prueba debe contar con un monitoreo en la infraestructura). Bajo lo mismo es importante poder definir una estrategia específica a cada una de las necesidades.
En Akzio contamos con una lista de preguntas para poder elegir la mejor estrategia, y destacamos algunas de las más importantes.
- ¿Cuál es la expectativa del usuario?
- ¿Cómo será el comportamiento del servicio cuando este operativo?
- ¿Qué tanto impacta el servicio en el negocio que se certifica?
- ¿Qué tantos “escenarios” existe en el servicio/flujo a certificar?
- ¿Qué tanta data maneja el servicio/flujo a certificar para resolver respuesta?
- Si el servicio a certificar es parte de un flujo mayor, ¿Cuál es el comportamiento de dicho flujo (tiempos y carga)?
- ¿El ambiente de certificación es equivalente al productivo en arquitectura/recursos?
Claramente no siempre se realizan todas las preguntas, ya que mientras algunas respuestas pueden levantar nuevas preguntas y otras tienden a cerrar una arista de evaluación. A modo de ejemplo un servicio con muchos escenarios puede fomentar la realización de pruebas de volumetría, además de levantar consultas más específicas sobre la distribución de dichos escenarios y eventualmente presentar acotaciones a las expectativas del usuario, mientras que un ambiente de certificación que no se asemeje al productivo (arquitectura y/o uso) puede cerrar inmediatamente la posibilidad de realizar pruebas de peak y/o rendimiento.
Una vez identificada la mejor estrategia y posterior a la ejecución de las pruebas de rendimiento, es importante contar con la visión del experto para poder interpretar correctamente los resultados, obteniendo mediante la lectura gráficos y datos puros “síntomas” de una posible “enfermedad” del sistema:
- Tiempos de respuesta base muy alto: Antes de comenzar a evaluar Las pruebas de carga deben comenzar con 1 usuario, con el fin de poder evaluar el tiempo de respuesta de la solución en un ambiente con recursos disponibles y sin estrés. Este valor corresponde al tiempo base del servicio, por lo que tiempos altos genera un riesgo importante en la validación bajo concurrencia que exijan la arquitectura.
- Variabilidad de tiempos de respuesta: Uno de los mayores errores es medir los tiempos de respuesta con su promedio, debido a las distorsiones que se generan cuando tenemos tiempos mínimos muy bajos o máximos demasiado alto, además que acá lo que necesitamos medir es el comportamiento que tendrán los usuarios. Para esto usamos los percentiles, estos valores lo dispone prácticamente todas las herramientas de performance, pero se pueden obtener manualmente ordenando los tiempos de respuesta de menor a mayor asignando un valor dentro de una escala de 0 a 100 de la siguiente forma:
Las primeras dos curvas nos indican que el servicio responde correctamente, tiempos bajos y constantes. Esto nos indica que estamos evaluando un servicio en donde los datos de entrada influyen poco en el resultado (servicios con respuestas genéricas, consultas a tablas unitarias y/o una correcta optimización del servicio). En el caso de encontrarnos una curva más caótica nos indica que el servicio se comporta de forma dispar en tiempos de respuesta, ya sea para distintos escenarios, falta de optimización y/o problemas en la arquitectura de la solución.
- Comportamiento de tiempos de respuesta bajo distintos usuarios concurrentes: Las pruebas de escalabilidad se encargan de medir el impacto que el uso por varios actores sobre el servicio y la arquitectura. Este impacto puede visualizarse desde un aumento en los tiempos de respuesta llegando a situaciones más extremas como existencia errores en los servicios. Los errores presentados sirven para validar que la arquitectura permita la concurrencia esperada (validación indirecta sobre Gateway y/o servidor de aplicaciones), que el pool de conexiones a Base de datos esté correctamente configurado y en algunos casos las pruebas de performance permiten identificar malas prácticas en la implementación del servicio (cerrado incorrecto de conexiones, limpieza incompleta de buffer e incluso errores por no limpieza de variables). Para esto es importante contar con la visualización de los logs de los servicios y la interpretación de los retornos ante las solicitudes.
- Comportamientos anómalos durante las pruebas de Resistencia: Para estas pruebas se requiere que exista un uso constante y prolongado de los servicios a validar (desde 5 horas hasta días), tiene como objetivo identificar problemas ocasionados por errores en la configuración (al igual que las pruebas de escalabilidad busca fugas de memoria, errores en la gestión de conexión a terceros, entre otros). Este tipo de prueba otorga un valor adicional en el caso de contar con un ambiente de certificación “vivo”, ya que validar los servicio cuando se comparten recursos puede entregar una visión mas real de cómo se comportará cuando esté operativo. Es común encontrar problemas cuando el api compite con procesos de volcado y conciliación de data, ya que es común ver aumentos en los tiempos de respuesta de los servicios cuando estos están utilizando los mismos insumos (DB).
Conclusión
Las pruebas de performance, que inicialmente tiene como objetivo cubrir las expectativas de uso enfocadas en la experiencia del usuario (tiempos de respuesta), cuando se realizan correctamente pueden entregar información complementaria que permite alertar de “ineficiencias” en la solución tal es el caso de cuellos de botella, caídas y sobrecargas. Todo esto permite asegurar la entrega de un producto óptimo, tanto a nivel funcional como técnico.
Fernando Morales Araneda
Jefe de Tecnología QA/Servicios