Alta disponibilidad Moodle

Muy buen vídeo sobre alta disponibilidad para la plataforma Moodle, aunque sea un poco antiguo (Moodlemoot 2009).

Todo el reconocimiento para Antonio Jesús Lozano y Felipe Retortillo.

Load Testing Moodle con Jmeter

Jmeter es una herramienta muy útil para hacer test de carga de distintas aplicaciones. Es tan flexible puede servir para poner a prueba tanto una aplicación web, como un servidor de base de datos o incluso un servicio tipo SOAP.

La potencia de Jmeter radica en la capacidad para simular la actividad de usuarios o las peticiones a un determinado servicio o aplicación, de forma concurrente. Estas pruebas nos pueden ayudar en el dimensionamiento del servidor, posibles fallos o problemas derivados de la concurrencia, etc.

Otra característica muy interesante de la herramienta es que puede "grabar" la actividad del navegador para después lanzar una determinada cantidad de usuarios o "hebras" que ejecuten esta misma actividad. Esto se realiza creando un proxy en jmeter al que debemos apuntar nuestro navegador. Jmeter se encargará de ir almacenando todas las peticiones que se realicen. Para encontrar más información podéis buscar "jmeter proxy record" o términos similares.

Obviamente cualquier prueba de carga nunca debería ser ejecutada en un servicio/servidor de producción.

Para ponerse al día con la herramienta lo mejor es pasar por su documentación y buscar algún ejemplo en concreto e ir modificándolo para adaptarlo a nuestras necesidades. Esto mismo es lo que he hecho yo, basándome en un plan de pruebas existente en los foros de moodle.org (todos los agradecimientos a su autor). A partir de este plan de pruebas he ido parametrizando algunos procedimientos y adaptando su funcionamiento a los cambios de Moodle v2.5.

Las tareas que he incluido en el plan son:

• Abrir la página principal de Moodle
• Login en Moodle
• Entrar en el curso
• Acciones del usuario en orden aleatorio:
• Actividad de texto
• Mensaje en el chat
• Mensaje en el foro y contestar a un mensaje en el foro
• Subir un fichero a archivos privados
• Enviar un fichero a una actividad (implica subir fichero)
• Salir de Moodle

Peticiones y respuestas

La forma de proceder para cada una de las tareas de nuestro test será la siguiente:

1. Realizar una petición al servidor web con una serie de parámetros
2. Recibir la respuesta del servidor y comprobar que se ha realizado con éxito
3. Capturar nuevos parámetros que nos serán útiles en peticiones posteriores
4. Realizar una pausa aleatoria antes de llevar a cabo la siguiente petición y así adaptar el test a los tiempos que emplearía un operador humano.

Pero... ¿Cómo sabemos si una petición ha sido correcta? Lo más indicado es seguir los pasos "manualmente" en el navegador y así ver (directamente en pantalla o abriendo el código fuente devuelto) cual es la respuesta de la plataforma a cada clic. De esta manera podemos ir identificando los textos que se presentarán después de cada petición y utilizarlos en Jmeter.

Bien, ya hemos considerado dos de los elementos más importantes en el diálogo que se establece entre nosotros (o nuestro navegador) y el servidor web: peticiones y respuestas. Pero hay un elemento que aún falta y que es imprescindible si queremos simular ese diálogo: las cookies!! 

Como ya sabéis prácticamente todas las aplicaciones web utilizan cookies. Moodle también necesita crear una cookie en el navegador del usuario para mantener la sesión. En Jmeter dispondremos de un objeto que hará de gestor de cookies de manera que "cada usuario virtual" pueda mantener una sesión con el servidor.

El plan

Variables globales

Definir las "variables globales" del experimento. Como por ejemplo el host al que accederemos y el path dentro de ese host que aloja la plataforma. Esto no es obligatorio, pero siempre está bien para poder cambiar la máquina o la ruta de forma fácil. Si no parametrizamos estos datos tendremos que modificar cada petición cuando queramos probar contra otra máquina o si ha habido cambios en la ruta.

Estas variables no varían durante toda la ejecución del plan, por lo que podemos definirlas a nivel de "Test Plan".

