© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. 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. 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. 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 cliente- servidor. – 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 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: 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. Í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. MNCS: Investigación, desarrollo y gestión de la calidad.

Presentaciones similares

Presentación del tema: "© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. MNCS: Investigación, desarrollo y gestión de la calidad."— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. MNCS: Investigación, desarrollo y gestión de la calidad.

Presentaciones similares

Presentación del tema: "© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. MNCS: Investigación, desarrollo y gestión de la calidad."— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback