MAQ Módulo 3 – Rendimiento: cuando el sitio va lento, todos lo saben
Hay una ley no escrita en la administración de sistemas educativos: cuando Moodle va lento, el teléfono suena. No importa la hora. No importa que sea periodo de exámenes y que precisamente por eso haya más carga. El administrador siempre es el primero en saber que algo va mal, aunque sea a través de un mensaje de WhatsApp del rector.
Este módulo del MAQ, Mantenimiento y Soporte 2.1 Rendimiento, toca algo que vivo en el día a día: cómo mantener un sitio Moodle respondiendo bien bajo carga real.
Lo que el MAQ propone
El marco DigCompLMSAdmin define esta competencia como “usar medidas de rendimiento recomendadas para la optimización y la escalabilidad”. Suena académico, pero en la práctica se traduce en tres preguntas concretas:
- ¿Está el servidor bien dimensionado?
- ¿Está la caché correctamente configurada?
- ¿Estoy monitorizando o simplemente esperando a que algo falle?
El Resumen de rendimiento
El primer recurso que menciona el MAQ es el Informe de Resumen de Rendimiento en Administración del sitio > Informes > Resumen de rendimiento. Es uno de esos paneles que mucha gente ignora hasta que hay un problema.
El semáforo es claro: verde está bien, ámbar es una advertencia que merece atención, rojo requiere acción inmediata. Lo que he aprendido con los años es que los ámbar crónicos son más peligrosos que los rojos puntuales. Un rojo se arregla. Un ámbar que llevas meses ignorando es una deuda técnica acumulada.
También existe la Información de rendimiento en Administración del sitio > Desarrollo > Depuración, que muestra en tiempo real el uso de RAM, tiempo de ejecución, archivos en uso y estado de las cachés. Útil para diagnosticar, pero hay que activarla con cuidado en producción — expone información técnica que no debería ver cualquier usuario.
La infraestructura importa más de lo que parece
El MAQ recomienda aumentar RAM como primer paso fundamental. Parece obvio, pero he visto instalaciones de Moodle para miles de usuarios corriendo en servidores con 4GB de RAM compartida con el servidor web, la base de datos y el servidor de caché. Todo en la misma máquina. El rendimiento en ese escenario no es un problema de configuración — es un problema de arquitectura.
En nuestra instalación actual, la separación de servicios marca la diferencia: servidor web dedicado, base de datos PostgreSQL en servidor propio, y caché Valkey (el sucesor de Redis) también separada. Cuando hay un pico de carga — inicio de semestre, periodo de exámenes, una sincronización masiva de usuarios — cada capa puede escalar de forma independiente sin afectar a las demás.
El caso de estudio del MAQ muestra exactamente esto: Greta, la administradora de una escuela vocacional, resolvió los problemas de pico configurando APCu para caché local y Redis para caché de sesiones. No es casualidad que la solución pase por la caché — es siempre el primer lugar donde buscar margen de mejora sin tocar el hardware.
Caché: el arma más infravalorada
Moodle tiene su propio sistema de gestión de caché llamado MUC (Moodle Universal Cache). Es sofisticado, flexible y habitualmente mal configurado. Por defecto, Moodle usa el sistema de archivos para la caché, que es funcional pero no óptimo.
La mejora más impactante que puedes hacer en un Moodle de cualquier tamaño es configurar una caché en memoria:
- APCu para instalaciones en servidor único — rápido, sin dependencias externas
- Redis o Valkey para instalaciones multi-servidor — permite compartir caché entre nodos
- Memcached como alternativa a Redis si ya lo tienes en infraestructura
En nuestro caso, la migración de caché de archivos a Valkey redujo los tiempos de respuesta de forma medible. No porque el sistema de archivos sea malo, sino porque la RAM es órdenes de magnitud más rápida que el disco, incluso con SSD.
PHP: los ajustes que marcan la diferencia
El MAQ menciona específicamente la configuración de PHP como palanca de rendimiento. Los parámetros más relevantes:
- memory_limit: Moodle recomienda mínimo 96MB por proceso, pero en producción con plugins pesados conviene 256MB o más
- max_execution_time: suficiente para operaciones largas como importaciones o backups, pero no ilimitado
- opcache: fundamental tenerlo activado — cachea el bytecode de PHP evitando recompilar en cada petición
- max_input_vars: Moodle con muchos ajustes puede necesitar aumentar este valor por encima del default de 1000
Plugins: menos es más
Una sección que me parece especialmente relevante del MAQ es la dedicada a minimizar el uso de plugins. Cada plugin adicional es código que se ejecuta en cada petición. Un Moodle con 80 plugins activos responde diferente que uno con 30, aunque el hardware sea idéntico.
La recomendación es hacer auditorías periódicas: ¿este plugin se usa realmente? ¿La funcionalidad que aporta justifica el coste en rendimiento? A veces instalamos un plugin para resolver un problema puntual y tres años después sigue ahí, activo, añadiendo latencia a cada carga de página.
Almacenamiento externo y CDN
Para sitios grandes con muchos archivos, el MAQ plantea dos estrategias complementarias:
Almacenamiento externo (Google Drive, Dropbox, o mejor aún, un almacén de objetos S3-compatible) — saca los archivos pesados del servidor Moodle, liberando espacio y ancho de banda local.
CDN — para sitios con usuarios geográficamente distribuidos, una red de distribución de contenidos almacena recursos estáticos cerca de los usuarios. La ganancia es especialmente notable para imágenes, CSS y JavaScript.
En infraestructuras sobre OpenShift o Kubernetes, el almacenamiento de objetos no es una opción sino una necesidad — los pods no tienen almacenamiento persistente local, por lo que los archivos de usuario deben vivir fuera del sistema de archivos del contenedor.
Mi reflexión personal
Lo que más me ha enseñado el trabajo real con Moodle a gran escala es que el rendimiento no se arregla una vez — se gestiona continuamente. Las cargas cambian, los patrones de uso evolucionan, se añaden plugins, crece el número de usuarios. Lo que funcionaba bien hace dos años puede ser un cuello de botella hoy.
Por eso el MAQ insiste en establecer procesos: un canal claro para que los usuarios reporten lentitud, revisión periódica del resumen de rendimiento, monitorización activa. No es glamuroso, pero es lo que distingue al administrador que previene problemas del que solo los resuelve cuando ya han ocurrido.
La próxima sección del módulo trata sobre actualizaciones. Una de las formas más directas — y más subestimadas — de mejorar el rendimiento de Moodle.
Este post forma parte de mi serie de apuntes para el examen de certificación MAQ. Si también estás preparándote, espero que te sea útil.
← MAQ Módulo 2 – Políticas del sitio | MAQ Módulo 3 – Actualización →
