El día del examen o de la matrícula
Cientos de personas entran a la vez en la misma actividad. Ese pico crea unas condiciones distintas de las del uso diario, así que lo reproduzco y lo dimensiono por separado antes de la convocatoria.
Moodle · Plataforma
Rendimiento de Moodle: diagnostico la causa antes de ampliar la infraestructura
El pico de actividad puede explicar más problemas de rendimiento que el tamaño total del campus. La reacción habitual ante una degradación en el momento de máxima actividad es aumentar la capacidad de la máquina. Yo obtengo antes una medición de referencia, reproduzco la carga y determino si el límite está en PHP, la base de datos, las cachés, el almacenamiento, la red, las sesiones, las tareas o las integraciones. Con mucha concurrencia, encuentro a menudo el cuello de botella en la base de datos, pero no lo doy por supuesto. También compruebo las tareas en segundo plano, las integraciones que responden tarde y las extensiones que consultan dentro de un bucle: cualquiera de ellas puede explicar la degradación del día del examen.
- La documentación oficial recomienda establecer una línea base y actuar sobre el factor que más afecta a la experiencia medida.
- Una caché compartida en memoria puede producir una mejora notable en algunas instalaciones, pero su efecto depende de la carga y del componente que limite el rendimiento; hay que medirlo antes y después.
- Invocar el cron por línea de comandos evita el sobrecoste y los límites propios de la petición HTTP, aunque el proceso sigue consumiendo memoria y otros recursos.
- Añadir servidores web reparte la carga, pero puede aumentar la presión sobre otros componentes; el efecto debe medirse con la carga real.
Experiencia en plataforma
Diagnostico los picos de exámenes y matrículas observando la base de datos, la caché, las sesiones, las tareas en segundo plano, el almacenamiento y las integraciones. Reproduzco el comportamiento real y mido todas las capas antes de ampliar servidores o desactivar funciones.
Mi trayectoriaLos picos que cambian el comportamiento
El patrón aparece cuando una carga, una tarea o un volumen de datos que apenas se nota durante el uso ordinario coincide con una franja crítica.
Tras instalar una extensión nueva
Una extensión nueva puede consultar la base de datos dentro de un bucle o en cada carga de página. El efecto apenas se aprecia con poco uso y aparece al aumentar el volumen.
A determinadas horas, sin más usuarios
Las tareas programadas compiten por los mismos recursos. Si una tarea pesada coincide con la franja de mayor uso, la plataforma puede responder peor aunque no haya más personas conectadas.
Cuando el catálogo ha crecido mucho
Miles de cursos, un banco de preguntas grande o un histórico acumulado pueden aumentar el coste de consultas que antes eran baratas.
Dónde se va realmente el tiempo
Cinco lugares. En mi experiencia, el orden en el que aparecen los culpables es bastante estable.
- 01
La base de datos
Compruebo si la base de datos limita el rendimiento bajo concurrencia: ocurre con frecuencia, pero no parto de esa conclusión. En MySQL, el ajuste de InnoDB puede mejorar mucho el rendimiento. También reviso las consultas lentas, los índices que faltan y las tablas que han crecido sin control, y comparo siempre los resultados con una línea base.
- 02
La caché
Sin una caché compartida, los nodos no pueden reutilizar entre sí determinadas entradas y pueden repetir parte del trabajo cacheable. El efecto de compartirla depende de la carga y debe medirse. La documentación oficial recoge el testimonio de un colaborador para quien instalar Redis produjo la mayor mejora aislada en su sitio. Él mismo describe ese sitio como «relativamente pequeño». Lo cito como un caso, no como una medida oficial: mido el efecto en cada instalación.
- 03
Las sesiones
En sitios grandes, compruebo si guardar las sesiones en la base de datos está perjudicando el rendimiento. Solo cambio su almacenamiento después de medir y de diseñar el almacén alternativo para asegurar su disponibilidad, persistencia y recuperación.
- 04
Las tareas en segundo plano
Analizo el cron como parte del rendimiento general de la plataforma. La documentación oficial recomienda ejecutarlo directamente desde la línea de comandos, en vez de hacerlo por HTTP, porque así es más eficiente. También advierte de que la llamada por HTTP consume mucha memoria en instalaciones grandes. Compruebo si alguna tarea no termina, se solapa consigo misma o se ejecuta en hora punta: cualquiera de estas situaciones degrada la experiencia aunque no haya más usuarios.
- 05
El almacenamiento y las integraciones
Reviso el almacenamiento: si responde despacio, penaliza cada entrega de fichero. Mido también cuánto tardan las integraciones síncronas, porque una respuesta lenta bloquea la petición entera. Identifico así cuándo un servicio externo lento hace pensar que «Moodle va lento».
Errores frecuentes al diagnosticar
Seis formas de perder semanas mirando el sitio equivocado.
Medir solo el servidor web
Reviso el servidor web y la base de datos. Los indicadores de procesador y memoria del nodo web pueden parecer normales mientras la base de datos espera. Si no miro ambas capas, llego a una conclusión errónea.
Probar la carga sin reproducir el comportamiento real
Una prueba que solo pide la portada no se parece a un examen. Simulo el recorrido real: entrar, abrir el cuestionario, guardar respuestas y enviar.
Ignorar el efecto de las extensiones
Una extensión que consulta dentro de un bucle puede pasar inadvertida con poca carga y saturar un componente cuando aumenta la concurrencia. Empiezo mirando qué añadió el último despliegue.
Confundir lentitud de red con lentitud de plataforma
Si solo unas sedes o unos dispositivos notan el problema, compruebo la red y esos dispositivos antes de buscar el fallo dentro de Moodle: la plataforma puede no ser la causa.
Ignorar las tareas que no terminan
Reviso las tareas atascadas que se reintentan: consumen recursos sin parar y no aparecen en ningún panel de usuarios conectados.
Optimizar sin volver a medir
Comparo las medidas de antes y después para comprobar si el cambio ayudó, no tuvo efecto o empeoró otra cosa.
Cómo decido dónde intervenir
Cinco preguntas que me hago para no gastar en el sitio equivocado.
- 01
¿La degradación es constante o solo en picos?
Si la degradación es constante, reviso la configuración, las consultas y el código. Si solo aparece en picos, reviso la concurrencia, las sesiones, la caché y la capacidad. Distingo ambos diagnósticos porque exigen actuar en sitios distintos.
- 02
¿Cuántas personas hay realmente a la vez?
No cuento usuarios registrados ni activos al mes: cuento cuántos coinciden en la franja de máxima carga. Sin ese número, solo puedo dimensionar a ciegas.
- 03
¿La base de datos está ajustada o mantiene la configuración por defecto?
Si la reserva de memoria del motor sigue en el valor por defecto, compruebo con métricas si limita la carga antes de comprar capacidad.
- 04
¿Hay caché compartida y dónde se almacenan las sesiones?
Mido cuánto aumentan el pico de carga la falta de caché compartida y el almacenamiento de las sesiones en la base de datos antes de concluir que un único componente impone el límite.
- 05
¿Qué otras tareas detecté en ejecución en ese momento?
Compruebo si las tareas programadas, las copias de seguridad o las sincronizaciones coinciden con el pico, y mido su consumo y la contención que generan para determinar si contribuyen a la degradación.
Qué cambia según el tamaño
Dimensiono la plataforma según el volumen. Sobredimensionarla sale caro; quedarme corto, también.
- Instalación pequeña y estable
En una instalación pequeña y estable, considero suficiente un solo nodo bien ajustado si permite cumplir los objetivos de disponibilidad y recuperación y respetar las ventanas de mantenimiento. Elijo un clúster cuando la carga medida o los requisitos de continuidad, aislamiento o mantenimiento justifican su coste y complejidad.
- Miles de usuarios con picos moderados
Ajusto el componente que señalan las medidas, con especial atención a la base de datos, la caché, las sesiones y las tareas. En muchas instalaciones consigo mejoras sin cambiar la arquitectura, pero compruebo el efecto antes y después.
- Picos de convocatoria fuertes
Reproduzco el examen y localizo el límite. Si encuentro el cuello de botella en la capa web, valoro escalarla horizontalmente. Si lo encuentro en la lectura de la base de datos y la aplicación permite usar réplicas, las estudio. La carga medida me sirve además para dimensionar el almacenamiento, las sesiones y las tareas.
- Servicio crítico que funciona de forma continua
Combino la alta disponibilidad y la observabilidad con la degradación deliberada de funciones para conservar lo esencial durante un incidente.
Diez comprobaciones antes de ampliar nada
Si alguna falla, compruebo si la causa está en la configuración o en la operación antes de ampliar la infraestructura.
- Sé cuántas personas simultáneas hubo en el momento malo, no cuántas registradas.
- La reserva de memoria del motor de base de datos está ajustada al tamaño de la máquina.
- Si hay varios nodos o las mediciones muestran trabajo repetido, he comprobado si una caché compartida reduce la carga y sus métricas confirman que recibe tráfico.
- La ubicación de las sesiones se ha decidido después de medir y el almacén elegido tiene disponibilidad y recuperación definidas.
- El cron se ejecuta por línea de comandos y termina en un tiempo razonable.
- Sé qué tareas programadas coinciden con la franja de mayor uso.
- Tengo las consultas lentas registradas y revisadas.
- Sé qué extensiones se instalaron antes de que empezara el problema.
- Ninguna integración síncrona bloquea la petición sin límite de espera.
- Existe una medida antes y después de cada cambio.
Qué exigir sobre rendimiento en un pliego
No acepto «plataforma escalable» sin cifras ni una forma de comprobarlas: la expresión no define un criterio verificable y dificulta exigir su cumplimiento.
| Requisito | Evidencia exigible | Criterio de aceptación |
|---|---|---|
| Volumen de uso y concurrencia declarados | Número de usuarios activos, número máximo de usuarios simultáneos y franja horaria del pico | Cifras acordadas por escrito antes del diseño |
| Tiempo de respuesta acordado | Objetivo por tipo de página y percentil, no una media | Medición en producción que confirme el objetivo |
| Prueba de carga que reproduzca el examen | Guion con el recorrido real y los resultados obtenidos | Prueba superada con el volumen declarado antes de la primera convocatoria |
| Observabilidad entregada | Métricas de aplicación, base de datos, tareas e integraciones | La organización puede ver el estado sin depender del proveedor |
| Plan de degradación | Qué apago primero para conservar lo esencial | Procedimiento ensayado en un entorno de pruebas |
Lo primero que veo hacer y por qué suele fallar
Veo el mismo fallo en las tres reacciones habituales: aparecen antes de medir.
Ampliar el servidor
Duplicar la capacidad de proceso y la memoria del servidor web puede aliviar el síntoma. Si el límite está en la base de datos, más peticiones llegan antes al mismo cuello de botella.
Añadir más servidores web
Añadir nodos web aumenta la concurrencia contra las dependencias compartidas. Antes de hacerlo, mido las conexiones, las consultas, la caché y las colas. Solo valoro réplicas de lectura cuando la carga lo justifica y después de comprobar la compatibilidad y los requisitos de consistencia.
Desactivar funciones a ciegas
Mido el coste real antes de desactivar registros, informes o funcionalidades. Si los desactivo sin conocerlo, reduzco prestaciones y dejo el problema donde estaba, pero con menos información para diagnosticarlo.
Referencias
Fuentes y límites
- Documentación oficialRecomendaciones de rendimiento — documentación oficial de Moodle
Línea base, configuración del servidor web y de la base de datos, caché, cron y almacenamiento. Consultado el 1 de agosto de 2026.
- Documentación oficialCaché — documentación oficial de Moodle
Almacenes de caché disponibles y cómo se configuran. Consultado el 1 de agosto de 2026.
- Documentación oficialTareas programadas — documentación oficial de Moodle
Ejecución, frecuencia y control de las tareas en segundo plano. Consultado el 1 de agosto de 2026.
El orden en el que suelen aparecer los cuellos de botella es criterio propio formado diagnosticando plataformas concretas, no una regla universal: en tu instalación puede ser otro. Las recomendaciones de configuración proceden de la documentación oficial enlazada y sus valores concretos dependen de la versión, del motor de base de datos y del tamaño de la máquina, así que hay que comprobarlos allí antes de aplicarlos. No publico cifras de rendimiento de plataformas de clientes.
Blog
Diagnósticos de rendimiento con contexto.
En el blog documento diagnósticos de rendimiento con su punto de partida, la carga aplicada, el cuello de botella y el efecto medido tras cada cambio.
Ir a blog.albertolarah.comContacto
Cuando el campus funciona bien salvo el día que importa
Empiezo por cuatro datos: cuántas personas coinciden en el pico, qué hacen, qué medidas hay de ese momento y qué cambios recientes ha tenido la plataforma. Con eso distingo si el problema está en la configuración, en el código o en la capacidad.
hola@albertolarah.comLinkedIn ↗