Calendario
Matrícula, inicios de curso, evaluaciones, entregas, cierres y procesos batch que concentran actividad.
Artículo · Educación & Moodle
Dimensionar Moodle por concurrencia y calendario
Una ruta para transformar actividades académicas, picos esperados y comportamiento real en escenarios de prueba observables.
- Publicado
- Revisión técnica
- Revisor técnico
- Wilfredo Rodriguez · Principal Architect
- Estado
- Pieza técnica propia
Demanda educativa
Usuarios registrados no equivalen a carga simultánea
El total de cuentas o de personas conectadas no describe por sí solo el trabajo que debe atender la plataforma. La demanda cambia según la actividad: leer contenido, descargar archivos, rendir una evaluación, enviar tareas o ejecutar procesos programados producen patrones distintos.
MoodleDocs señala que la concurrencia depende de lo que el servidor está procesando y recomienda medir con un piloto. Por eso el dimensionamiento debe empezar con el calendario académico y los recorridos críticos, y terminar con pruebas sobre un entorno representativo.
Supuestos de la guía
Información mínima para construir escenarios
- 01La versión, los plugins y las integraciones de Moodle están identificados
- 02El calendario académico permite describir actividades y picos esperados
- 03Las pruebas se ejecutarán en un entorno controlado representativo, no directamente en producción
Modelo de demanda
Cuatro entradas antes de elegir capacidad
Recorrido
Acciones reales de estudiantes, docentes y administradores, con pausas y secuencias representativas.
Plataforma
Versión, plugins, tema, integraciones, sesiones, caché, archivos, base de datos y tareas programadas.
Criterios
Tiempos observables, errores, colas, saturación y recuperación aceptables para cada escenario acordado.
Ejemplo sintético · Sin datos de clientes
Del calendario a un escenario de prueba
Pensemos en una institución ficticia que espera un periodo de evaluaciones. En lugar de multiplicar el número de matriculados por una regla genérica, describe cuándo comienzan las evaluaciones, qué páginas se recorren, qué plugins intervienen y qué tareas coinciden en el mismo intervalo.
El equipo reproduce ese recorrido en un entorno controlado, aumenta la demanda gradualmente y observa aplicación, caché, archivos y base de datos. La capacidad se decide con los resultados y los márgenes acordados; este ejemplo no establece una cifra reutilizable para otros sitios.
Escenario
Inicio de evaluación, navegación, guardado y entrega, junto con la actividad administrativa prevista.
Observación
Respuesta de la aplicación, errores, consumo y comportamiento de caché, almacenamiento y base de datos.
Decisión
Ajustar configuración, arquitectura o capacidad y repetir la prueba hasta sostener los criterios acordados.
Plan de validación
Cómo hacer que la prueba sea repetible
- 01Definir recorridos y datos de prueba que representen actividades permitidas
- 02Preparar un entorno aislado y controlar versiones, configuración y estado inicial
- 03Calentar componentes cuando corresponda y documentar cada ejecución
- 04Aumentar la demanda por etapas, observar cuellos de botella y conservar resultados
- 05Repetir después de cada cambio y validar también recuperación y operación
Fuentes primarias
Documentación utilizada
Performance FAQ
MoodleDocs sobre concurrencia, actividad real, pilotos y límites de las reglas genéricas.
Conocer más ↗Performance recommendations
MoodleDocs sobre medición, configuración, caché, base de datos y escalabilidad.
Conocer más ↗Moodle performance comparison
Herramientas de Moodle HQ para generar planes de prueba y comparar configuraciones en entornos controlados.
Conocer más ↗Tu próximo paso
Preparar mi evaluación Moodle ↗