Plataforma Moodle en la UPC: Estudio sobre

Arquitectura y Rendimiento
Marcos Montero Torres

Abstract. Proyecto de diseo e implantacin de una arquitectura Moodle con capacidad para
dar servicio a un colectivo de 30.000 usuarios bajo criterios de escalabilidad, rendimiento y alta
disponibilidad. Al margen del diseo de la arquitectura, se definen y desarrollan unas pruebas
de rendimiento que nos permitan mejorar la eficiencia del sistema y determinar de manera
fiable la validez de la plataforma respecto a la dimensin del entorno con antelacin suficiente
a su puesta en explotacin. As mismo, se pretende poder repetir este tipo de estudios de
rendimiento para realizarlos de forma habitual previo a futuras modificaciones de la plataforma
Moodle.
Keywords: Moodle, rendimiento, Jmeter, Campus Digital, UPC, UPCnet, Atenea.

1 Introduccin
Durante el curso 2005/2006 la UPC realiz un proyecto piloto de implantacin de una
nueva plataforma de e-Learning basada en Moodle. Este piloto tena un mbito
limitado dentro de la universidad, ofrecindose un pequeo nmero de asignaturas a
un colectivo formado por 4700 alumnos y 700 profesores.
La UPC ya dispona de una plataforma de e-Learning propia, desarrollada
enteramente desde la propia universidad y con un grado de implantacin y uso
considerables. Una vez valoradas diversas alternativas y comprobada la viabilidad del
uso de Moodle desde el punto de vista docente y su adaptabilidad a las necesidades
del profesorado de la UPC se decidi su utilizacin como herramienta de e-Learning
global en toda la universidad y, para ello, se procedi a disear un proyecto para
acometer la extensin del nuevo campus digital, (conocido como Atenea), a toda la
comunidad UPC.
En su nueva fase, el campus digital debera ofrecer servicio a un colectivo de 30.000
estudiantes y 3.000 profesores, ofreciendo un nmero aproximado de 4.000 cursos
Moodle.
Este volumen lo converta, no slo en una herramienta clave en el entorno docente de
la universidad, sino en una de las mayores instalaciones de Moodle en el entorno
Universitario hispano. Y como tal, resultaba imprescindible que su implantacin fuera
un completo xito. Como factor clave para este xito (aunque no el nico), la
plataforma que ofreciera este servicio deba cumplir una serie de requisitos en cuanto

a rendimiento, escalabilidad y disponibilidad que garantizasen el correcto

funcionamiento de Moodle bajo condiciones extremas de carga y permitieran dar
respuesta con facilidad a futuras ampliaciones del servicio, ya fuera en nmero de
usuarios, asignaturas o capacidad de carga.
La entrada en funcionamiento del sistema definitivo se produjo en septiembre de 2006
y durante los meses anteriores se llevaron a cabo el proyecto de diseo de la
arquitectura y el estudio de rendimiento que aqu se describen para garantizar su
correcto dimensionado.

2 Arquitectura Hardware

2.1 Arquitectura durante el piloto

En su primera versin, la arquitectura de soporte a Moodle estaba formada por 2
capas diferenciadas:

Capa de Front-end: formada por 3 servidores Debian + Apache. Existe un

nombre DNS genrico para el campus que contiene las IPs de los 3 servidores. El
reparto de la carga entre los front-ends se realiza de forma transparente a travs
del RoundRobbin que proporciona el mecanismo de resolucin del DNS.

Capa de Back-end: formada por 1 nico servidor de Bases de datos con un

SGBD PostgreSQL ms un espacio de disco exportado por NFS al que acceden
los 3 front-ends. El servidor de Backend tiene los datos ubicados en sendas
particiones locales con RAID5.

Fig. 1. Arquitectura de la plataforma moodle UPC durante el proyecto piloto

2.2 Arquitectura actual

En la nueva arquitectura se mantienen los conceptos bsicos del piloto: una nica
instancia de Moodle para dar servicio a toda la comunidad UPC y separacin fsica de
los servidores web y servidores de bases de datos. Ahora, adems, se hace especial
nfasis en mejorar las posibilidades de escalabilidad, distribucin de la carga y alta
disponibilidad.
La arquitectura definitiva consta de 4 capas diferenciadas:
Balanceo de carga:
Se incorpora un cluster formado por 2 servidores Linux con LVS + HA que se
encargan de balancear el trfico entre los diferentes Front-ends HTTP. Permiten
distribuir la carga de manera inteligente, as como mejorar la disponibilidad
eliminando de forma dinmica los Front-ends que no se encuentren en
funcionamiento. Tambin permiten crecer o decrecer, (por necesidades de

mantenimiento, p.ej), al sistema de forma transparente, con slo aadir o eliminar