Si llamamos a las variables host y path, cada vez que hagamos una petición podremos utilizar la ruta ${host}${path}. Supongo que queda claro que para hacer referencia al valor de una variable debemos utilizar la forma ${variable}.
Además de estas variables también he definido una ruta para el almacenamiento de los resultados de los tests, donde utilizo la expresión ${__time(yyyyMMdd_HHmm)} que devuelve la fecha y hora en la que se realizó el test.

Grupo de hilos

El siguiente elemento a definir es nuestro grupo de hilos (cuantos hilos y cuantas veces queremos repetir cada hilo). Este elemento será el que contendrá el resto de objetos de nuestro plan. Dentro de este objeto definimos elementos para cada una de las hebras (usuarios) que lanzamos. Esto queda claro si nos detenemos en el elemento UserParameters que contiene una serie de variables que distintas para cada hebra. Por ejemplo, cada hebra accederá con un usuario/contraseña distintos, para ello se sortea  un número del 1 al 10 con la función __Random y se añade al prefijo de usuario y al prefijo de contraseña (UsernameHead y PasswordHead respectivamente). También se tienen los nombres de los objetos de Moodle a los que accederemos: jmeter course, jmeter text assignment, jmeter forum, etc. Estos objetos, así como los usuarios deben estar creados previamente en la instalación de Moodle sobre la que estamos trabajando.

Interacciones con la plataforma

Analizaremos sólo una de las peticiones/respuestas, por ejemplo, la de login. El resto de peticiones son muy similares. Como se ve en la imagen, definimos las variables de la petición en el espacio Parameters. Estos parámetros construyen usando las variables que hemos definido en el grupo de hilos. En la parte superior de la ventana se da el host y el path completo de la petición.

Y ahora podemos comprobar si es usuario se ha identificado correctamente en la plataforma buscando la cadena "you are logged in as", que aparece en cualquier página de Moodle una vez que el usuario se ha identificado. Para ello añadimos un elemento del tipo Response Assertion y la configuramos para que busque la cadena en la respuesta del servidor.

De la respuesta que nos da el servidor también debemos extraer más cosas. Moodle necesita en muchas de las llamadas un id de session sesskey y además nosotros necesitamos el id del curso al que queremos acceder para realizar la próxima llamada que será del tipo

${host}${path}/course/view.php?id=${courseid}

Para obtener el id del curso, por ejemplo, configuramos un elemento de tipo Xpath Extractor que revisará la respuesta del servidor y buscará el id del curso. La expresión que se ha usado es:

