Problemas más comunes en las pruebas de carga

Problemas más comunes en pruebas de carga

El artículo que incluimos a continuación pretende ser un muestrario de las dificultades comunes que se presentan en el día a día del técnico de pruebas. Un auténtico experto, adquiere la experiencia a la hora de resolverlos con métodos que van desde la investigación exhaustiva , el método “prueba y error” y suficiente suerte como para saltar la banca de un casino…

Pasemos a una breve descripción del artículo.

1. Definición de objetivos.
2. Modelado de comportamiento del usuario
3. Generación de la carga
4. Monitorización estado
5. Análisis de resultados

Definición de objetivos

Habitualmente cuando, se pretende realizar una prueba de carga, los objetivos a alcanzar son difíciles de detallar. Salvo que los peticionarios tengan experiencia previa en este tipo de pruebas, siempre hay que realizar una pequeña presentación o “bienvenida” a este mundillo.

Sólo hay una excepción a esta regla y son las pruebas a lanzar cuando se presenta un problema en la explotación. En ese caso, se tienen claros los objetivos:

• Reproducir el fallo
• Detectar sus causas
• Una vez pasado por Desarrollo, comprobar que se corrige dicho fallo

El solicitante habitual debe comprender que las pruebas de carga consiguen dar una idea del rendimiento de la aplicación en concurrencia, detectan posibles problemas debido al consumo de los recursos, los posibles cuellos de botella.

El modelado de las navegaciones

Es preciso determinar cúales son las actividades de los usuarios o procesos propios de la aplicación que causan los problemas. En una aplicación en explotación siempre se puede recurrir a los log de actividad de la misma (los de acceso web, uso de la BBDD, monitorización de seguridad) y, una vez tratados, determinar cúales son los posibles “caminos críticos” que generan el fallo –en el caso de ser ese el propósito de las pruebas- o determinar el rendimiento de la aplicación (ya sea real, para comparar con nuevas versiones o extrapolar para los posibles crecimientos de actividad)

Generación de la carga

Una vez definidos los ciclos de prueba, hay que saber cómo incrementar la carga para alcanzar el objetivo determinado.

Aunque, habitualmente las pruebas estresantes son las más comunes, hay pruebas que pueden ser más ajustadas a la realidad. Algunos ejemplos son estos

• Pruebas con escalonamientos de carga mínimos. Este tipo de pruebas sirven para confirmar problemas de serialización de peticiones. Es decir, podemos detectar que se está produciendo una situación en la que un recurso usado por el sistema es usado sin paralelización, bien sea por configuración del servidor (tamaño de la cola de petición , RqThrottle, número de conexiones activas simultáneas de JRun…), bien por código -clases obsoletas de Java, estructuras de control poco eficientes –

• Pruebas de aislamiento. En estas pruebas, se selecciona una llamada específica que se produce durante la navegación del usuario, pero que es la que puede causar más problemas. De esta manera, en entornos más reducidos que el de Explotación, se puede conseguir reproducir una situación de estrés de recursos que pueden ser “apantallados” por la poca capacidad de las capas de presentación (por ejemplo, un problema en BBDD que no se pueda reproducir debido a que el frontend web agota recursos de manera que no llega a generar el nivel de carga necesario para que se presente)

• Pruebas de estabilidad. Consisten en mantener la carga durante largos periodos de tiempo, de manera que la degradación del uso se manifieste en la aparición de los problemas. Aunque actualmente, con los reinicios programados de los servidores estas pruebas tienen más sentido como medida preventiva.

• Pruebas de impacto. Simulan el uso concurrente masivo de una aplicación en un breve periodo de tiempo. Por ejemplo, el inicio de la jornada laboral en unas oficinas donde utilicen una herramienta corporativa común, como una intranet, o las consultas de determinados periodos (nóminas, facturas del mes, declaraciones de Hacienda, reservas de viajes…).

• Pruebas de tolerancia a fallos. Se busca verificar tanto la capacidad de mantener el servicio de la aplicación, como detectar los cuellos de botella de la infraestructura. Este sería el caso de aplicaciones con entornos de alta disponibilidad ,que incluyan balanceado de aplicaciones, servidores de contingencia, duplicidad de centros de proceso de datos…

Monitorización de estado

La arquitectura usada por la aplicación o definida para el entorno determinará los elementos a monitorizar e incluso las herramientas para ello.

Podemos diferenciar entre monitorizaciones intrusivas y no intrusivas, si usamos una aplicación específica como Introscope , Diagnostics, JTrace …que incluyen clases que ejecutan rutinas de temporalización –o instrumentalizadas- que se incluyen en el arranque de los servidores. Su ejecución afecta y puede que decisivamente, al rendimiento de las aplicaciones, al compartir directamente recursos con ellas

Las monitorizaciones no intrusivas, utilizan comandos del sistema operativo o análisis a posteriori de logs de sistema, de manera que los comandos no utilicen directamente los mismos recursos que las aplicaciones.

También hay elementos de la arquitectura que requieren monitorizaciones que no suelen estar al alcance de los conocimientos de los técnicos de pruebas. Por ejemplo, los entornos que tienen parte de sus elementos basados en plataformas tipo OS/Z o Legacy, requieren de personal muy especializado para analizar y comprender la información que estos sistemas generan

Otro caso específico es el de la infraestructura de comunicaciones. Esta puede ser bastante compleja y requerir de un conocimiento profundo de la misma y de los conceptos que maneja (encaminamiento, pérdidas de paquetes, TTL, número de colisiones…etc)

Análisis de resultados

Aquí se establece la verdadera parte “artesanal” del proceso de pruebas de carga. Al poder considerarlo como un proceso que se retroalimenta, los análisis pueden mostrar a veces lo que nos hemos marcado como objetivo de las pruebas.

En esta parte además, la experiencia previa con aplicaciones con elementos comunes, ya sea de arquitectura o por los productos utilizados por la misma nos puede servir de guía…o de distracción.

Aunque es cierto que se reproducen de manera contínua errores bien sea en el manejo de los productos (configuración, desconocimiento de particularidades de codificación, inexperiencia.) o en el planteamiento de la aplicación (uso indebido de variables, estructuras de control inadecuadas, adecuación incorrecta al flujo de negocio…), no debemos guiarnos por prejuicios, aunque tengan su base.

El proceso de análisis debe ser objetivo y basado en la observación crítica de los resultados, solicitando ayuda para solventar las lagunas en el conocimiento de las monitorizaciones o comportamientos de los sistemas o servidores que nos haga falta.