nodos al conjunto de Front-ends y sin impacto en el servicio.
Front-ends HTTP
Mantiene la misma estructura hardware que tena anteriormente. Est formada por 3
servidores Linux con Debian + Apache. Se trata de servidores con 2 CPU Xeon
2,8Ghz y 4Gb de RAM. Se han realizado ciertas mejoras a nivel de software que se
comentan ms adelante en este documento.
Back-end
Formada por 2 servidores, de los cuales slo uno ofrece servicio al campus:
1 servidor Back-end primario. 6Gb de RAM y 4 CPUs. Contiene el
SGBD postgreSQL v8.1 y una placa HBA Emulex LPE9802 de 2Gbit para su
conexin a una red SAN.
1 servidor Back-end de backup. Se trata de una mquina de
caractersticas hardware muy similares a la anterior y configuracin idntica.
La eleccin de esta disposicin vino determinada por el hecho de que en el momento
de la implantacin de Moodle en la UPC los nicos candidatos disponibles, (debido a
limitaciones impuestas por Moodle), para su utilizacin como SGBD eran MySQL y
PostgreSQL. Ninguna de estas 2 plataformas ofrece todava un soporte para clustering
suficientemente maduro (ni de complejidad asumible). Por este motivo se opt por la
utilizacin de un sistema sin alta disponibilidad automatizada. Un nico servidor se
encarga de gestionar el acceso a los datos, pero se ha dotado a la plataforma de un
nodo de backup que, junto con el almacenamiento en SAN, garantice una rpida
recuperacin del servicio en caso de avera hardware.
Almacenamiento SAN
Los datos se encuentran ubicados en volmenes especficos en una SAN formada por
un Diskarray FDA2400 Bull y 2 Switches fiber-channel Brocade Silkworm 3850. Los
volmenes de datos estn formados por particiones RAID-6 (que ofrecen 2 discos de
redundancia) con un tamao 120Gb para la base de datos y 200Gb para el sistema de
ficheros moodledata.

Fig. 2. Arquitectura actual de la plataforma Moodle en la UPC.

3. Herramienta de simulacin

3.1 Criterios de seleccin

La eleccin de la herramienta de simulacin viene determinada por su capacidad para
llevar a cabo unas pruebas realistas que nos permitan verificar el rendimiento de
moodle para toda la UPC. Los factores fundamentales que se han tenido en cuenta
para ello son los siguientes:

Posibilidad de establecer y verificar criterios de calidad de uso: por ejemplo,

la generacin de estadsticas en base al tiempo de respuesta para cada peticin
HTTP o el nmero/porcentaje de peticiones errneas.

Gestin de concurrencia de usuarios: la herramienta debe ser capaz de

simular accesos simultneos al sistema por parte de usuarios diferentes. Debe
poder gestionar su autenticacin y las caractersticas propias de cada uno de ellos.

Escalabilidad: Es imprescindible que la herramienta sea capaz de generar

simulaciones con cargas muy elevadas para responder a las necesidades cada vez
mayores del entorno del campus digital.

Posibilidad de realizar pruebas realistas: no sirve cualquier simulacin. No

basta con lanzar peticiones HTTP al azar al sistema. Para garantizar la fiabilidad
del test es necesario utilizar patrones de navegacin semajantes a los de los
usuarios del sistema, contemplar tiempos de sesin similares a los suyos e incluso
intervalos entre diferentes peticiones lo ms prximos posibles a la realidad. En
definitiva, es importante poder disear perfiles de uso adaptados al entorno de
explotacin y que la herramienta sea capaz de reproducirlos a gran escala.

3.2 J-meter
La herramienta seleccionada para realizar las pruebas de rendimiento ha sido Apache
Jmeter. Desarrollada por la Apache Software Foundation, se trata de una aplicacin
100% Java que se utiliza habitualmente para realizar pruebas funcionales y medir
rendimientos. Fue originalmente diseada para testear aplicaciones web, pero desde
entonces ha evolucionado incrementando su funcionalidad y los tipos de pruebas a los
que puede aplicarse.
Puede utilizarse para simular condiciones de carga muy elevada en servidores, redes o
aplicaciones concretas, para comprobar su capacidad o analizar el rendimiento
general bajo diferentes condiciones de carga.