substring-after(//*/a[text()='${course_name}']/@href,'=')

Explicación breve:

La función substring-after busca un carácter dentro de una cadena y devuelve la subcadena que hay después de ese carácter.

Lo que hay dentro de la función es una expresión xpath. Estamos diciendo que busque un enlace (tag "a" de HTML) en cualquier parte del documento que tenga como texto el nombre del curso (recordad que lo tenemos definido en las variables) y devuelva el valor de su atributo href. Si el enlace en cuestión es

<a class="" href="http://host/path/course/view.php?id=33">jmeter course</a>

La función devolverá lo que hay después del "=", dentro del atributo href, es decir, 33.

Después se incluyen dos elementos, en elemento de retardo para simular la interacción humana y otro que irá construyendo un gráfico con todas los valores obtenidos en cuando los usuarios ejecuten la tarea en cuestión.

Controladores lógicos

Después de entrar a la plataforma programaremos una serie de tareas que deberán realizar todos los usuarios. Para ello vamos a incluir un controlador lógico de orden aleatorio... ¿Qué quiere decir esto? Las tareas que se incluyen dentro de este controlador serán ejecutadas por las hebras de forma desordenada. Unas hebras entregarán la actividad primero, otras postearán en el foro, etc. Todo para intentar que la actividad sea todo lo "caótica" que podría ser en un periodo de alta actividad en el servidor web.

Subida de ficheros

Además de los parámetros típicos, ya sean vía metodos GET o POST del servidor podemos utilizar ficheros para que sean subidos a la plataforma. En un objeto Request se pueden incluir ficheros dando la ruta al fichero en la sección Send files with the request. Además del MIME/Type y el nombre del parámetro con que se enviará el mismo.

Esto es muy útil cuando estamos probando aplicaciones que previsiblemente recibirán ficheros de cierto tamaño mientras siguen respondiendo a peticiones de otros usuarios.

Depurado

Para intentar detectar fallos en nuestro plan o fallos en nuestra aplicación tenemos dos herramientas básicas que nos ayudarán: El debug sampler y el objeto View Result Tree. Con el primero tendremos acceso a todas las variables y parámetros que hemos definido en el plan. Con el segundo podremos ver el diálogo entre el cliente y el servidor a bajo nivel, es decir, las cabeceras de la petición HTTP, los parámetros que se han enviado y la respuesta del servidor en HTML, los mensajes de error del servidor en caso de que los hubiera, etc. Como vemos en la figura muestra las el resultado de las assertions que hemos definido, para que detectemos fácilmente errores en el script. Si alguna respuesta del servidor no verifica la condición que hemos establecido, en lugar del triángulo verde mostraría un símbolo rojo informando del fallo.

Resultados

Los datos que genera Jmeter serán normalmente el tiempo que ha llevado cada petición contando desde que se ha enviado la misma hasta que se ha recibido la respuesta al completo. Para visualizar estos datos tenemos muchas opciones aunque las más interesantes son el simple data writer que generará un archivo con los datos en crudo para poder ser procesados posteriormente con otra herramienta o cualquiera de las opciones gráficas o de resumen que dan algunas medidas estadísticas. Todas estas opciones pueden ser utilizadas simultáneamente añadiéndolas desde la sección Listeners. Además cualquiera de estos informes pueden ser salvados a fichero para un posterior análisis en un fichero en disco.
En un post siguiente mostraré los resultados de una ejecución contra varias instalaciones de Moodle y lo más interesante y complejo: cómo interpretar los resultados... Pero para eso aún me faltan conos y bastones que quemar.

Descargar fichero de test

Revisión de opciones para el uso de la plataforma Moodle en dispositivos Móviles

Aceptado el artículo que hemos escrito Vanesa Gámiz Sánchez y yo en la revista RED donde hablamos de las distintas alternativas para acceder a Moodle con dispositivos móviles.

Abstract.

Los espacios y modelos de aprendizaje se han visto modificados radicalmente en los últimos tiempos gracias al avance de las tecnologías de la comunicación que han hecho posible el acceso y la producción de grandes cantidades de información; el desarrollo de aplicaciones y herramientas para mejorar la interacción entre las personas; y la extensión de dispositivos que han permitido el aumento de la movilidad de los usuarios. En este artículo analizamos cuáles son las circunstancias que están permitiendo el desarrollo y la expansión del uso de los dispositivos móviles en los procesos de aprendizaje en lo que se conoce como mobile learning o m-learning. En especial, nos interesa su implementación a través del entorno de enseñanza virtual Moodle. Para su estudio revisamos brevemente las opciones móviles más usadas para acceder a la plataforma Moodle ya sean aplicaciones nativas o plantillas/temas optimizados para dispositivos móviles. Por último, proponemos una de las metodologías más usadas para analizar la usabilidad de soluciones móviles, adaptándola al ámbito del estudio.

Enlace al texto completo.

Migración de materiales de WebCT a Moodle usando SCORM

En el evento MoodleMoot 2008 presentamos desde el CEVUG el proceso que utilizamos para migrar los materiales de nuestro antiguo WebCT a Moodle.
Aunque posiblemente ya queda un poco lejos aquel proceso, comparto la presentación que llevamos por si a alguien le resulta de utilidad.

WebCT de materiales de WebCT a Moodle (SCORM) from emilio_ah

Clase introductoria de eportafolios con Moodle y Mahara

Proyecto de Innovación Docente coordinado por Vanesa Gámiz: "El e-portafolio como estrategia didáctica de aprendizaje y evaluación. Implementación con Mahara integrado con Moodle"

Fragmentos de la clase de introducción impartida a los alumnos que participan en el PID.

Ir a la página del proyecto

Autenticando usuarios de Moodle 1.9 en Adobe Connect 8

Uno de los inconvenientes de la enseñanza online
es la sensación de distancia entre los alumnos y de éstos con profesores y tutores. La mayoría de los LMS (Learning Management Systems) proporcionan un reducido número de herramientas de comunicación síncronas y las típicas, como el chat, dejan mucho que desear a la hora de enriquecer la experiencia formativa. Normalmente se buscan soluciones con herramientas externas a la plataforma, como Messenger, Skype, etc., que se integran con mayor o menor acierto en el LMS de turno.

Una de las herramientas más utilizadas es Adobe Connect. Adobe Connect es una herramienta de web conferencing utilizada muy frecuentemente en ambientes educativos. Además de su función de servidor de conferencia web multipunto, permite la compartición de la pantalla del ordenador del ponente, la visualización de archivos de varios tipos (PDF, Power Point, etc.) , el envío de archivos entre asistentes, dispone de un chat integrado, etc., todo en un entorno muy cómodo construido sobre Flash.

Nuestra experiencia con este software ha sido agridulce... Las posibilidades son enormes, pero hemos tenido problemas al aplicar actualizaciones de Windows o de Connect. En cualquier caso, siempre hemos podido resolverlo.

Después de algún tiempo usando la herramienta de forma puntual hemos decidido dar el siguiente paso: realizar la integración con Moodle para ofrecer Connect de forma más generalizada. En este post explicaré como es el proceso de integración de Moodle y Connect usando el plugin de Remote Learner.

Lo primero, montar nuestro entorno de trabajo

Adobe Connect funciona sobre Windows 2003 Server o superior con MS SQL Server. Como uso linux recurro a VirtualBox para instalar mi servidor Connect de pruebas. Para poder acceder a la máquina virtual de Windows2003 por red usamos "Adaptador puente" en la configuración de red. De esta manera la máquina será accesible por la máquina anfitrión y cualquier otra que se encuentre en la red local. Comprobamos que todo funciona haciendo ping desde la máquina guest hacia la host y al contrario. También podemos comprobar que funciona con otras máquinas de la red local.

Cambiamos el nombre del equipo en la configuración de Windows. Usaremos este nombre al instalar Adobe Connect (hostname). No es mala idea modificar el fichero /etc/hosts de la máquina host y del resto de máquinas que accederán a Connect para evitar fallos de resolución de nombres y hacernos un poco más sencillo todo. Yo la he llamado mini-w2003 y su IP dentro de la red local es 192.168.1.45 así que añado al fichero /etc/hosts la siguiente línea:

192.168.1.45 mini-w2003

Instalar Adobe Connect 8

Descargamos y ejecutamos el instalador de Adobe Connect en la máquina virtual. Este paso quizás sea el más sencillo. Solo hay que seguir las instrucciones del instalador, que acabará abriendo una página de configuración similar a esta:

Comprobamos que Adobe Connect funciona correctamente creando una sala y accediendo a ella y seguimos con la instalación de Moodle.

Instalar y configurar Moodle

Necesitamos un servidor de aplicaciones de tipo Apache+MySQL+PHP, por ejemplo XAMPP, en el que instalamos Moodle. La versión de Moodle que he utilizado es la 1.9.14. Queda pendiente probar con Moodle 2.

Ya tenemos todas las herramientas sobre la mesa. Empezamos el trabajo delicado.

Autenticación de usuarios de Moodle en Adobe Connect usando el módulo

Para la integración he usado el módulo de Remote Learner por ser el más extendido aunque se han desarrollado otros como éste, de la Universitat Rovira i Virgili.

Lo que debemos hacer primero activar la API de WebServices de Adobe Connect. Para ello debemos:

Modificar el archivo [Instalación Connect]\appserv\web\WEB-INF\web.xml. Ojo! la documentación que hay en moodle.org la ruta correspondiente a Connect 7.5 y anteriores.

Debemos descomentar sólo (en la documentación también activan el filtro NtlmAuthenticationFilter), pero esto no es necesario. Copio aquí un extracto del fichero marcando las diferencias con la documentación oficial en Moodle.org:

<filter>

<filter-name>HeaderAuthenticationFilter</filter-name>

<filter-class>com.macromedia.airspeed.servlet.filter.HeaderAuthenticationFilter</filter-class>

<!--

<init-param>

<param-name>ignore-pattern-0</param-name>

<param-value>/api/</param-value>

</init-param>

-->

<init-param>

<param-name>ignore-pattern-1</param-name>

<param-value>/common/</param-value>

</init-param>

<init-param>

<param-name>ignore-pattern-2</param-name>

<param-value>/servlet/gateway/</param-value>

</init-param>

<init-param>

<param-name>ignore-pattern-3</param-name>

<param-value>/servlet/mirror</param-value>

</init-param>

<init-param>

<param-name>ignore-pattern-4</param-name>

<param-value>/servlet/testbuilder</param-value>

</init-param>

<init-param>

<param-name>ignore-pattern-5</param-name>

<param-value>/main</param-value>

</init-param>

</filter>

<filter-mapping>

<filter-name>HeaderAuthenticationFilter</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

</web-app>

Es normal que Connect no consiga arrancar si el fichero el fichero es incorrecto por lo que siempre es recomendable tener copia de seguridad de los archivos web.xml y custom.ini originales. Si después de modificar los archivos y reiniciar los servicios de Connect obtenemos errores de Tomcat al intentar acceder a Connect posiblemente haya algún error en los ficheros que hemos modificado.

También debemos añadir la siguiente línea al fichero [Instalación Connect]\custom.ini

HTTP_AUTH_HEADER=my-user-id

Utilizaremos el valor asignado a HTTP_AUTH_HEADER en la configuración del módulo de Connect en Moodle.

Instalamos el módulo en Moodle descomprimiéndolo en el directorio mod de la instalación entrando como administrador y pulsando en notificaciones para que se inicialicen las estructuras asociadas al módulo.

Acabamos la configuración del módulo abriendo la ventana de configuración del módulo y enlazando con la API de Connect:

Hay que tener especial atención al parámetro Email address login, que controla el nombre de usuario que se usará en Connect. Debemos usar la misma política de nombre de usuario que usa Adobe Connect. En mi caso, como al hacer la instalación de Connect indiqué que se usara el email como nombre de usuario debo marcar esta opción.

Pulsando en el botón "Test connection" el módulo ejecuta varias comprobaciones para verificar la conexión con el servidor de WebMeeting. Debo apuntar que aunque el test se ejecute correctamente puede haber pasos que no se lleguen a realizar. Por ejemplo, en una de nuestras pruebas el módulo conseguía crear la sala y los usuarios en Connect, pero no incluía a los usuarios en la sala recién creada.

Comprobando que todo funciona

Ya tenemos todo listo para crear nuestra primera sala de Connect desde Moodle. El funcionamiento del módulo es similar al de cualquier otra actividad de Moodle. Abrimos un curso, pulsamos en el botón de edición y escogemos "Adobe Connect" en la lista de actividades. Aparecerá una ventana como esta:

Los parámetros de configuración más imortantes son:

• Meeting Title. Es el nombre del recurso en Moodle.
• Meeting URL. El nombre de la sala en Adobe Connect. De manera que si queremos acceder a la sala sin usar Moodle podremos hacerlo usando la dirección http://servidorConnect/meeting-url. Es importante tener en cuenta que este parámetro no puede contener caracteres especiales.
• Meeting Type. El tipo de reunión Connect: pública o privada. En la publica podrá entrar cualquiera que tenga la URL además de los usuarios que Moodle ha registrado. En la privada solo entrarán los usuarios que estén en el curso con el rol correspondiente.
• Meeting Templates. La plantilla en la que queremos basar la sala.

Asignación de roles

Pero ¿qué usuarios entran en la sala? Para controlar el acceso a la sala el módulo crea tres nuevos roles en Moodle: El anfitrión (Adobe Connect Host), el presentador (Adobe Connect Presenter) y el participante (Adobe Connect Participant). Desde la gestión de roles del curso deberemos asignar estos roles para que nuestros usuarios tengan los privilegios adecuados en la sala de Connect.

Me queda pendiente probar el módulo en Moodle v2 y comprobar que los usuarios que acceden a Moodle usando plugins de autenticación (LDAP, p.e.) también son soportados por el módulo.... Pero eso lo dejaré para otra ocasión.