Moodle lento: cómo diagnosticar la causa real
«El campus va lento» es un síntoma, no un diagnóstico. Esta guía ordena las causas por frecuencia real y explica cómo distinguirlas antes de invertir en más servidor.
Primero: ¿lento para quién y cuándo?
Antes de tocar la configuración hay que acotar el problema. ¿Es lento para todos los usuarios o solo para algunos? ¿A cualquier hora o en los picos de matrícula y entrega de trabajos? ¿En todas las páginas o solo en el libro de calificaciones de cursos grandes?
Estas tres preguntas separan cuatro problemas distintos: saturación de infraestructura, consultas ineficientes en páginas concretas, un plugin problemático o un cuello de botella de red del lado del usuario. Invertir en un servidor más grande cuando el problema es una consulta mal indexada no resuelve nada y encarece la operación de forma permanente.
Causas ordenadas por frecuencia
| Causa | Señal característica |
|---|---|
| Caché mal configurada o desactivada | Lentitud generalizada y constante, sin relación con la carga |
| Tareas programadas mal distribuidas | Picos de lentitud a horas fijas y repetidas |
| Libro de calificaciones en cursos masivos | Solo esa página es lenta; el resto responde bien |
| Plugin con consultas ineficientes | Lentitud aparecida tras instalar o actualizar un componente |
| Almacenamiento con latencia alta | Lentitud al abrir y subir archivos, no al navegar |
| Infraestructura infradimensionada | Lentitud proporcional al número de usuarios concurrentes |
La caché es el primer sitio donde mirar
Moodle tiene un sistema de caché por capas. En instalaciones que crecieron sin acompañamiento técnico es habitual encontrarlo en su configuración por defecto, escribiendo en disco lo que debería estar en memoria.
Mover las cachés de aplicación y sesión a un almacén en memoria suele producir la mejora más grande por unidad de esfuerzo en toda la operación. Es también el cambio más seguro de revertir si algo sale mal.
Tareas programadas: el pico de las 3 de la mañana
Moodle ejecuta decenas de tareas en segundo plano. Cuando varias tareas pesadas coinciden en el mismo minuto, el servidor se satura y los usuarios activos a esa hora perciben la plataforma caída.
La solución no es desactivar tareas, sino escalonarlas y revisar cuáles están tardando de forma anómala. Una tarea que antes tomaba dos minutos y ahora toma cuarenta suele indicar una tabla que ha crecido sin depuración.
Cuándo sí es la infraestructura
Después de descartar lo anterior, el dimensionamiento sí puede ser el límite. La señal que lo confirma es una relación clara y sostenida entre usuarios concurrentes y tiempo de respuesta, con la memoria o la CPU en niveles altos durante los picos.
En ese escenario, ampliar recursos es la decisión correcta. Pero llegar ahí después de haber descartado lo demás significa que se paga por capacidad que realmente hace falta, y no por compensar una configuración deficiente.
¿Su plataforma responde mal en los picos de actividad?
Escríbanos con el contexto de su organización. Respondemos con criterio técnico, no con un formulario de ventas.
Contactar