Las pruebas de performance consisten básicamente en simular el uso intensivo por parte de varios usuarios un sistema determinado. De este modo es posible verificar el correcto o incorrecto funcionamiento del mismo cuando se encuentra estresado bajo una pesada carga transaccional.
Utilizando algunas herramientas, como JMeter o LoadRunner, se pueden desarrollar scripts para simular el comportamiento de usuarios reales interactuando con el sistema que se desea probar.
Luego estos scripts son ejecutados en uno o más hosts destinados a la tarea de generación de carga con el fin de generar la carga transaccional sobre un ambiente creado previamente para las pruebas de performance.
Los tests de performance son útiles para detectar diferentes tipos de problemas y prevenirlos antes de que el sistema se encuentre brindando servicio en el mundo real. De este modo se consiguen mitigar riesgos económicos y políticos que podrían ser provocados por dichos problemas.
Además proveerán métricas útiles que podrán ser usadas para mejorar el rendimiento y para elaborar un plan de escalabilidad, ya que en todo negocio se prevé que la demanda transaccional aumente en el futuro.
Problemas detectables.
Realizando este tipo de pruebas es posible detectar una amplia variedad de problemas que no podrían ser encontrados a través de las pruebas funcionales.
- Problemas inherentes a la concurrencia.
Los servicios que no han sido diseñados y programados correctamente fallan cuando son invocados más de una vez al mismo tiempo. Este es un error común que ningún test funcional podría detectar.
- Utilización subóptima del hardware.
Ocurre cuando el rendimiento del sistema alcanza su límite, pero aún queda hardware ocioso (CPU, disco, red, etc.) en el servidor.
Esto significa que el cuello de botella se podría encontrar en la lógica misma de la programación o en la configuración de los servidores.
- Hardware desbalanceado.
Ocurre cuando uno de los componentes del hardware alcanza su límite, como la memoria, el disco o el procesador, pero el resto está muy lejos de alcanzarlo.
Aunque no es crítico este problema, representa un desperdicio y es fácilmente detectado a través de las pruebas. - Degradación de la performance con el uso.
La performance de algunos servicios y consultas a la base de datos se vuelven más lentas a medida que se utiliza el sistema. Esto ocurre, por ejemplo, porque la base de datos comienza vacía y se va llenando de datos con el tiempo.
Sólo un test de carga de larga duración podría detectar este problema.
- Fuga de memoria u otros recursos.
Algunos errores comunes en programación consisten en no liberar, devolver o cerrar algunos recursos, como la memoria, los archivos, los sockets de red, o las conexiones a las bases de datos. Este tipo de errores producen la caída del sistema y la necesidad de reiniciar el servidor.
Realizando una prueba de carga de larga duración, es posible alcanzar el punto, si existe, en el que el sistema deja de funcionar. - Mala configuración del cluster.
La alta disponibilidad y cualquier plan de contingencia no funcionarán si el cluster no se encuentra correctamente configurado. La forma adecuada de probar esto es ejecutando una prueba de carga y simulando desconexiones de los distintos elementos del cluster durante la ejecución.
Por otro lado es importante verificar que el cluster escale adecuadamente, debido a que las demandas del negocio así lo requerirán en el futuro.
Métricas útiles.
Aún en el improbable caso de que el sistema funcione correctamente y ninguno de los problemas mencionados anteriormente se verifiquen, las pruebas de performance arrojan información importante para:
- Establecer una relación entre la carga transaccional del sistema y el hardware requerido. De este modo será posible prever los requerimientos de hardware del sistema.
- Entender qué transacciones vale la pena optimizar para generar una mejora significativa de la performance.
Consideración final.
El momento adecuado para estudiar y analizar estos asuntos relacionados a la performance del sistema, es antes de que el mismo se encuentre en producción.
El costo de no hacerlo dependerá de cada negocio. Hay que considerar el perjuicio económico ocasionado si el sistema deja de brindar servicio por un periodo indeterminado de tiempo. Muchos de los problemas que se encuentran en la lista son de compleja solución.