Rendimiento y fiabilidad:
post-mortem y mejoras
Resumen del trabajo realizado sobre los problemas de rendimiento y de edición reportados: causas encontradas y mejoras aplicadas en tres frentes — infraestructura, editor de proyectos y rendimiento de la aplicación.
Del reporte a la corrección en tres días
Todos los problemas reportados tienen causa identificada y corrección implementada.
Se ha actuado en tres frentes: la infraestructura del servidor (ya en producción), el editor de proyectos y el rendimiento de la aplicación (implementados y verificados, llegan con el próximo despliegue).
- Últimas semanasReportes acumulados de docentes y del equipo: sensación de lentitud, errores intermitentes de «servicio no disponible» en momentos de uso intenso, y problemas al editar proyectos (cambios que no se veían hasta recargar, errores de permisos al borrar preguntas).
- 13 de julioRefuerzo de infraestructura (ya en producción): el servidor pasa de una instancia única a un mínimo de dos siempre activas, con escalado automático hasta cuatro y una recalibración del mecanismo que causaba los errores de «servicio no disponible».
- 14 de julioAnálisis a fondo de la aplicación: métricas de infraestructura, registros del servidor minuto a minuto y auditoría del código, para localizar el origen del trabajo innecesario y de los fallos del editor.
- 15 de julioCorrección de la aplicación: los tres planes de trabajo resultantes (editor, peticiones, caché) quedan implementados, revisados y verificados contra datos reales.
Ineficiencias que crecían con el uso
Ninguna causa era una avería: eran ineficiencias acumuladas que crecían con el uso — la plataforma pedía los mismos datos una y otra vez, algunas pantallas pedían mucho más de lo que mostraban, y el servidor no tenía margen para absorber los momentos de trabajo intenso.
Un único servidor sin margen
Toda la plataforma dependía de una sola instancia. Cuando una operación pesada (generar un proyecto, un PDF, una importación) la ocupaba, un mecanismo de protección demasiado estricto respondía «servicio no disponible» al resto de usuarios.
Los textos de la interfaz, ~30 veces por sesión
Cada pantalla volvía a descargar, pieza a pieza, todas las traducciones de la interfaz — sin guardarlas para la siguiente.
Un recuento lento en cada visita
Contar los proyectos visibles para cada docente costaba casi 2 segundos y se repetía en cada página de Explorar y de la biblioteca.
Pantallas que traían datos de más
La ficha de proyecto y la generación de PDF descargaban estructuras completas (plantillas, currículo, ejercicios) cuando la vista solo necesitaba una parte. Las vistas de clase hacían cientos de consultas encadenadas.
El editor guardaba bien, pero mostraba mal
Al editar bloques y ejercicios, los cambios sí se guardaban, pero la pantalla seguía enseñando la copia antigua hasta recargar. El borrado de preguntas usaba una vía que requería permisos que el rol docente no tiene (el mensaje «No tienes permisos»), y las preguntas nuevas podían insertarse al final en lugar de en su sitio.
De un servidor único a redundancia elástica
- Redundancia real: dos servidores siempre activos repartiéndose el trabajo. Si uno está ocupado con una operación pesada, el otro sigue atendiendo con normalidad.
- Escalado automático: cuando la carga sostenida sube, se añaden servidores solos (hasta 4) y se retiran cuando baja — sin intervención manual.
- Adiós al «servicio no disponible»: recalibrado el mecanismo de protección que rechazaba peticiones cuando una operación intensiva ocupaba el servidor. Era la causa directa de los errores intermitentes reportados.
- Despliegues más rápidos y fiables, con reconstrucciones aceleradas para reducir ventanas de entrega.
- Siguiente paso ya diseñado: separar el trabajo pesado de IA en un servicio propio, para que la generación de proyectos nunca comparta cola con la navegación de los docentes.
Editor fiable y menos trabajo repetido
Editor de proyectos: sincronización total
Bloques y ejerciciosSe rediseñó cómo el editor refresca lo que ves tras cada acción: ahora toda vista que muestre una copia del bloque se actualiza al momento, y las operaciones sobre preguntas son atómicas — una sola operación, sin estados intermedios.
- Guardar un texto deja visible lo guardado inmediatamente — y si fallara, se ve el error (antes podía aparentar éxito).
- Crear una pregunta la muestra al instante y exactamente en la posición elegida (arriba, en medio o al final).
- Borrar una pregunta ya no da «No tienes permisos»: el borrado usa la vía correcta, dentro de los permisos normales del docente.
- La numeración se mantiene visible mientras editas, en los diez tipos de pregunta.
- Renombrar un bloque respeta el nombre que pone el docente.
- Estadísticas: eliminado un bucle de recargas que hacía «parpadear» la página.
Menos trabajo repetido con la base de datos
Rendimiento · peticionesLas peticiones redundantes se han consolidado o eliminado: los textos de la interfaz se descargan una vez y se reutilizan, las vistas de clase calculan lo pendiente en un puñado de consultas, y cada pantalla pide exactamente los campos que muestra.
- Traducciones: de ~30 descargas por sesión de trabajo a 1, compartida entre todos los usuarios durante 10 minutos.
- Tareas pendientes de una clase (25 alumnos): de ~400 consultas encadenadas a 4, con idéntico resultado.
- Ficha de proyecto y PDF: el PDF maneja un 74% menos de datos en proyectos grandes.
- Catálogos con memoria de corto plazo (cursos, materias, biblioteca, plantillas): respuesta casi instantánea tras la primera consulta; los datos vivos — entregas, notas, notificaciones — siguen siempre en tiempo real.
Antes y después, medido
Seis cambios visibles en el día a día
Lo que guardas es lo que ves, al momento y en todas las vistas del proyecto — sin recargar la página.
Se crean donde las pides, conservan su número mientras editas y se borran sin errores de permisos.
Cambiar de pestaña dentro de un proyecto y moverse por Explorar y la biblioteca responde notablemente más rápido.
Los errores de «servicio no disponible» en momentos de uso intenso desaparecen: hay redundancia y el mecanismo que los causaba está recalibrado.
El recuento de tareas pendientes deja de ser un cuello de botella en clases numerosas.
Menos trabajo repetido + servidores elásticos = mucho más margen en inicios de clase e importaciones masivas.
Fin de la pantalla de «Application error»
Algunos usuarios veían, de forma intermitente y sin poder reproducirlo, una pantalla con el mensaje «Application error» en lugar de la página. Al ser un fallo que ocurre por completo en el navegador, no dejaba ningún rastro en los registros del servidor, lo que hacía muy difícil localizarlo. Se hizo una revisión transversal de la plataforma para encontrar las causas y, sobre todo, para dejar de estar a ciegas ante estos errores.
La causa más probable: las actualizaciones de la plataforma
Cuando se publica una versión nueva, un usuario con la pestaña abierta desde antes podía pedir una pieza de la web que esa actualización había renovado. Al no existir ya con el nombre antiguo, la pantalla fallaba. Explica el patrón intermitente y sin página fija.
Navegadores con el almacenamiento bloqueado
En navegación privada o en equipos de centros con el almacenamiento restringido, un acceso interno a la memoria del navegador lanzaba un error que rompía la carga de datos de toda la app.
Qué hemos hecho
Pantalla propia · auto-recuperación · diagnósticoAhora, si algo falla en el navegador, el usuario ve una pantalla de error propia y con la marca —en lugar de una página en blanco— y, en la mayoría de los casos, la aplicación se recupera sola. Además, cada error queda registrado para poder corregirlo.
- Pantalla de error propia: sustituye a la pantalla en blanco genérica, con opciones claras para recargar o volver al inicio.
- Auto-recuperación tras una actualización: si el error se debe a una versión recién publicada, la página se recarga sola una vez y el usuario continúa sin hacer nada (con una protección para no entrar en bucle).
- Ya no nos quedamos a ciegas: cada error de navegador se registra en el servidor con su detalle, así que a partir de ahora se pueden diagnosticar y corregir uno a uno.
- Detalles técnicos a un clic: un desplegable en la propia pantalla permite copiar o mandar un pantallazo útil si el usuario necesita reportarlo.
- Ronda de robustez: se blindaron varios puntos que podían tumbar la pantalla —portfolio, tareas del profesor, vistas de fase, el muro de mensajes y el cambio entre vista de profesor y alumno—, además del caso del almacenamiento bloqueado.
Qué queda por delante
- ✓Infraestructura: en producción desde el 13 de julio. Redundancia, escalado automático y recalibración del limitador ya están activos.
- ✓Aplicación: implementado y revisado. Editor y rendimiento completados, con revisión de código y verificación funcional interactiva contra el entorno real.
- ✓Estabilidad del cliente: implementado y verificado. Nueva pantalla de error con auto-recuperación e instrumentación de los errores de navegador; llega también con el próximo despliegue.
- 1Despliegue de la aplicación a producción por el circuito habitual (pruebas → demo → producción), con el próximo ciclo de entrega.
- 2Medición posterior: tras el despliegue se volverán a medir tiempos de respuesta y actividad del servidor para confirmar las mejoras con uso real.
- 3Optimizaciones ya diseñadas: separar el trabajo pesado de IA en un servicio propio, y consolidar un recálculo interno que hoy se ejecuta varias veces al editar competencias.