1. Atenea. El Campus Digital de la UPC

1
(No Transcript)
2
(No Transcript)
3
1. Atenea. El Campus Digital de la UPC

• Introducción
• Planificación del proyecto
• Datos de uso de la plataforma
• Arquitectura funcional

4
1. Atenea. El Campus Digital de la UPC.
1.1 Introducción

• Objetivo
• Mejora de los procesos docentes
• Características
• Servicio a más de 30.000 estudiantes
• Se usa para ofrecer asignaturas no-presenciales,
  semipresenciales y
• como complemento a la enseñanza presencial
  (depósito de contenidos)
• Sistema integrado con el resto de procesos de la
  UPC Gestión
• académica, Bibliotecas, Servicios
  informáticos, etc,
• La solución tecnológica
• Software libre Basado en Moodle (
  http//www.moodle.org )
• Plataforma LAPP LinuxApachePostGreSQLPHP
• Modular Arquitectura sólida y segura
• Escalable

5
1. Atenea. El Campus Digital de la UPC.
1.2 Planificación del proyecto
Recojida especificaciones y prospección
Preparación del piloto
Piloto Atenea 4.0 i 4.1
Explotación Atenea 4.2 i 4.3
set
set
Feb
Sept
Sept
Feb
Sept
6
1. Atenea. El Campus Digital de la UPC.
1.3 Datos de uso de la plataforma
Set. 2007
7
1. Atenea. El Campus Digital de la UPC.
Media de logins y usuarios diferentes diarios
Datos 2007
8
1. Atenea. El Campus Digital de la UPC.
1.4 Arquitectura funcional
9
2. Diseño tecnológico de la plataforma

• Introducción
• Arquitectura hardware
• Herramientas
• JMeter
• Pruebas realizadas
• Cuellos de botella y mejoras introducidas
• Conclusiones sobre el diseño final

10
2. Diseño tecnológico de la plataforma
2.1 Objetivos

• Verificar la validez de la plataforma Moodle UPC
  ( Atenea ) para un colectivo de 30.000 usuarios
• Disponer de una herramienta que permita
  planificar adecuadamente evoluciones futuras

11
2. Diseño tecnológico de la plataforma
2.2 Infraestructura hardware y software (I)
12
2. Diseño tecnológico de la plataforma
2.2 Infraestructura hardware y software (II)
13
2. Diseño tecnológico de la plataforma
2.3 Requerimientos a las herramientas

• Podemos verificar de una manera realista el
  comportamiento de la plataforma ?
• Cumple los requisitos funcionales ? ( 30.000
  usuarios, picos de concurrencia, carga en
• régimen estacionario,etc, )
• Podemos identificar los posibles cuellos de
  botella y diseñar planes de contingencia
• asociados ?
• Dispondremos realmente de un escenario de
  pruebas configurable y repetible ?
• Además la plataforma será válida si
• Calidad percibida por el usuario garantiza
• Tiempo de respuesta web lt 10s
• Peticiones http erróneas lt 1
• Somos capaces de identificar perfiles concretos
  de usuarios ( comportamientos de navegación y uso
  del sistema )

14
2. Diseño tecnológico de la plataforma
2.4 Apache JMeter (http//jakarta.apache.org/jmete
r/index.html )

• Modelado de la carga
• Análisis de los logs de Apache
• Definición de usuarios modelo
• Autenticación y gestión de cookies por cada
  usuario
• Permite verificar nuestros parámetros de calidad
  
• ( tiempo de acceso web y de errores )
• Granja de PCs para realizar las pruebas
• ( en nuestro caso 15 PCs de nuestras oficinas )
• y es Software Libre !

15
2. Diseño tecnológico de la plataforma
2.5 Pruebas realizadas (I)

• Modelado de las pruebas
• Tiempo medio de sesión 7,25 minutos
• 50,26 Hits por usuario
• 90 de perfil Alumno y 10 de perfil Profesor
• Para cada usuario modelo se acotan URLs a
  visitar , tiempo de sesión, tiempo entre
  peticiones http.
• Procedimiento
• Pruebas iniciales en sistemas de pre-producción
• Detección prematura de cuellos de botella
• Implementación de mejoras específicas que nos
  permiten avanzar hacia pruebas cada vez
• más complejas y estresantes para el sistema

16
2. Diseño tecnológico de la plataforma
2.5 Pruebas realizadas (II)

• Prueba 1
• 600 hits/seg 15 mins. (aprox 2.100.000
  hits/hora)
• Clientes 12 PCs con Jmeter
• Aprox. 1200 usuarios concurrentes
• Prueba 2
• 800 hits/seg 15 mins. (aprox 2.900.000
  hits/hora)
• Clientes 18 Pcs con Jmeter
• Aprox. 1500 usuarios concurrentes

17
2. Diseño tecnológico de la plataforma
2.6 Cuellos de botella y mejoras introducidas

• RAM CPU en Front-ends
• Servidores apache independientes para contenidos
  estáticos y dinámicos TinyApache
• Acelerador PHP
• Número de conexiones concurrentes a la BD
• Configuración postgres
• Parámetros kernel linux
• Time-out de los balanceadores
• Variación del método de comprobación ( keep alive
  load )
• CPU del back-end del servidor de Bases de Datos
• Optimización de consultas, índices SQL,etc,

18
2. Diseño tecnológico de la plataforma
2.7 Conclusiones

• Atenea funciona y ofrece un buen servicio !!
• Definición de los perfiles de usuario ? Factor
  Clave de Éxito
• JMeter es una herramienta con una curva de
  aprendizaje razonable ? Y Modificable !!
• Es imprescindible que tras cada cambio en el
  entorno de producción se vuelvan a realizar
• pruebas ? Un inocente cambio de versión puede
  tener impacto en el rendimiento de la
• plataforma !!
• Moodle es una plataforma consolidada y que
  evoluciona. Dispone ya de una buena masa crítica
  de desarrolladores ( algunos ya en la UPC ? ).
• PostGreSQL es un SGBD robusto y que nos está
  ofreciendo un excelente
• rendimiento.
• JMeter es ahora nuestra herramienta de
  referencia a la hora de realizar pruebas de
• estrés sobre servicios Inet.

19
3. Líneas de trabajo futuras

• Aumentar el nivel de escalabilidad horizontal
  del backend servidor de BDs
• ( PostGreSQL 9? , Oracle ? MySQL ? )
• Seguir muy de cerca la evolución de Moodle y
  servir como referencia a la
• comunidad de un entorno real y con altos
  requerimientos.
• Estudiar la viabilidad de integrar Moodle con
  otras plataformas de almacenamiento
• ( DSpace? ), con el objetivo de aprovechar lo
  mejor de ambos mundos.
• Plataforma Moodle distribuida y federada ?

20
Muchas gracias por su atención
! andres.navarro-soto_at_upcnet.es
UPCnet Universidad Politécnica de
Cataluña