Sus caractersticas principales son las siguientes:

Modelado de la carga. A partir de logs reales de Apache o generando

usuarios modelo especficos para nuestra aplicacin.
Autenticacin y gestin de cookies para cada usuario.
Permite verificacin de criterios de calidad.
Posibilidad de instalacin en cluster para simulaciones que requieran cargas
muy elevadas.

4. Pruebas de rendimiento
La realizacin de las pruebas de rendimiento del sistema tena dos objetivos
complementarios: el primero, certificar la validez de la arquitectura tecnolgica
escogida para soportar volmenes de carga adecuados segn la magnitud del
colectivo de alumnos/profesores de la UPC (30.000 alumnos, 3000 profesores). El
segundo, detectar los aspectos mejorables de la plataforma para dotarla de la
capacidad de respuesta suficiente y una vez conseguida esta, tener una idea lo ms
exacta posible de los elementos susceptibles de mejora en futuras ampliaciones.

4.1 Preparacin del escenario de pruebas

Como paso previo para la realizacin de las pruebas de carga, se elabor un perfil de
uso del campus digital basado en los datos reales de utilizacin del sistema durante el
proyecto piloto. La intencin era conseguir informacin lo ms fiable posible sobre el
estilo de navegacin de los usuarios en el campus: tiempos de sesin, secciones ms
accedidas, intervalos entre peticiones etc...
Para conseguir estos datos fue necesario seleccionar los perodos de mayor actividad
durante la duracin del proyecto piloto. Se extrajeron los logs de los servidores web y
se eliminaron las entradas correspondientes a los perodos no lectivos. Con ayuda de
un programa de estadsticas web, (Awstats), se seleccionaron los perodos con
mayores niveles de concurrencia y, a partir de estos datos, se obtuvieron los
siguientes parmetros:

Tiempo medio de sesin: 7,25 mins

50,26 Hits/usuario
90% entradas pertenecientes a alumnos, 10% a profesores
lista de URLs ms accedidas

Una vez determinados los aspectos ms relevantes que definen el comportamiento de

los usuarios, se elaboraron 2 perfiles de navegacin diferenciados para distinguir
profesores y alumnos. El acceso de otros perfiles de uso a moodle es tan marginal

respecto de estos dos que no se consider necesaria su inclusin en las pruebas de

carga.
La elaboracin de los perfiles se hizo combinando los resultados extrados del estudio
de los logs con navegacin especfica aportada por usuarios experimentados en el uso
de Moodle. De esta forma se pretenda garantizar un nivel mnimo de acceso a las
reas ms importantes del campus en cada sesin.
Los siguientes pasos fueron montar un entorno de pruebas reducido, (formado
exclusivamente por 1 front-end y 1 backend), y trasladar a este una copia de la Base
de Datos de explotacin. Sobre esta base de datos con su contenido ntegro, se
aadieron un total de 3000 usuarios de prueba, (300 profesores y el resto alumnos),
matriculados en diversas asignaturas creadas expresamente para la prueba. El objetivo
era disponer de una base de datos que no tuviera tablas recien creadas y con los datos
mnimos, sino que tuviera el tamao y posible degradacin propia del uso habitual
pero incrementados con los nuevos usuarios y asignaturas.

4.2 Ejecucin de las pruebas: Cuellos de botella y Soluciones implementadas

Una vez establecido el escenario de pruebas, comenz un plan de ejecucin de las
mismas durante 2 meses, utilizando primero un entorno de test y realizando 2 pruebas
finales en el entorno de explotacin ya con su configuracin definitiva.
La complejidad de las pruebas fue incrementndose de manera gradual. Comenzando
con niveles de concurrencia muy sencillos (1 nico usuario para comprobar la validez
de los perfiles, 10-20 usuarios simultneos, 50-100 usuarios, 200 usuarios... ), y
finalizando con las 2 pruebas a gran escala sobre el entorno real de explotacin.
Esta aproximacin gradual se escogi porque nos permita ir descubriendo paso a
paso los distintos cuellos de botella del sistema y proponer las soluciones ms
adecuadas para solventarlos antes de acometer la siguiente prueba. De esta forma, el
sistema iba mejorando su rendimiento progresivamente y en el momento de
realizacin de los 2 tests definitivos sobre el entorno de explotacin ya se dispona de
un sistema completamente afinado en todos sus componentes.
Para las pruebas definitivas sobre el entorno de explotacin se utiliz una
configuracin de Jmeter en cluster para poder generar la carga necesaria. El objetivo
era comprobar que el sistema era capaz de atender 1.000 usuarios de moodle
trabajando simultneamente, para lo que se realizaron pruebas de las siguientes
caractersticas:

