La mayoría de los problemas de rendimiento de Moodle no vienen de la plataforma, sino de un dimensionamiento hecho con el número de matriculados en lugar de con la concurrencia real. Esta guía explica cómo estimarla y traducirla a recursos. Somos el Moodle Certified Partner del Perú.
Matriculados no es concurrencia
Una institución con veinte mil matriculados rara vez tiene veinte mil personas dentro al mismo tiempo. El número que importa es cuántas peticiones llegan por minuto en la hora más cargada del periodo más cargado del año.
Dimensionar con el total de matriculados lleva a pagar por capacidad ociosa once meses al año. Dimensionar con el promedio lleva a caerse justo en la semana de exámenes. El objetivo es dimensionar con el pico medido y dejar margen.
Cómo estimar tu concurrencia real
Si ya tienes Moodle en operación, la estimación sale de tus propios registros. Tres consultas bastan: usuarios únicos activos por franja de quince minutos, distribución de esa actividad a lo largo del día y comparación entre una semana normal y una semana de evaluaciones.
Si todavía no tienes plataforma, la estimación se construye desde el calendario: cuántos grupos rinden evaluaciones simultáneas, de qué tamaño y en qué franjas. El dato relevante es el grupo más grande que coincide en el tiempo, no el total institucional.
Anota también los eventos no académicos que generan picos: publicación de notas, apertura de matrícula y campañas de capacitación obligatoria con fecha límite.
El perfil de uso cambia todo
Mil personas leyendo materiales consumen mucho menos que mil personas rindiendo un cuestionario con imágenes, y muchísimo menos que mil personas subiendo archivos de video al mismo tiempo.
Para dimensionar conviene clasificar el uso en tres perfiles: lectura de contenidos, actividad evaluada (cuestionarios, tareas, foros) y carga de archivos pesados. La proporción entre ellos define si el cuello de botella estará en la base de datos, en el procesamiento o en el almacenamiento.
Las evaluaciones masivas merecen un tratamiento aparte: revisa nuestro artículo sobre exámenes y concurrencia en Moodle.
Qué componentes se dimensionan
Un Moodle en producción tiene cuatro piezas que se dimensionan por separado:
- Servidor de aplicación: atiende las peticiones web. Escala bien horizontalmente cuando el diseño lo permite.
- Base de datos: suele ser el primer cuello de botella en actividades evaluadas. Necesita memoria suficiente y consultas sanas.
- Almacenamiento de archivos: crece de forma constante y pide una política de retención.
- Caché: reduce trabajo repetido y es el ajuste con mejor relación entre costo y mejora percibida.
A eso se suman las tareas programadas de Moodle, que deben correr sin competir con el tráfico de usuarios en la hora pico.
Almacenamiento y crecimiento anual
El almacenamiento se planifica con la tasa de crecimiento observada, no con una cifra inicial. Durante un semestre, mide cuánto crecen los archivos de curso y cuánto los envíos de estudiantes; proyecta con esa pendiente y añade el espacio que ocupan los respaldos según su política de retención.
Si el video pesa mucho en tu plan, evalúa alojarlo en un servicio especializado y enlazarlo desde Moodle. Es más barato y evita que el crecimiento de video arrastre el dimensionamiento de toda la plataforma.
Pruebas de carga antes del pico
Una prueba de carga responde la única pregunta que importa: con este dimensionamiento y este perfil de uso, ¿a partir de qué punto el tiempo de respuesta se degrada?
La prueba debe reproducir el escenario real, no una navegación genérica: ingreso, apertura del cuestionario, respuesta de varias preguntas y envío. Se ejecuta en un entorno equivalente al de producción y con datos parecidos en volumen.
El resultado no es un número de aprobación, sino una curva. Saber dónde empieza la degradación permite decidir si se agrega capacidad, se escalona el calendario o se ajusta la configuración.
Cuánto margen dejar
El margen razonable depende de qué tan predecible sea tu pico. Con un calendario académico estable y picos conocidos, un margen moderado sobre el pico medido es suficiente. Con crecimiento acelerado o campañas imprevisibles, conviene un margen mayor o la capacidad de ampliar rápido.
Lo que no funciona es dimensionar exactamente al pico observado: cualquier cambio de comportamiento, un plugin nuevo o una actualización de versión mueve la línea.
Señales de que te quedaste corto
Antes de una caída hay avisos: páginas que tardan más en horas pico, tiempos de espera al guardar intentos de cuestionario, tareas programadas que se acumulan, errores intermitentes al subir archivos y crecimiento sostenido del uso de memoria de la base de datos.
Si tu proveedor no te muestra esos indicadores, no tienes forma de anticipar. El monitoreo con acceso a la institución debería ser parte del contrato: revisa nuestro artículo sobre qué exigir en un SLA de soporte.
Revisar el dimensionamiento cada periodo
El dimensionamiento no es una decisión de una sola vez. Al cierre de cada periodo conviene comparar el pico real con el estimado, revisar el crecimiento de almacenamiento y ajustar antes del siguiente ciclo.
Esa revisión toma poco tiempo y evita la conversación de emergencia en plena semana de exámenes. Si quieres una primera aproximación, usa el estimador de sizing y los errores comunes de hosting Moodle.