Problemas más comunes en pruebas de carga El producto que incluimos a continuación pretende ser un muestrario de las problemas 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 brincar la banca de un casino... Pasemos a una breve descripción del artículo. Definición de objetivos. Modelado de comportamiento del usuario Generación de la carga Monitorización estado Análisis de frutos Definición de metas Habitualmente cuando, se pretende hacer una prueba de carga, los metas a conseguir son complicados de detallar. Salvo que los peticionarios tengan experiencia previa en este tipo de pruebas, siempre hay que hacer una pequeña presentación o ?bienvenida? a este mundillo. Sólo hay una excepción a esta norma y son las pruebas a arrojar cuando se muestra un asunto en la explotación. En ese caso, se tienen claros los objetivos: Reproducir el fallo Detectar sus motivos Una vez pasado por Desarrollo, verificar que se corrige dicho fallo El solicitante habitual debe entender que las pruebas de carga consiguen dar una idea del rendimiento de la aplicación en concurrencia, detectan probables dificultades debido al consumo de los recursos, los probables cuellos de botella. El modelado de las navegaciones Es preciso decidir 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 entrada web, uso de la BBDD, monitorización de seguridad) y, una vez tratados, decidir cúales son los probables ?caminos críticos? que generan el fallo ?en el caso de ser ese el objetivo de las pruebas- o decidir el rendimiento de la aplicación (ya sea real, para comparar con nuevas versiones o extrapolar para los probables crecimientos de actividad) Generación de la carga Una vez definidos los ciclos de prueba, hay que saber cómo incrementar la carga para conseguir el meta 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 dificultades de serialización de peticiones. Es decir, podemos detectar que se está produciendo una situación en la que un medio usado por el sistema es usado sin paralelización, bien sea por configuración del servidor (tamaño de la rabo de petición , RqThrottle, número de conexiones activas simultáneas de JRun...), bien por código -clases obsoletas de Java, estructuras de control escaso eficientes ? Pruebas de aislamiento. En estas pruebas, se selecciona una llamada específica que se produce mientras la navegación del usuario, pero que es la que puede causar más problemas. De esta manera, en ámbitos más reducidos que el de Explotación, se puede obtener 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 asunto en BBDD que no se pueda reproducir debido a que el frontend web agota recursos de forma que no llega a generar el nivel de carga indispensable para que se presente) Pruebas de estabilidad. Consisten en mantener la carga mientras largos periodos de tiempo, de forma que la degradación del uso se manifieste en la fantasma 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 origen de la jornada laboral en unas oficinas donde utilicen una dispositivo 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 comprobar 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 ámbitos de alta disponibilidad ,que incluyan balanceado de aplicaciones, servidores de contingencia, duplicidad de institutos de proceso de datos... Monitorización de estado La arquitectura usada por la aplicación o definida para el ámbito determinará los fundamentos a monitorizar e inclusive las dispositivos para ello. Podemos distinguir 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, emplean comandos del sistema operativo o análisis a posteriori de logs de sistema, de forma que los comandos no utilicen directamente los mismos recursos que las aplicaciones. También hay fundamentos de la arquitectura que necesitan monitorizaciones que no suelen estar al alcance de los conocimientos de los técnicos de pruebas. Por ejemplo, los ámbitos que tienen fracción de sus fundamentos basados en plataformas tipo OS/Z o Legacy, necesitan de personal muy especializado para considerar y entender la información que estos sistemas generan Otro caso particular es el de la infraestructura de comunicaciones. Esta puede ser bastante compleja y solicitar 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 frutos Aquí se constituye la verdadera fracción ?artesanal? del proceso de pruebas de carga. Al poder considerarlo como un proceso que se retroalimenta, los análisis pueden presentar a veces lo que nos hemos marcado como meta de las pruebas. En esta fracción además, la experiencia previa con aplicaciones con fundamentos comunes, ya sea de arquitectura o por los artículos utilizados por la misma nos puede servir de guía...o de distracción. Aunque es cierto que se reproducen de forma contínua yerros bien sea en el empleo de los artículos (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 meta y basado en la observación apreciación de los resultados, solicitando ayuda para solventar las lagunas en el conocimiento de las monitorizaciones o comportamientos de los sistemas o servi dores que nos haga falta.