# 09 - Migliorie performance post analisi migliorie app ## Piano iniziale sintetico 1. Consolidare le evidenze gia presenti in `08_migliorie_app.md`, `07_differenze_cross_app.md`, `structure_and_functions.md` e `sophia_customizations.md`. 2. Tradurre le evidenze tecniche in hotspot prestazionali osservabili, limitandosi a cio che il corpus locale dimostra davvero. 3. Ordinare le proposte per priorita, impatto, costo e rischio, evitando ottimizzazioni speculative. 4. Separare chiaramente i contributi su: - rendering e griglie - sessione e continuita di navigazione - error handling e logging - backlog documentale e punti da validare 5. Chiudere con assunzioni, limiti e punti da validare con il team. ## Contesto e perimetro analisi performance `yii-framework-base` e il repository documentale del layer Yii/Sophia comune, non una business app verticale. Questa analisi quindi non misura un carico applicativo di produzione, ma ricava miglioramenti plausibili dal comportamento del framework e dalle customizzazioni gia documentate. Le evidenze usate come base sono quelle gia consolidate nel corpus locale: - `08_migliorie_app.md` - `07_differenze_cross_app.md` - `structure_and_functions.md` - `sophia_customizations.md` - `cross_app_capability_registry.md` L'analisi e limitata alle aree dove il repository mostra una base tecnica concreta: - `CGridView`, `CGridColumn` e `jquery.yiigridview.js` - `CHttpSession` - `CErrorHandler` e `framework/views/exception.php` - registry cross-app e tassonomia documentale Non sono presenti nel corpus locale metriche runtime di produzione, profili di query o benchmark strumentali. Di conseguenza la baseline qui sotto e una baseline documentale, non una misurazione sintetica da APM o load test. ## Baseline e metriche di riferimento ### Baseline documentale Le metriche di riferimento ricavate dal corpus sono indicatori tecnici osservabili, non tempi numerici: - complessita del rendering griglia: `CGridView` orchestra header, filtri, body, footer e script client - costo potenziale del rendering colonna: `CGridColumn` gestisce header, filtro, body e footer per ogni colonna - costo potenziale dei filtri avanzati: `jquery.yiigridview.js` ha piu passaggi di gestione per filtri inline e ricerca avanzata - costo di continuita sessione: `CHttpSession` impone apertura, chiusura, cookie, timeout e cache-control - costo di diagnosi errori: `CErrorHandler` e `exception.php` aggiungono rendering e logging ### Metriche di riferimento da usare prima/dopo Per allineare future verifiche, le metriche minime da misurare sono: - tempo di rendering di una vista griglia complessa - numero di query generate da una pagina lista con filtri e relazioni - numero di passaggi JS necessari per aprire, applicare e chiudere filtri avanzati - tempo di risposta percepito in caso di sessione scaduta o back browser - costo di logging per eccezione e frequenza di eccezioni ripetute ### Baseline cross-app Dal confronto cross-app emerge che le stesse capability tecniche sono riusate in piu verticali. Questo suggerisce che gli eventuali miglioramenti di performance sul layer base avrebbero impatto trasversale, ma il corpus non contiene valori comparativi numerici. La baseline cross-app e quindi questa: - il layer grid e il punto con piu customizzazioni tecniche consolidate - sessione e error handling sono standard condivisi, quindi ogni miglioramento ha raggio ampio - il repository base non espone un dominio verticale proprio, percio il rischio principale e infrastrutturale, non funzionale ## Hotspot identificati ### 1. Rendering delle griglie **Evidenza** - `structure_and_functions.md` descrive la catena `CGridView` -> `CGridColumn` -> `jquery.yiigridview.js` - `sophia_customizations.md` documenta fix ripetuti su filtri avanzati, filtri inline, textarea, e seconda riga footer - `07_differenze_cross_app.md` segnala che il layer grid e piu maturo del singolo modulo verticale medio **Perche e un hotspot** - il rendering di una griglia coinvolge piu passaggi e piu oggetti per cella/colonna - filtri avanzati e footer estesi aumentano il lavoro lato server e lato client - il pattern e riusato ovunque, quindi anche inefficienze piccole si moltiplicano **Indicatore osservabile** - numero di colonne renderizzate per griglia - presenza di filtri avanzati e inline insieme - presenza di footer estesi o componenti custom nelle colonne ### 2. Continuita di sessione e browser-back **Evidenza** - `structure_and_functions.md` documenta `CHttpSession` e il controllo di cache-control - `sophia_customizations.md` indica che l'header `Cache-Control: no cache` migliora l'affidabilita del back browser **Perche e un hotspot** - il controllo sessione impatta tutti i flussi autenticati - back browser e session timeout generano spesso ricarichi inutili, stati incoerenti o refresh ripetuti **Indicatore osservabile** - frequenza di riapertura di form dopo back browser - numero di redirect o refresh dovuti a sessione non valida - eventuali duplicazioni di submit legate al rientro su pagine cache-ate ### 3. Error handling e logging **Evidenza** - `structure_and_functions.md` descrive `CErrorHandler` - `sophia_customizations.md` indica che `exception.php` scrive i dettagli su file prima del rendering **Perche e un hotspot** - il logging file-based puo introdurre I/O aggiuntivo in caso di errori ripetuti - il rendering del dettaglio eccezione e utile, ma deve restare leggero e coerente **Indicatore osservabile** - numero di eccezioni ripetute sullo stesso flusso - presenza di logging sincrono su file per eventi frequenti - differenza tra modalita debug e produzione nel costo del rendering ### 4. Replica di parsing e logica di presentazione **Evidenza** - `structure_and_functions.md` mostra che il controller prepara modello, data provider e configurazione di rendering - la stessa action puo esporre rendering diverso per griglia, filtri, form e bottoni **Perche e un hotspot** - la logica di presentazione ripetuta in piu rami porta a lavoro duplicato - configurazioni renderizzate piu volte sono candidate naturali a cache o consolidamento **Indicatore osservabile** - stessa configurazione costruita piu volte nella stessa request - rami di render multipli per la stessa entita ## Schede per ottimizzazione ### 1. Consolidare il rendering delle griglie **Problema** Il layer griglia e ricco ma costoso da mantenere: `CGridView`, `CGridColumn` e `jquery.yiigridview.js` sono stati estesi in piu punti, quindi il rischio non e solo funzionale ma anche prestazionale. **Proposta** Definire una check-list tecnica che riduca le combinazioni costose: - usare filtri avanzati solo quando servono davvero - evitare l'accoppiata tra filtri inline complessi e colonne custom inutili - limitare footer estesi alle griglie che lo richiedono - consolidare configurazioni ripetute in helper o preset documentati **Impatto atteso** - minor costo di rendering - meno lavoro JS per l'apertura/applicazione dei filtri - maggiore uniformita nelle liste amministrative **Costo** - basso-medio, soprattutto documentale con eventuali ritocchi puntuali **Rischio** - basso, se la check-list resta conservativa **Priorita** - alta ### 2. Rendere esplicito il comportamento sessione/back browser **Problema** Il comportamento e gia corretto a livello di framework, ma il corpus non mostra una regola operativa unica che limiti i casi di ricarico o stato incoerente. **Proposta** - standardizzare le schermate sensibili con indicazione esplicita del comportamento atteso in caso di back browser - verificare che i flussi multi-step usino la sessione in modo coerente e non accumulino stati inutili - preferire rientri guidati a refresh liberi dove il dato e critico **Impatto atteso** - meno submit duplicati - meno errori percepiti come lentezze - miglioramento della continuita di navigazione **Costo** - basso **Rischio** - basso **Priorita** - alta ### 3. Ridurre il costo del logging eccezioni **Problema** Il logging su file per le eccezioni e utile, ma se gli errori diventano ripetitivi il costo I/O si somma al costo del rendering. **Proposta** - distinguere chiaramente tra errori rari e errori ripetuti - limitare il logging sincrono ai casi realmente necessari per diagnosi - mantenere la diagnosi dettagliata in debug e una traccia piu leggera in produzione **Impatto atteso** - minor I/O in presenza di errori ripetuti - diagnosi piu leggibile - minore rumore nei log **Costo** - medio, perche puo richiedere allineamento tra framework e convenzioni di progetto **Rischio** - medio, se si riduce troppo il dettaglio diagnostico **Priorita** - media ### 4. Consolidare configurazioni di rendering ricorrenti **Problema** La documentazione mostra che la stessa action puo preparare piu varianti di rendering. Questo e corretto, ma puo introdurre duplicazione di configurazioni e passaggi ripetuti. **Proposta** - estrarre le configurazioni ricorrenti in helper o preset documentati - evitare ricostruzioni identiche del data provider o della configurazione griglia nella stessa request - privilegiare composizione e riuso rispetto a rami duplicati **Impatto atteso** - minor costo CPU per request - codice piu lineare - minore rischio di divergenza tra viste simili **Costo** - medio **Rischio** - medio-basso **Priorita** - media ## Backlog prioritizzato ### Quick win | Priorita | Proposta | Impatto | Costo | Rischio | |---|---|---|---|---| | P1 | Checklist tecnica per griglie avanzate e filtri | Alto | Basso | Basso | | P1 | Standard operativo per sessione e browser-back | Alto | Basso | Basso | ### Miglioramenti medi | Priorita | Proposta | Impatto | Costo | Rischio | |---|---|---|---|---| | P2 | Ridurre il costo del logging eccezioni ripetute | Medio-alto | Medio | Medio | | P2 | Consolidare configurazioni di rendering ricorrenti | Medio | Medio | Medio-basso | ### Interventi strutturali | Priorita | Proposta | Impatto | Costo | Rischio | |---|---|---|---|---| | P3 | Introdurre una baseline misurabile per griglie, sessione ed error handling | Alto | Medio | Basso | | P3 | Rendere il registry performance un artefatto vivo da aggiornare con nuove evidenze | Medio | Medio | Basso | ## Piano di validazione post-intervento 1. Misurare il tempo di rendering prima e dopo su una griglia complessa. 2. Verificare il numero di richieste/refresh causati da back browser e sessione scaduta. 3. Controllare la frequenza di eccezioni ripetute e il costo di logging. 4. Confrontare il numero di configurazioni duplicate nella stessa pagina o request. 5. Validare che eventuali semplificazioni non rompano filtri avanzati, footer o comportamenti AJAX. ## Checklist verifiche eseguite - [x] Letto il prompt `09_migliorie_performance.md` - [x] Riesaminata la documentazione app gia prodotta - [x] Riesaminate le note su griglie, sessione, error handling e registry cross-app - [x] Distinte evidenze osservabili da inferenze - [x] Evitate proposte prive di impatto verificabile nel corpus locale - [x] Limitato il perimetro al repository `yii-framework-base` ## Assunzioni, limiti e punti da validare con il team - Non esistono nel corpus locale metriche runtime di produzione, quindi la baseline e documentale. - Le ottimizzazioni proposte sono concentrate sulle aree gia descritte nel repo e non su ipotesi di business non documentate. - Il costo reale di rendering e logging va confermato con misure applicative, non solo con la documentazione. - Va validato con il team se alcune griglie o flussi sono piu critici di altri e meritano priorita diversa. - Va confermato se esistono punti di logging o sessione gia ottimizzati altrove ma non ancora documentati qui. ## File modificati - `analisi/09_migliorie_performance.md` - `analisi/performance_registry.md` ## Scopo Descrivere obiettivo operativo e risultato atteso. ## Perimetro Definire modulo, confini funzionali e prerequisiti. ## Flusso 1. Input e contesto. 2. Esecuzione del processo. 3. Output e verifica. ## Componenti - Controller/servizi. - Model e tabelle. - Job/log/integrazioni correlate. ## Failure mode - Errori ricorrenti. - Cause tipiche. - Segnali diagnostici. ## Checklist - Pre: prerequisiti validati. - Post: outcome e coerenza dati verificati. ## Criteri di accettazione Contenuto azionabile, verificabile e coerente con il codice.