#PC cluster Jmeter #Hits/seg

#Hits/hora

Usuarios concurrentes

Prueba 1

12

600

2.100.000

1.200

Prueba 2

18

800

2.900.000

1.500

Cabe destacar que la simultaneidad no hace referencia a meras peticiones http, sino a
la cantidad de usuarios que se encuentran en el sistema ejecutando parte de una sesin
tal y como la hemos definido previamente en los perfiles. Es decir, estamos ante
1200 o 1500 sesiones de 7 minutos y de usuarios diferentes que se ejecutan de manera
solapada en el tiempo.
A continuacin se resumen los cuellos de botella ms importantes que se detectaron
en la plataforma conforme avanzaban las pruebas y las soluciones que se aportaron
para cada uno de ellos. Se presentan agrupados segn la capa de la plataforma en la
que se ha actuado:

Balanceadores de carga:
Una vez instalados los balanceadores, las actuaciones sobre ellos consistieron en
afinar al maximo los valores de los diferentes time-outs de ldirector y en definir un
test adecuado para la comprobacin del servicio http (en nuestro caso, la consulta de
un archivo .gif).
Front-ends HTTP:
Instalacin de un acelerador PHP. (PHP eAccelerator)
Puesto que el cdigo Moodle est basado en PHP casi en su totalidad, esta es la
medida de tuning ms evidente. Aun as, los ratios de mejora observados cuando se
instala un acelerador pueden variar dependiendo de diversos factores. En nuestras
pruebas se observaba una mejora sustancial pero no excesiva (alrededor de un 15% de
incremento de la capacidad del sistema respecto a las pruebas sin acelerador).
Procesos de Apache.
Es el objetivo prioritario de la actuacin. La capacidad de concurrencia del web server
depende, en gran medida, (el aprovechamiento de la CPU ya mejora gracias al
acelerador PHP), de la memoria disponible.
Aunque Apache es un servidor web de magnficas prestaciones, la utilizacin de PHP
nos impone algunas restricciones: puesto que PHP no es un producto considerado
thread-safe, no es posible ejecutar Apache bajo el mdulo mpm-worker, que es donde
consigue un mayor rendimiento. Moodle (PHP, en realidad) nos obliga a utilizar el
mdulo mpm-prefork, pasando a usar Apache en multiproceso en lugar de multithread. Esto quiere decir que para atender cada peticin HTTP Apache lanza un

