Transcript TestCarga
MNCS: Investigación, desarrollo y gestión de la calidad © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Índice • MNCS: Metodologías, Normalización y Calidad del Software. – Investigación y diseño. – Gestión de los desarrollos MEDEA • Test de carga – Componentes Hardware – Componentes Software • Elementos de testeo – Tipos de test de carga – Puntos críticos – Interpretando resultados • Diseñando un test de carga • Herramientas Software – JMeter – LoadUI • Ejercicios © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. MNCS: Investigación y diseño. • Estudio e investigación de componentes software: – Tecnologías de desarrollo. – Herramientas monitorización y control de software . – Herramientas de testeo de aplicaciones y depuración. • Punto de unión entre los desarrollos realizados y los servidores físicos que los soportan. • Diseño de estructuras software adaptadas a los requerimientos del hardware especificado por la sección de sistemas. – – – – Estructura de librerías. Diseño de actualizadores. Librerías específicas etc… © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. MNCS: Gestión de desarrolos. • Gestión del proceso de desarrollo de aplicaciones software. – Recogida de requisitos – Gestión de cambios – Control de calidad del software – Control de entornos de pruebas y test – Integración continua de aplicaciones. • MEDEA: Metodología diseñada para el control de todo el ciclo de desarrollo desde la toma de requisitos hasta la puesta en marcha en los servidores. © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. MNCS: MEDEA © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Índice • MNCS: Metodologías, Normalización y Calidad del Software. – Investigación y diseño. – Gestión de los desarrollos MEDEA • Test de carga – Componentes Hardware – Componentes Software • Elementos de testeo – Tipos de test de carga – Puntos críticos – Interpretando resultados • Diseñando un test de carga • Herramientas Software – JMeter – LoadUI • Ejercicios © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Test de carga • Ideados para testear el rendimiento de las aplicaciones en diferentes situaciones. • Obtiene medidas de: – Rendimiento general del sistema. – Respuesta ante picos de carga. – Respuesta ante una alta carga sostenida. • Componentes a testear: – Elementos Hardware: Servidores, balanceadores, cachés… – Elementos Software: Balanceadores, sistemas de caché, bases de datos, servidores… © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Test de carga • Su importancia es crítica a la hora de asegurar que los recursos disponibles son los adecuados. • El análisis de resultados nos permite: – Conocer exactamente los recursos que debemos asignar. – Detectar puntos críticos y cuellos de botella. – Comprobar robustez del sistema a nivel hardware/software. • A la hora de gestionar un sistema las aplicaciones deben tener los recursos que necesitan, ni más, ni menos. • Los test de carga permiten simular con detalle las cargas estimadas para asignar los recursos adecuadamente. © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Componentes Hardware • Los componentes Hardware involucrados en un sistema distribuido son: – Servidores: Principalmente de aplicaciones y web, aunque existen otros tipos según el ámbito en el que trabajemos. – Balanceadores: Están por encima de los servidores, principalmente son Software pero también los encontramos Hardware. – Base de datos: En un solo nodo o distribuida, se encuentra por debajo de los servidores. – Otros: Servidores Industriales (robótica), macro procesadores, etc… © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Componentes Hardware • Definición del sistema: • Cluster DB de 2 nodos. • Cluster WS de 3 nodos. • Balanceador Hardware de un nodo. © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Componentes Software • Los componentes Software que normalmente encontraremos son: – Servidores: Weblogic, GlassFish, Tomcat, Apache ... – Balanceadores: Zen LoadBalancer, Kemp, BalanceNG ... – Base de datos: Oracle, MySql, Postgres …. • Estos componentes están limitados por las características del Hardware que los engloba. • Es crítico gestionar la mejor configuración Hardware/Software para lo que necesitamos. © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Índice • MNCS: Metodologías, Normalización y Calidad del Software. – Investigación y diseño. – Gestión de los desarrollos MEDEA • Test de carga – Componentes Hardware – Componentes Software • Elementos de testeo – Tipos de test de carga – Puntos críticos – Interpretando resultados • Diseñando un test de carga • Herramientas Software – JMeter – LoadUI • Ejercicios © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Tipos de test de carga • Existen tres tipos principales de test de carga: – Test de carga (realista): Valora la reacción del sistema ante una carga promedio de accesos. Permite verificar que el sistema funciona correctamente durante largos periodos de tiempo. – Test de rendimiento: Empezando con una carga promedio y aumentando poco a poco hasta llegar al límite del sistema. Nos indica cómo responde el sistema ante el aumento de carga y dónde está su máximo. – Test de estrés (con picos): Lanza diversos test con diferentes cargas de manera intercalada para ver cómo se comporta el sistema con picos de carga y sobre su punto máximo. © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Puntos críticos • A la hora de montar un sistema debemos identificar claramente los puntos críticos y testearlos a conciencia para evitar errores en la ejecución de las aplicaciones. • Factores a tener en cuenta: – Concurrencia de aplicaciones. – Sincronización de los nodos. – Gestión de sesiones/estado de la comunicación clienteservidor. – Timeouts. © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Puntos críticos • Cada tipo de servidor tiene unas restricciones propias, por ejemplo: – Servidor Base de Datos: • Sincronización de datos. • Gestión de bloqueos. • Gestión de la recuperación de un nodo. (Actualización de los datos, activar el nodo). – Servidor Web/Aplicaciones: • Manejo de sesiones. (Mantenimiento y distribución de la sesión). • Gestión de diferentes aplicaciones de manera concurrente. © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Puntos críticos • El balanceador, en caso de tenerlo, es el único punto de acceso al sistema, por lo que su correcto funcionamiento es prioritario. • Puede existir un único balanceador, o encontrarse varios en paralelo. • Es importante, tener un sistema de balanceo de respaldo por si el sistema principal se cae evitar que el sistema quede inaccesible. • Un correcto algoritmo de balanceo asegura una optimización de los recursos. © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Interpretando resultados • Interpretar de manera adecuada los resultados es muy importante para establecer una configuración óptima del sistema. • En ocasiones resulta necesario repetir los test de manera individualizada sobre determinados componentes hardware para aumentar el nivel de detalle. • Existe un gran espectro de datos a tener en cuenta, pero los básicos son: – Errores detectados. – Tiempo de respuesta (Latencia). – Tiempo de recuperación. © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Interpretando resultados • Errores detectados – Nos indica todas las peticiones que no pudieron ser atendidas porque el sistema está sobrecargado. – Debemos identificar quien es el causante de la caída y el motivo. • No se responde a las peticiones (TimeOut) -> El balanceador o los servidores no responden. • Se responde con un mensaje de error -> Los servidores notifican por mal funcionamiento del sistema o de la base de datos. – Con una carga alta, puede considerarse “normal” que algunas peticiones fallen. – Ataque Denegación de Servicio (DoS): Miles o millones de equipos hacen solicitudes a un servidor, sobrecargándolo e impidiendo que responda, o lo haga con mucho retardo. © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Interpretando resultados • Tiempo de respuesta (Latencia). – El tiempo de respuesta nos indica cómo de sobrecargados están los servidores. – Es una medida que nos permite determinar si debemos ampliar el sistema o reconfigurarlo. – Es un factor a reducir lo máximo posible, cuanto menor sea este valor mejor será la configuración del sistema. – En momentos pico, la latencia subirá, el objetivo es contenerla dentro de un rango adecuado y baja en las zonas valle. © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Interpretando resultados • Tiempo de recuperación. – Es el tiempo que tarda el sistema en recuperarse de la caída de alguno de sus componentes. – Es muy importante que el sistema esté disponible el mayor tiempo posible. – Es conveniente tener servidores de respaldo, inactivos pero actualizados, que retomen el control cuando los principales caigan. – Debemos tener bien cubiertos los cuellos de botella. © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Índice • MNCS: Metodologías, Normalización y Calidad del Software. – Investigación y diseño. – Gestión de los desarrollos MEDEA • Test de carga – Componentes Hardware – Componentes Software • Elementos de testeo – Tipos de test de carga – Puntos críticos – Interpretando resultados • Diseñando un test de carga – Herramientas Software • JMeter • LoadUI • Ejercicios © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Diseñando un test de carga • A la hora de diseñar el test, debemos llegar a los límites del sistema, sin perder de vista el objetivo real, que es que con una carga normal funcione todo. • Los casos extremos son puntuales, por lo que prima que el sistema esté siempre activo antes que obtener un bajo tiempo de respuesta. • https://wiki.um.es/wikis/programador/doku.php?id=migralinux:mi gracion_bd_a_rac • Por lo tanto, proponemos la siguiente estructura de test: – – – – Localización de límites y ajuste del sistema. Test de carga en “límite -1”. Test de carga en con tráfico normal. Simulación de caídas de equipos para los test anteriores. © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Diseñando un test de carga • La simulación de caídas de equipos nos dará una medida más exacta de cómo puede responder el sistema ante cualquier problema. • Con una carga normal, si se mantiene la disponibilidad con tiempos razonables, la estructura global del sistema se puede dar como válida. • Manteniendo la disponibilidad, a mejor tiempo de respuesta, mejor estructura global del sistema. © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Herramientas Software • Es imposible simular el acceso concurrente de miles de equipos de manera simultánea. • Es necesario disponer de una herramienta que permita emular dichas conexiones. – JMeter: Herramienta Java que permite emular múltiples conexiones y procesos de navegación complejos. • http://jmeter.apache.org/ – LoadUI: Herramienta Java FX, que permite, en su versión gratuita, emular test de carga simples. • http://www.loadui.org/ © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Herramientas Software: JMeter • JMeter es una herramienta de software libre proporcionada por Apache para la generación de test de carga. • Esta desarrollado en Java al 100% lo que permite una fácil modificación y extensión. • Presenta una interfaz clara con multitud de elementos para medir el rendimiento del sistema. • Permite simular la navegación de un usuario a través de un flujo de datos. • Incorpora un servidor proxy para capturar las peticiones que queremos incluir posteriormente en el test. © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Herramientas Software: JMeter © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Herramientas Software: JMeter Controlador simple: Gestiona el test © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Herramientas Software: JMeter Sevidor proxy: Prepara el test © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Herramientas Software: JMeter Muestreadores: Obtiene los datos del test © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Herramientas Software: LoadUI • Preparación del test de carga: – – – – – – – – Creamos un grupo de hilos. Creamos un controlador. Creamos un servidor proxy en JMeter. Modificamos el navegador para que acceda a internet a través de nuestro servidor proxy. Ejecutamos las consultas. Paramos el servidor. Repasamos nuestro plan de pruebas eliminando consultas redundantes. Lanzamos nuestro test. © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Herramientas Software: LoadUI Generadores de flujo de llamadas © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Herramientas Software: LoadUI Módulos de ejecución © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Herramientas Software: LoadUI Procesadores de estadísticas © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Herramientas Software: LoadUI © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Índice • MNCS: Metodologías, Normalización y Calidad del Software. – Investigación y diseño. – Gestión de los desarrollos MEDEA • Test de carga – Componentes Hardware – Componentes Software • Elementos de testeo – Tipos de test de carga – Puntos críticos – Interpretando resultados • Diseñando un test de carga – Herramientas Software • JMeter • LoadUI • Ejercicios © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Ejercicios • Ejercicio JMeter: – Crear un test de carga para las url: • www.um.es • www.todofp.es • www.carm.es – Probar los diferentes tipos de receptores: • • • • Árbol de resultados. Response Time Graph. Resultados en árbol. Reporte resumen. – Comprobar las tasas de error y diferencia de respuesta en ambos test. © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Ejercicios © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Ejercicios • Ejercicio LoadUI: – Repetir el ejercicio anterior con LoadUI – Observar los resultados obtenidos © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Ejercicios © 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas.