Pruebas de estrés. (Introducción)

1. Hablando de pruebas de estrés
2. Divergencias entre aplicaciones
3. Esbozo de herramientas a utilizar

Hablando de pruebas de estrés.


Este tipo de pruebas han sido menospreciadas por muchas empresas, sin embargo, constituyen una importante barrera ante la mala calidad de las aplicaciones web, base de datos e incluso LDAPs.

Lo importante de las pruebas de estrés web es conocer los desperfectos de una aplicación, no directamente a nivel de código ni de diseño, sino la forma en que utiliza los recursos del sistema operativo y el software en general que se relaciona con el aplicativo, después de eso es factible revisar todas aquellas condiciones que pudieran mejorar el desempeño de la aplicación. Los límites dependen de los tiempos de entrega, así como la afectación que la aplicación presente y demás trámites que se tienen que hacer para tocar una aplicación.

Existen dos términos semejantes, los cuales no considero que sean muy distintos, es más, en la práctica es difícil separarlos. Las pruebas de estrés y las pruebas de volumen; mientras que las primeras miden la capacidad de la aplicación para estabilizarse ante condiciones extremas (concurrencia de usuarios muy alta), la segunda mide la capacidad de respuesta durante esas condiciones extremas. Es decir, no se pueden hacer pruebas por separado y de forma aislada, conviven en la misma prueba.

Divergencias entre aplicaciones.


Una vez definidas las pruebas de estrés, hago hincapié en que un punto fundamental es saber lo que vamos a probar, es decir, no podemos tratar con las mismas exigencias servicios web, que una aplicación de alta transaccionalidad. Otro factor importante es saber las relaciones que la aplicación o servicio establece, ya que de ello puede depender criterios a tomar, como la tolerancia ante los tiempos o uso de procesador, ya que tiene que dividirse entre más elementos.

Aquellos tópicos que observo son las conexiones a base de datos que se establecen, y aquellas que están en fase de cierre (ver estados de conexiones TCP), con objeto de conocer si dicha aplicación deja conexiones abiertas, impactando directamente en disponibilidad de conexiones futuras y rendimiento del sistema operativo. El comportamiento del sistema operativo en general, es decir, la cantidad de memoria y procesador que utiliza la aplicación, pudiendo llegar a ser más fino el análisis, por ejemplo, los fallos de página que pudieran estar sucediendo o los cambios de contextos que hay, inclusive el intercambio de memoria. Por último, el comportamiento del proceso de la máquina virtual de Java, para determinar el uso de memoria  que utiliza la aplicación y su generación de objetos; todo esto para garantizar el correcto funcionamiento de la aplicación ante situaciones extremas y a largo plazo.

Por razones de conocimiento sólo puedo mencionar dos herramientas que estoy por entero relacionado, sin embargo, hay muchas más opciones. Ambas son de ámbitos comerciales totalmente distintos, por un lado la que representa el software libre y por el otro la que representa el software privativo: JMeter y Pureload, respectivamente.

Existen herramientas de monitoreo para obtener las métricas de las pruebas de estrés, sin embargo, por gusto personal, utilizo las herramientas nativas del sistema operativo o del software utilizado, aunque de vez en cuando echamos mano de herramientas de terceros para obtener métricas más finas y profundas.

También me gustaría hablarles de los tipos de aplicaciones que pueden hallarse, en mi caso son las siguientes:

• De alta transaccionalidad
• De transaccionalidades largas
• De procesamiento (conversión de archivos, generación de reportes, etcétera)

Cada una tiene una forma de operar y cargas distintas de trabajo,  por ello debemos exigir comportamientos distintos y no medirlos bajo una misma regla inflexible, eso solo atraería decisiones fuera de lugar.



Esbozo de herramientas a utiliza.

Existe una infinidad de herramientas que cumplen con el cometido, yo puedo comentar al respecto de dos que he utilizado ampliamente y las cuales me han dejado satisfecho. Cabe mencionar que las utilizo como complemento, es decir, lo que no logro hacer con una lo hago con la segunda. Las herramientas son Pureload (código cerrado) y el conspicuo JMeter (código abierto). Ambas herramientas tienen pros y contras, sin embargo, estoy desarrollando un documento donde las pongo a prueba en el mismo escenario. Aún está en fase alpha, pero en cuanto tenga algo más lo comento en el hilo de escritos de este blog.