proceso hijo que consume memoria adicional. As, la cantidad de procesos Apache
que puede tener nuestro sistema tiene como lmite fsico la memoria disponible
dividida entre la memoria ocupada por uno de estos procesos.
En nuestras mediciones se observ que el peso de un proceso Apache oscilaba entre
los 10 y 12Mb (llegando incluso a 15Mb segn las condiciones del sistema).
Suponiendo un sistema con 3Gb libres de memoria, podramos tener no ms de 300
procesos en marcha en cada Front-end.
Para incrementar este lmite sin aumentar la memoria fsica de nuestros servidores, se
examin con detalle el trfico HTTP y se determin que ms del 50% de las
peticiones que deba atender el servidor web corresponden a contenido esttico.
Concretamente imgenes de poco tamao (gif, png, jpg...) que se sirven una y otra
vez y se encuentran en cabeceras, pies de pgina, iconos, logos, etc...
Como solucin para aumentar la capacidad del sistema se instal en los servidores
Front-end un segundo servidor Apache con una configuracin extremadamente
simple: se compil expresamente sin la mayor parte de mdulos que lleva un servidor
estndar, de tal manera que debido a esta simplicidad, sus procesos slo ocupan
2Mbytes de RAM.
Este servidor que llamamos tiny-apache pasa a ser el servidor web que atiende en el
puerto 80. Para cada peticin que le llega lo nico que hace es: determinar si se trata
de contenido esttico o dinmico, servir la peticin si se trata de contenido esttico, y
en otro caso, pasarla al servidor apache estndar, (que ahora corre en el puerto 8080).
Con este mecanismo, la mayor parte de las peticiones HTTP que recibe el sistema, las
atiende un servidor cuyos procesos slo ocupan 2Mbytes de memoria en lugar de los
10-12Mbytes anteriores; gracias a ello se incrementa considerablemente el nmero de
peticiones que es capaz de atender simultneamente el sistema.
Back-end:
Las actuaciones en el Back-end se orientaron bsicamente a buscar la configuracin
necesaria para garantizar que el SGBD pudiera soportar un nmero muy elevado de
conexiones simultneas. En nuestro caso, 1.500 conexiones.
Para conseguirlo, aparte de la configuracin del servidor PostgreSQL hubo que
modificar los valores de determinados parmetros referentes a la gestin de memoria
en el kernel de linux.
La experiencia ha demostrado que el nmero de conexiones a la Base de datos suele
mantenerse en niveles considerablemente bajos incluso cuando tenemos un nmero
muy elevado de peticiones simultneas al sistema. Si el servidor tiene memoria y
CPU suficiente, suelen servirse muy rpido.
Sin embargo, condicionantes externos pueden hacer que su duracin sea mayor y, por
tanto, su nmero se incremente muy rpidamente en condiciones de carga elevada. Es
por esto que es importante que el sistema sea capaz de absorber muchas
simultneamente. De todas formas, un nmero muy elevado de conexiones
postgreSQL de forma sostenida habitualmente constituye un buen indicio de que el

sistema tiene algn problema (ya sea debido a hardware, lentitud en la red, falta de
algn ndice en alguna tabla, consultas muy costosas, malfuncionamiento de algn
mdulo de moodle, etc...)

5. Conclusiones

5.1 Validez de la plataforma y cifras actuales de uso.

La conclusin ms obvia una vez puestas en funcionamiento todas las medidas de
mejora y realizadas las pruebas de rendimiento, es que ahora tenamos la certeza de
que la nueva plataforma Moodle tena capacidad suficiente para asumir la carga
prevista una vez incorporados la prctica totalidad del alumnado y asignaturas al
campus digital.
De hecho, las cifras extradas durante el primer cuatrimestre de uso del sistema son
suficientemente clarificadoras y refrendan esta conclusin da tras da. A continuacin
pueden verse algunos datos:

Usuarios distintos

Nmero de logins Registro de actividad

Diario

12.000

32.000

320.000

Semanal

20.000

140.000

1.200.000

Mensual

25.000

400.000

4.500.000

Las cifras de la tabla corresponden a valores promedio observados durante 2007. De

ellas se desprende que el xito de la plataforma es incuestionable: segn se observa,
cada da utilizan la plataforma de campus digital 1/3 del total de alumnos de la UPC,
algunos de los cuales lo hacen ms de una vez. Y en un mes la prctica totalidad de
los alumnos ha accedido al campus al menos en una ocasin.
De hecho, en los das laborables el nmero de sesiones moodle establecidas se
encuentra en valores cercanos a 1.000 de manera sistemtica durante la prctica
totalidad del tiempo comprendido entre las 10:00h y las 22:00h.
En pocas de uso intensivo de la plataforma, (a final de cuatrimestre), se han
producido picos de ms de 2.000 usuarios simultneos en el sistema de manera
sostenida sin apenas impacto en la carga o en la velocidad de respuesta de los
servidores.
La columna Registro de actividad hace referencia a las entradas contenidas en la
tabla Log de Moodle. En esa tabla Moodle guarda referencias a la actividad que sus
usuarios llevan a cabo en el sistema. Es muy apreciada por los profesores por su

