Hay una historia que se repite con demasiada frecuencia en administración de Moodle: una plataforma funcionando con la configuración por defecto durante años, sin que nadie la toque, hasta que llega un pico de tráfico (el inicio de curso, una convocatoria de examen) y el servidor se pone al 98% de CPU con apenas unos cientos de usuarios conectados a la vez. La causa casi nunca es “el servidor es pequeño”: es que nadie había afinado nada desde el primer día.
En esta guía vas a ver las cinco palancas reales que determinan la velocidad de Moodle, en qué orden atacarlas, y los detalles técnicos que marcan la diferencia entre una configuración que funciona sobre el papel y una que aguanta de verdad un pico de tráfico real.
Por qué el rendimiento no es un lujo, es una cuestión de resultado educativo
Cada 100 milisegundos de latencia adicional reduce mediblemente el compromiso y las tasas de finalización de curso. No es una afirmación exagerada: una plataforma lenta genera abandono, sesiones interrumpidas y frustración, especialmente en momentos críticos como un examen con tiempo limitado. El rendimiento de Moodle no es solo una cuestión técnica, es directamente una cuestión de resultado educativo.
Las cinco palancas del rendimiento
1. Arquitectura dimensionada según usuarios concurrentes, no cuentas totales
El dimensionamiento correcto de servidor depende de usuarios concurrentes, no del número total de cuentas registradas. Como referencia orientativa:
| Usuarios concurrentes | Arquitectura recomendada |
|---|---|
| Hasta 100 | 2-4 vCPU, 4-8 GB RAM, todo en un mismo servidor con almacenamiento NVMe |
| 200-500 | 4-8 vCPU, 8-16 GB RAM, con base de datos idealmente en servidor separado |
| Más de 500-1.000 | Varios nodos web, base de datos dedicada, y Redis en su propio servidor |
Añadir más núcleos de CPU más allá de 8-16 vCPU rara vez aporta mejoras proporcionales para una carga de trabajo típica de Moodle, el cuello de botella, superado ese punto, suele estar en otro lado (base de datos, I/O de disco), no en la CPU.
2. PHP y OPcache: la mejora más rápida y más grande que puedes hacer
Activar OPcache suele ser, por sí sola, la mejora individual más rápida y de mayor impacto en el tiempo de carga de página. Configuración de referencia para producción:
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=10000
opcache.validate_timestamps=0
opcache.save_comments=1El detalle que atrapa a casi todo el mundo una vez: con validate_timestamps=0, PHP deja de comprobar si los archivos han cambiado, lo que mejora el rendimiento pero significa que después de cada despliegue de código o actualización de plugin, hay que reiniciar PHP-FPM o ejecutar opcache_reset() manualmente, de lo contrario, el servidor sigue sirviendo el bytecode compilado de la versión anterior, y un plugin recién actualizado puede parecer que “no ha hecho nada” cuando en realidad OPcache simplemente no se ha enterado del cambio.
3. Base de datos: el corazón de Moodle
Moodle ejecuta habitualmente entre 200 y 500 consultas a base de datos por cada carga de página. Si esos datos no están en memoria, el servidor tiene que leerlos de disco, con el coste de latencia que eso implica. La configuración de referencia:
innodb_buffer_pool_sizeajustado a aproximadamente el 70% de la RAM disponible en el servidor de base de datos, para que los datos más consultados queden en memoria.- Usar InnoDB como motor para todas las tablas.
- Activar el registro de consultas lentas para identificar qué operaciones concretas están penalizando el rendimiento.
- Revisar y optimizar tablas de forma periódica, no solo al instalar.
Profundizamos en esta palanca en optimizar la base de datos de Moodle.
4. Caché en memoria con Redis
Moodle, por defecto, cachea buena parte de su información en disco, una opción notablemente más lenta que la memoria. Mover las cachés de sesión y de aplicación (MUC) a Redis es, según la experiencia de administradores que ya lo han aplicado, una de las mejoras individuales más grandes que se pueden hacer en una instalación real, especialmente si el almacenamiento en disco no es NVMe.
El detalle que solo se aprende una vez, del modo difícil: conviene usar políticas de expulsión de caché distintas para sesiones y para MUC. Las sesiones deberían usar noeviction (si la memoria se llena, mejor un error visible que perder sesiones de usuarios activos sin avisar); la caché MUC puede usar allkeys-lru sin problema, porque Moodle la regenera automáticamente en la siguiente petición si se expulsa. Mezclar ambas bajo la misma política ha causado más de un incidente de sesiones perdidas en producción sin previo aviso.
Lo tratamos en profundidad en Redis para Moodle: caché en memoria explicado y en OPcache en Moodle: qué es y cómo configurarlo.
5. Servidor web, CDN y cron
- Nginx + PHP-FPM tiende a mantener mejor el rendimiento a medida que sube la concurrencia, frente a Apache con mod_php. Los runtimes más nuevos (Nginx Unit, FrankenPHP) no cuentan con soporte oficial para Moodle.
- Un CDN para contenido estático (imágenes, CSS, JS) reduce la latencia sirviendo esos recursos desde el nodo más cercano al usuario, con beneficio proporcional a lo geográficamente distribuidos que estén tus alumnos.
- El cron por línea de comandos, ejecutado cada minuto, evita los timeouts que puede generar ejecutarlo vía HTTP y mantiene las tareas de fondo (notificaciones, limpieza, informes) sin competir directamente con el tráfico real de usuarios.
Profundizamos en cada uno en requisitos de servidor para Moodle, el cron de Moodle: por qué es crítico y CDN para Moodle: cuándo tiene sentido.
Nunca optimices a ciegas
Antes de cambiar cualquier configuración, captura una referencia de partida (tiempos de carga actuales en flujos reales: login, inicio de un cuestionario, envío de una tarea, generación de un informe), cambia una sola cosa, y vuelve a medir el mismo flujo. Optimizar varias variables a la vez sin medir entre cada cambio hace imposible saber cuál de ellas realmente movió la aguja, y, en ocasiones, alguna “optimización” recomendada en un blog no aporta nada en tu caso concreto.
Checklist previa a un pico de tráfico (examen, inicio de curso)
| Punto | Verificado |
|---|---|
| OPcache activado y sin reinicios recientes de PHP-FPM pendientes tras el último despliegue | ☐ |
| Sesiones y cachés clave funcionando en Redis, no en disco | ☐ |
| Ratio de aciertos del buffer pool de InnoDB alto (revisar métricas) | ☐ |
| Logs lentos de PHP-FPM limpios, sin acumulación de peticiones bloqueadas | ☐ |
| Prueba de carga realizada sobre los flujos reales (login, cuestionario, envío, informes) | ☐ |
Errores comunes que deshacen todo el trabajo de optimización
- Olvidar reiniciar PHP-FPM tras un despliegue con
opcache.validate_timestamps=0activo, sirviendo código desactualizado sin ningún error visible. - Mezclar la política de expulsión de sesiones y MUC en la misma instancia de Redis, arriesgándose a perder sesiones activas sin previo aviso.
- Dimensionar el servidor según cuentas totales en vez de usuarios concurrentes reales, sobredimensionando o infradimensionando según el caso.
- Dejar plugins sin usar activos, que siguen añadiendo tiempo de procesamiento a cada carga de página aunque nadie los use activamente.
- No hacer pruebas de carga antes de un pico previsible (examen, inicio de curso), descubriendo los límites del servidor en el peor momento posible.
Preguntas frecuentes
¿Cuál es la mejora de rendimiento con mayor impacto por menor esfuerzo? Activar OPcache correctamente configurado suele ser la mejora individual más rápida y de mayor impacto en el tiempo de carga, y es relativamente sencilla de aplicar.
¿Necesito servidores separados para web y base de datos desde el principio? No necesariamente. Para instalaciones de hasta unos pocos cientos de usuarios concurrentes, un único servidor bien dimensionado y afinado suele ser suficiente.
¿Redis sustituye completamente la necesidad de una base de datos bien configurada? No, son complementarios: Redis reduce la carga de sesiones y ciertos datos cacheables, pero la base de datos sigue gestionando la mayoría de las consultas reales de contenido y calificaciones.
¿Qué pasa si activo opcache.validate_timestamps=0 y no reinicio tras un despliegue?
El servidor sigue sirviendo el código compilado anterior al cambio, provocando que actualizaciones de plugins o de núcleo parezcan no aplicarse, aunque técnicamente sí se hayan instalado.
¿Cuántos vCPU necesito para varios cientos de usuarios concurrentes? Como referencia orientativa, entre 4 y 8 vCPU con 8-16 GB de RAM suele ser suficiente para 200-500 usuarios concurrentes, aunque siempre conviene validarlo con pruebas de carga reales.
¿El CDN merece la pena si mis alumnos están todos en la misma ciudad? El beneficio de un CDN es proporcional a lo geográficamente distribuidos que estén tus usuarios, si están todos muy concentrados, el impacto será menor que en una plataforma con alumnos repartidos por distintas regiones.
¿Con qué frecuencia debería revisar el rendimiento de mi Moodle? Al menos antes de cada pico de tráfico previsible (inicio de curso, exámenes), y de forma periódica para detectar degradaciones progresivas antes de que se conviertan en un problema visible para los usuarios.
Conclusión
Un Moodle rápido no depende de trucos exóticos, depende de aplicar de forma consistente cinco fundamentos: arquitectura bien dimensionada, PHP con OPcache correctamente gestionado, base de datos afinada, caché en memoria con Redis, y un servidor web más CDN adecuados. Cada palanca por separado es sencilla; lo que marca la diferencia es aplicarlas todas y medir cada cambio antes de dar el siguiente paso.
Si prefieres no tener que vigilar tú mismo cada una de estas palancas antes del próximo pico de tráfico, en Avantys lo llevamos como parte del mantenimiento continuo de cada Moodle que gestionamos. Puedes pedir una auditoría gratuita en Moodle Gestionado.
Artículos relacionados
- Por qué mi Moodle va lento: causas más comunes
- Redis para Moodle: caché en memoria explicado
- OPcache en Moodle: qué es y cómo configurarlo
- Requisitos de servidor para Moodle (CPU, RAM, disco)
- El cron de Moodle: por qué es crítico
- Optimizar la base de datos de Moodle
- CDN para Moodle: cuándo tiene sentido
- BigBlueButton en Moodle: requisitos de servidor
¿Y si tu Moodle lo lleváramos nosotros?
Actualizaciones, backups verificados, rendimiento y trazabilidad FUNDAE, gestionado de forma continua por una persona que responde. Auditoría gratuita de tu plataforma actual.