utilidad a la hora de determinar las materias que ms han interesado a los alumnos, los
ejercicios ms realizados, qu apartados de una asignatura han sido ms visitados,
etc El nmero de registros en esa tabla es un indicador infalible del grado de
actividad de los usuarios en la herramienta.
Al observar la tabla con detenimiento, queda patente que con semejantes cifras de
acceso diarias, forzosamente la complejidad y duracin de las sesiones reales en la
actualidad difiere en cierta medida, (y necesariamente a la baja), del modelo que se
utiliz para realizar las pruebas del sistema. Es lgico que una vez la plataforma se
extiende a un pblico mucho ms amplio y se generaliza su utilizacin, los patrones
de uso varen sustancialmente. El acceso ms frecuente lleva consigo el reparto del
trabajo entre las diferentes sesiones e implica, tanto la reduccin de la complejidad de
las tareas que se realizan en una sesin, como una disminucin en la duracin de la
misma. En cualquier caso, estas reducciones se compensan con el incremento global
de peticiones y, en estas nuevas condiciones, el sistema todava debe garantizar,
(como de hecho sucede), la capacidad suficiente para atender la elevada demanda de
conexiones al sistema.

5.2 Otras conclusiones: factores clave de xito.

Al margen de las conclusiones relativas a la validez o no de la plataforma escogida,
existen un conjunto de resultados, (ms bien lecciones), extraidos de este proyecto
quiz no tan evidentes pero que pueden tener tanta o ms importancia que la primera:

Perfiles de usuario: factor clave para de xito.

Conseguir unos perfiles de usuario lo ms ajustados posible a la realidad, (o como
mnimo, a la realidad que nos interesa reproducir), es el factor ms importante a la
hora de realizar las pruebas de rendimiento con cierta garanta de xito. Aunque hay
que ser consciente de que se trata de pruebas de laboratorio, es importante reproducir
el escenario de la forma ms realista posible.
No todos los mdulos de moodle tienen el mismo impacto en el rendimiento del
sistema y por tanto, es importante dar a cada componente un peso similar en las
pruebas al que tiene en el uso diario.
Cambios en plataforma o soft requieren nuevas pruebas.
Una prueba de rendimiento de nuestra plataforma realizada hoy slo tiene validez
mientras no se produzca ninguna variacin en los elementos del sistema, ya sean
hardware o software.
Aadir procesadores, memoria, o incrementar la velocidad de la red tendrn un
impacto, (la mayor parte de las veces positivo), en el rendimiento. Pero es muy difcil
de cuantificar a priori.

Los cambios en el software, ya sean por cambio de versin de Moodle, utilizacin de

nuevos mdulos, cambios en versiones del webserver, el servidor de bases de datos o
cualquier otro componente de software base... son delicados y su influencia en el
comportamiento final del campus digital en muchos casos es una incgnita.
Por este motivo, cualquier cambio en el sistema requiere de nuevas pruebas para que
podamos estar seguros de que la plataforma seguir comportndose como esperamos.
Aun as, hay que ser consciente de que no siempre es necesario acometer un proyecto
enorme para hacer estas comprobaciones. Dependiendo de la dimensin de los
cambios podemos, desde decidir no hacerlas, hasta realizar algunas pruebas de
pequea complejidad que nos sirvan exclusivamente para comparar el rendimiento
entre las versiones ya conocidas y las nuevas.
Necesidad de un entorno de pruebas estable.
Para dotar a este proyecto de una cierta continuidad, es recomendable disponer de un
entorno de test estable. Lo ideal sera disponer de una rplica exacta del entorno de
explotacin, pero eso no siempre es fcil de conseguir. De hecho, tampoco es
imprescindible, aunque s que es importante que ambos entornos sean fcilmente
comparables, (p.ej, no montar un entorno de pruebas basado en un servidor que
integre Front-end y Back-end si nuestro entorno de explotacin tiene estos
componentes separados). De esta forma ser posible extrapolar los resultados
obtenidos en las pruebas y minimizar la necesidad de recurrir al entorno real, cuya
disponibilidad para estos temas suele estar muy restringida.

6. Bibliografa
Libros:
PostgreSQL (2nd edition), by Korry Douglas.
Apache Cookbook: Solutions and examples for Apache administrators, by Rich
Bowen & Ken Coar.
Apache, the definitive guide (2nd edition), by Ben Laurie & Peter Laurie.
Recursos on-line:
PostgreSQL: documentation http://www.postgresql.org/docs
The Linux Virtual Server Project http://www.linux.virtualserver.org
Wikipedia http://www.wikipedia.org
Apache JMeter: http://jakarta.apache.org/jmeter/
Apache performance tuning http://httpd.apache.org/docs/2.0/misc/perftuning.html

Using Moodle: Hardware & performance

http://moodle.org/mod/forum/view.php?id=596
Sakai project: http://sakaiproject.org/