Prestazioni e profiling
Le app veloci trattengono gli utenti — e su larga scala le prestazioni sono un problema di architettura, non un ripensamento. Questo corso ti insegna a misurare, analizzare e ottimizzare le applicazioni Wisej.NET perché le sessioni restino rapide sotto carico. Imparerai a trovare i colli di bottiglia con un vero profiling, a capire dove vanno il tempo del server e la memoria in ogni sessione, e ad applicare le tecniche che mantengono reattiva un'app Wisej.NET molto usata su larga scala.
Misura, analizza e ottimizza le app Wisej.NET — trova i colli di bottiglia e mantieni veloci le sessioni su larga scala.
- Livello: Advanced
- Durata: 9 ore
- Moduli: 7
Programma
Modulo 1: Il modello delle prestazioni di Wisej.NET
Modulo 1 di Prestazioni e profiling — misura, analizza e ottimizza le app Wisej.NET perché le sessioni restino veloci su larga scala. Leggi la guida della lezione e la guida al lab / esame, guarda la videoguida sul modello delle prestazioni, supera la verifica delle conoscenze e completa il lab pratico in WisejPerfLab.
- LetturaGuida della lezione · 14 min
Il ciclo di richieste ed eventi, il push via WebSocket, lo stato di sessione come unità di capacità, i cinque contenitori di costo e la disciplina scenario-più-baseline con cui si confronta ogni traccia successiva. Che cosa significa per uno sviluppatore Wisej.NET che diagnostica i colli di bottiglia in un'app in produzione — e come affrontare questo modulo.
- LetturaGuida al lab / esame · 10 min
Che cosa costruirai nel lab pratico, l'approccio suggerito e i deliverable richiesti.
- Lezione videoDove va davvero il tempo in una sessione Wisej.NET · 14 min
Dove va davvero il tempo in una sessione Wisej.NET — una videoguida del Modulo 1, costruita passo dopo passo in WisejPerfLab. Parte direttamente qui nel player.
Trascrizione della narrazione
Inizia con l'aggiornamento lento in WisejPerfLab. Il tempo trascorso stabilisce il problema, ma un'indagine utile deve spiegare dove è andato a finire quel tempo prima di scegliere una soluzione.
Segui il clic dal browser al server e viceversa. I controlli del server consumano memoria, mentre la loro modifica crea anche lavoro di elaborazione, trasporto e rendering.
Calcolo separato, attesa, memoria, accesso ai dati e aggiornamenti trasmessi. Questa classificazione determina quale misurazione può spiegare il ritardo; una traccia del processore non può rivelare tutti i costi del browser.
Aggiungi uno ScenarioProbe attorno all'azione. Un ambito usa e getta registra il completamento di ogni percorso di uscita e i campi di durata denominata e conteggio delle righe rendono comparabili le esecuzioni separate.
Contare gli oggetti conservati da ciascuna sessione, inclusi i controlli e le righe memorizzate nella cache. Una piccola perdita diventa un problema di capacità quando ogni sessione connessa conserva un'altra copia.
Misura insieme la query e le modifiche dell'interfaccia. In caso contrario, la durata registrata omette parte del lavoro effettivamente atteso dall'utente durante l'aggiornamento.
Registra separatamente l'aggiornamento, la ricerca e l'espansione dell'albero sull'applicazione riscaldata. Questi tempi di sessione singola sono punti di riferimento; non spiegano ancora il comportamento in caso di uso simultaneo.
Annota la compilazione, il set di dati e il riscaldamento insieme a ciascuna linea di base. Assegnare a ogni scenario un obiettivo e uno strumento di misurazione in modo che i miglioramenti successivi possano essere valutati in modo coerente.
Strumentalizza tutti e tre gli scenari di laboratorio prima di ottimizzarli. La linea di base e il budget diventano le prove utilizzate dai moduli successivi per distinguere un miglioramento da un cambiamento temporale inspiegabile.
- LetturaEsercizio di coding con l'IA · 20 min
Costruisci il progetto OpsMonitor di questo modulo con ChatGPT o Claude partendo da un prompt già pronto che indirizza il modello alla specifica del modulo, poi rivedi, esegui ed estendi quello che ti restituisce — confrontandolo anche con la nostra build di riferimento su GitHub.
- VerificaVerifica delle conoscenze — Modulo 1 · 10 min · Soglia di superamento 80%
- Laboratorio praticoLab — Scenari, sonde e il primo budget · 45 min
Obiettivo: Crea la soluzione WisejPerfLab con una dashboard di supporto, una griglia dei ticket e un albero dei clienti alimentati da dati di seed, poi rendila misurabile. Aggiungi un servizio ScenarioProbe che racchiude uno scenario in uno scope con Stopwatch e scrive log PERF strutturati di inizio/fine con il nome dello scenario, l'azione dell'utente, i millisecondi trascorsi e il numero di righe, registralo nell'host builder e racchiudici tre scenari: aggiornamento della dashboard, ricerca dei ticket ed espansione dell'albero dei clienti. Esegui ogni scenario una volta di riscaldamento, poi registra la baseline e scrivi un budget di prestazioni che indica ambiente, configurazione di build, dimensione del dataset e una soglia di accettazione per ogni scenario. Deliverable: soluzione WisejPerfLab con dashboard, griglia dei ticket e albero dei clienti su dati di seed; servizio ScenarioProbe che scrive log PERF strutturati di inizio/fine con millisecondi trascorsi e numero di righe; tre scenari strumentati: aggiornamento della dashboard, ricerca dei ticket ed espansione dell'albero dei clienti; nota di baseline che registra ambiente, configurazione di build, dimensione del dataset e procedura di riscaldamento; budget di prestazioni con una soglia di accettazione per scenario e lo strumento che dimostrerebbe ciascuna.
Modulo 2: Flusso di profiling in Visual Studio per Wisej.NET
Modulo 2 di Prestazioni e profiling — misura, analizza e ottimizza le app Wisej.NET perché le sessioni restino veloci su larga scala. Leggi la guida della lezione e la guida al lab / esame, guarda la videoguida sul flusso di profiling, supera la verifica delle conoscenze e completa il lab pratico in WisejPerfLab.
- LetturaGuida della lezione · 14 min
Eseguire nel modo giusto il Performance Profiler su un'app Wisej.NET: build Release senza debugger, la matrice di scelta degli strumenti, l'aggancio a dotnet o w3wp e la lettura della timeline di riepilogo, dell'albero delle chiamate, del percorso critico e delle viste caller/callee. Che cosa significa per uno sviluppatore Wisej.NET che diagnostica i colli di bottiglia in un'app in produzione — e come affrontare questo modulo.
- LetturaGuida al lab / esame · 10 min
Che cosa costruirai nel lab pratico, l'approccio suggerito e i deliverable richiesti.
- Lezione videoRaccogli una traccia che dimostri davvero qualcosa · 14 min
Raccogli una traccia che dimostri davvero qualcosa — una videoguida del Modulo 2, costruita passo dopo passo in WisejPerfLab. Parte direttamente qui nel player.
Trascrizione della narrazione
Un'acquisizione di profilazione è utile solo quando rappresenta un esperimento noto. Mantieni espliciti la build, lo scenario e lo strumento selezionato in modo che un altro sviluppatore possa interpretare il risultato.
Riscalda una build di rilascio, registra un'azione, quindi interrompi. Escludere l'avvio e l'attività non correlata impedisce che i relativi costi vengano confusi con il comportamento che stai indagando.
Scegli il profiler dal costo sospetto. Il campionamento spiega il calcolo; l'attesa, le allocazioni, l'accesso al database e le operazioni sui file necessitano di visualizzazioni diverse per esporre il loro contributo.
Preparare la nota di traccia prima della registrazione. Hosting, set di dati, browser e budget spiegano le condizioni alla base dei campioni e rendono l'acquisizione riproducibile in seguito.
Allega al processo che effettivamente serve l'applicazione. Confermarne l'identificatore, soprattutto quando più siti o pool di applicazioni creano processi con lo stesso nome eseguibile.
Selezionare l'intervallo di clic prima di seguire il percorso attivo. Il tempo inclusivo elevato nel codice di spedizione differisce dal tempo autonomo in FormatRow, dove avviene effettivamente il lavoro del processore.
Ripeti lo stesso flusso di lavoro ordinato per ogni acquisizione. Su Internet Information Services, la selezione del processo di lavoro sbagliato invalida le misurazioni prima ancora che l'analisi abbia inizio.
Confronta il campionamento con la strumentazione per lo stesso aggiornamento. Le chiamate al formattatore spiegano il calcolo, mentre l'attesa separata mostra perché un'indagine esclusivamente sul processore lascerebbe parte del ritardo inspiegabile.
Salva entrambe le tracce di aggiornamento con le relative note. Indica una causa sospetta e le prove che potrebbero smentirla, in modo che la modifica successiva metta alla prova un'ipotesi anziché un'ipotesi.
- LetturaEsercizio di coding con l'IA · 20 min
Costruisci il progetto OpsMonitor di questo modulo con ChatGPT o Claude partendo da un prompt già pronto che indirizza il modello alla specifica del modulo, poi rivedi, esegui ed estendi quello che ti restituisce — confrontandolo anche con la nostra build di riferimento su GitHub.
- VerificaVerifica delle conoscenze — Modulo 2 · 10 min · Soglia di superamento 80%
- Laboratorio praticoLab — Utilizzo della CPU e tracce di strumentazione · 45 min
Obiettivo: Esegui correttamente il profiling del lento aggiornamento della dashboard di WisejPerfLab. Passa a Release, riscalda l'app una volta, poi raccogli con Alt+F2 una traccia CPU Usage di quell'unico scenario, restringi la timeline di riepilogo al solo clic e usa Show Hot Path per trovare il percorso principale sotto i frame di dispatch di Wisej.NET. Raccogli una seconda traccia Instrumentation dello stesso scenario per ottenere numero di chiamate e tempo reale, stabilisci dalle due tracce se il costo è CPU dentro il tuo codice o tempo passato in attesa, e salva entrambi i file .diagsession con un nome che riporta modulo, scenario, build, dataset e timestamp. Deliverable: traccia CPU Usage in Release dello scenario di aggiornamento della dashboard, con la timeline ristretta al clic; screenshot del percorso critico che indica la principale funzione applicativa e la sua CPU propria rispetto a quella totale; traccia Instrumentation dello stesso scenario con numero di chiamate e tempo reale; nota della traccia che indica corso, modulo, scenario, build, hosting, strumento, browser e budget atteso; un paragrafo sulla causa radice sospetta che dice verso quale dei cinque contenitori di costo puntano le prove.
Modulo 3: Percorsi critici della CPU, gestori di eventi e lavoro di UI lato server
Modulo 3 di Prestazioni e profiling — misura, analizza e ottimizza le app Wisej.NET perché le sessioni restino veloci su larga scala. Leggi la guida della lezione e la guida al lab / esame, guarda la videoguida sui percorsi critici della CPU, supera la verifica delle conoscenze e completa il lab pratico in WisejPerfLab.
- LetturaGuida della lezione · 14 min
Codice di UI lato server costoso in gestori di eventi, timer, aggiornamenti di layout e logica di formattazione, e i pattern di caching, batching e view model che rendono di nuovo economico un clic. Che cosa significa per uno sviluppatore Wisej.NET che diagnostica i colli di bottiglia in un'app in produzione — e come affrontare questo modulo.
- LetturaGuida al lab / esame · 10 min
Che cosa costruirai nel lab pratico, l'approccio suggerito e i deliverable richiesti.
- Lezione videoRendi economico il pulsante Refresh · 14 min
Rendi economico il pulsante Refresh — una videoguida del Modulo 3, costruita passo dopo passo in WisejPerfLab. Parte direttamente qui nel player.
Trascrizione della narrazione
Parti dalle operazioni che le misurazioni hanno indicato come costose: la formattazione ripetuta delle righe e la ricostruzione del pannello degli indicatori. La frequenza e la sequenza delle chiamate mostrano quale lavoro eliminare dal percorso avviato dal clic dell’utente.
Cerca operazioni di per sé ragionevoli che vengono ripetute negli eventi più frequenti. Formattazione, conversione delle immagini, reflection e ordinamento diventano costosi quando il punto in cui vengono eseguiti ne moltiplica il lavoro.
Distingui un numero eccessivo di chiamate da un costo eccessivo per singola chiamata. Ridurre la frequenza risolve il primo problema; rendere meno costosa ogni operazione risolve il secondo.
Esamina il gestore prima di modificarlo. Ricostruire i controlli e formattare tutte le righe introducono costi diversi, quindi una semplice riscrittura formale lascerebbe intatto il comportamento che causa il problema.
Precalcola i risultati stabili, raggruppa le modifiche correlate e aggiorna i controlli esistenti. Conserva nella cache soltanto dati immutabili: spostare un calcolo in un metodo asincrono non elimina quel calcolo.
Sposta la formattazione in GetSnapshot e lascia al gestore l’assegnazione dei risultati. Mantieni lo stesso ambito di misurazione e ripristina il pulsante in finally, così anche un errore lascia l’interfaccia utilizzabile.
Ripeti la stessa acquisizione e controlla le chiamate, non soltanto il tempo trascorso. La scomparsa del formattatore dal percorso più eseguito dimostra che il lavoro previsto è stato effettivamente eliminato.
L’aggiornamento rispetta ora il tempo previsto, ma documenta il compromesso introdotto: lo snapshot può contenere dati non più aggiornati. L’attesa individuata separatamente rimane un problema diverso, da analizzare in seguito.
Nel laboratorio sostituisci entrambi i comportamenti costosi e presenta misurazioni confrontabili. Le prove devono collegare lo snapshot e il gestore con aggiornamenti raggruppati alla variazione del numero di chiamate.
- LetturaEsercizio di coding con l'IA · 20 min
Costruisci il progetto OpsMonitor di questo modulo con ChatGPT o Claude partendo da un prompt già pronto che indirizza il modello alla specifica del modulo, poi rivedi, esegui ed estendi quello che ti restituisce — confrontandolo anche con la nostra build di riferimento su GitHub.
- VerificaVerifica delle conoscenze — Modulo 3 · 10 min · Soglia di superamento 80%
- Laboratorio praticoLab — Dal percorso critico al view model in cache · 45 min
Obiettivo: Sistema il pulsante Refresh di WisejPerfLab. Esegui il profiling dello scenario di aggiornamento con CPU Usage, apri il flame graph e Show Hot Path e individua i due colpevoli: un formatter che gira per ogni cella a ogni aggiornamento e una ricostruzione di controlli che ricrea ogni volta il pannello dei KPI. Sostituiscili con un view model DashboardSnapshot le cui stringhe di visualizzazione vengono calcolate una sola volta nel servizio, modifica le label e la sorgente dati del grafico una sola volta dentro uno scope della sonda invece che riga per riga, e tieni il pulsante disabilitato in un try/finally mentre il lavoro è in corso. Riesegui lo scenario identico e cattura il nuovo percorso critico. Deliverable: traccia CPU Usage prima della modifica che indica il formatter ripetuto e la ricostruzione dei controlli con la loro CPU totale e propria; view model DashboardSnapshot con le stringhe di visualizzazione precalcolate nel servizio; gestore di aggiornamento a batch che modifica i controlli una sola volta dentro uno scope della sonda, con riabilitazione in try/finally; traccia CPU Usage dopo la modifica dello scenario identico con il nuovo percorso critico; tabella prima/dopo di CPU totale, funzione principale e numero di chiamate, più il rischio residuo.
Modulo 4: Memoria, allocazioni e perdite di sessione
Modulo 4 di Prestazioni e profiling — misura, analizza e ottimizza le app Wisej.NET perché le sessioni restino veloci su larga scala. Leggi la guida della lezione e la guida al lab / esame, guarda la videoguida su memoria e perdite, supera la verifica delle conoscenze e completa il lab pratico in WisejPerfLab.
- LetturaGuida della lezione · 14 min
Pressione sulle allocazioni contro memoria trattenuta, il flusso di confronto tra snapshot, i pattern di ritenzione di Wisej.NET (eventi statici, timer, task in background, cache globali) e la checklist di rilascio che dimostra che una perdita è sparita. Che cosa significa per uno sviluppatore Wisej.NET che diagnostica i colli di bottiglia in un'app in produzione — e come affrontare questo modulo.
- LetturaGuida al lab / esame · 10 min
Che cosa costruirai nel lab pratico, l'approccio suggerito e i deliverable richiesti.
- Lezione videoTrova il form che non se ne è mai andato · 14 min
Trova il form che non se ne è mai andato — una videoguida del Modulo 4, costruita passo dopo passo in WisejPerfLab. Parte direttamente qui nel player.
Trascrizione della narrazione
Un aggiornamento rapido non dimostra un utilizzo corretto della memoria. L'apertura e la chiusura ripetute di un modulo rivela se gli oggetti scompaiono al termine della loro durata visibile.
Misurare l'allocazione e la fidelizzazione separatamente. Gli oggetti temporanei creano un lavoro di raccolta, mentre gli oggetti che rimangono raggiungibili consumano capacità finché sopravvivono i loro riferimenti.
Scatta un'istantanea di base, ripeti cinquanta cicli, torna al minimo e confronta. La ripetizione rende la crescita persistente più facile da distinguere dalle ordinarie allocazioni temporanee.
Seguire i riferimenti dai moduli sopravvissuti. Un evento statico e un callback del timer mantengono entrambi il modulo raggiungibile anche dopo la chiusura della finestra.
Esamina eventi, timer, attività, cache, campi e associazioni per riferimenti con una durata più lunga. La pulizia deve rilasciare la proprietà quando la sessione o il modulo non ne hanno più bisogno.
Affianca la disiscrizione e lo smaltimento alla gestione della durata del modulo. Il controllo di IsDisposed impedisce il lavoro non valido, ma non rilascia il riferimento mantenendo vivo quel modulo.
Confronta le allocazioni di ricerca dopo aver proiettato i dati una volta. Il volume ridotto delle stringhe dimostra un lavoro meno ripetuto durante i ridisegni, indipendentemente dal fatto che qualche oggetto sia trapelato.
Ripetere gli stessi cinquanta cicli dopo la pulizia. Conferma che il conteggio dei moduli conservati e il percorso di riferimento scompaiono; entrambi i controlli da soli lasciano la spiegazione incompleta.
Presentare le prove di allocazione e conservazione separatamente. Utilizzare la cifra di memoria per sessione risultante per stabilire un budget di capacità che i controlli di distribuzione successivi possono applicare.
- LetturaEsercizio di coding con l'IA · 20 min
Costruisci il progetto OpsMonitor di questo modulo con ChatGPT o Claude partendo da un prompt già pronto che indirizza il modello alla specifica del modulo, poi rivedi, esegui ed estendi quello che ti restituisce — confrontandolo anche con la nostra build di riferimento su GitHub.
- VerificaVerifica delle conoscenze — Modulo 4 · 10 min · Soglia di superamento 80%
- Laboratorio praticoLab — Pressione sulle allocazioni e radici di ritenzione · 45 min
Obiettivo: Affronta entrambe le metà del problema di memoria in WisejPerfLab. Esegui lo scenario di ricerca dei ticket sotto .NET Object Allocation e trova i modelli di riga e le stringhe allocati a ogni ricerca, poi riducili proiettando una volta sola invece di ricostruire gli oggetti a ogni ridisegno. Poi cattura uno snapshot di Memory Usage dopo il riscaldamento, apri e chiudi il form di dettaglio del ticket cinquanta volte, cattura un secondo snapshot e confrontali: i form trattenuti hanno come radice una sottoscrizione statica a GlobalTicketBus.TicketChanged e un timer di aggiornamento mai fermato. Annulla la sottoscrizione e ferma entrambi in un override di Dispose, azzera la sorgente dati del BindingSource, poi riesegui lo scenario di apertura/chiusura e mostra che l'heap trattenuto torna vicino allo snapshot A. Deliverable: traccia delle allocazioni che indica il tipo che alloca di più e il percorso di chiamata per lo scenario di ricerca, prima e dopo; confronto tra gli snapshot A/B che mostra il numero di istanze trattenute del form di dettaglio prima della correzione; screenshot del percorso fino alla radice che identifica la sottoscrizione all'evento statico e il timer ancora attivo; override di Dispose che annulla la sottoscrizione all'evento statico, ferma e rilascia il timer e azzera il binding; budget di memoria per sessione e una checklist di rilascio, con lo snapshot finale che dimostra che il percorso di ritenzione è sparito.
Modulo 5: Controlli dati, payload del browser e grandi superfici di UI
Modulo 5 di Prestazioni e profiling — misura, analizza e ottimizza le app Wisej.NET perché le sessioni restino veloci su larga scala. Leggi la guida della lezione e la guida al lab / esame, guarda la videoguida sulle grandi superfici di UI, supera la verifica delle conoscenze e completa il lab pratico in WisejPerfLab.
- LetturaGuida della lezione · 14 min
Griglie, liste, alberi e repeater su larga scala: virtual mode, paginazione, proiezione e caricamento lazy dei nodi, e l'uso delle prove di rete del browser accanto a quelle di Visual Studio per dimensionare il payload degli aggiornamenti. Che cosa significa per uno sviluppatore Wisej.NET che diagnostica i colli di bottiglia in un'app in produzione — e come affrontare questo modulo.
- LetturaGuida al lab / esame · 10 min
Che cosa costruirai nel lab pratico, l'approccio suggerito e i deliverable richiesti.
- Lezione videoCinquantamila righe senza cinquantamila controlli · 14 min
Cinquantamila righe senza cinquantamila controlli — una videoguida del Modulo 5, costruita passo dopo passo in WisejPerfLab. Parte direttamente qui nel player.
Trascrizione della narrazione
Modulo cinque. Griglie e alberi di grandi dimensioni possono rallentare un'applicazione prima che l'utente faccia qualsiasi cosa. Ridurremo i dati e i controlli caricati contemporaneamente, quindi misureremo l'effetto sia sul server che sul browser.
Una griglia grande ha costi in quattro posti. Il server memorizza gli oggetti e prepara l'aggiornamento. La rete lo trasporta e il browser lo visualizza. Misurare solo le prestazioni del server non permetterà di risolvere parte del problema.
Innanzitutto, proietta ciascun record in un oggetto più piccolo contenente i campi necessari allo schermo. Quindi utilizzare la modalità virtuale per evitare di mantenere ogni riga in memoria. Queste modifiche risolvono diverse parti del problema, quindi applicale entrambe.
Imposta RowCount da una query di conteggio. Quando CellValueNeeded richiede un valore, leggerlo dalla proiezione paginata. Evita una query sul database per ogni cella e mantieni la formattazione fuori da questo gestore.
Applicare lo stesso principio ad altri controlli. Carica gli alberi secondari quando il loro genitore si espande, virtualizza lunghi elenchi, mantieni semplici i modelli di ripetitore e aggiorna solo le righe del dashboard che sono cambiate.
Mentre il nodo dell'albero è compresso, mantieni un conteggio e un figlio segnaposto. Il segnaposto mantiene il controllo di espansione. Crea i nodi figlio reali solo quando l'utente apre quel ramo.
Confronta le misure del server. La griglia contiene quaranta righe di oggetti invece di cinquantamila. La memoria scende da 186 a nove megabyte e il tempo di elaborazione scende da 1.410 a 95 millisecondi. Successivamente, controlla cosa è cambiato nel browser.
Ora controlla il traffico del browser. L'aggiornamento della griglia si riduce da 4,8 megabyte a 96 kilobyte. Sei aggiornamenti più piccoli servono per lo scorrimento successivo. Riporta sia il numero che la dimensione delle richieste in modo che le misurazioni mostrino il costo completo.
Per il laboratorio cinque, proietta e virtualizza la griglia, quindi carica i rami degli alberi su richiesta. Utilizzare Visual Studio per misurare il server e il pannello di rete per misurare il traffico del browser. Le tue prove dovrebbero coprire entrambi.
- LetturaEsercizio di coding con l'IA · 20 min
Costruisci il progetto OpsMonitor di questo modulo con ChatGPT o Claude partendo da un prompt già pronto che indirizza il modello alla specifica del modulo, poi rivedi, esegui ed estendi quello che ti restituisce — confrontandolo anche con la nostra build di riferimento su GitHub.
- VerificaVerifica delle conoscenze — Modulo 5 · 10 min · Soglia di superamento 80%
- Laboratorio praticoLab — Griglia virtuale e albero lazy · 45 min
Obiettivo: Riduci le due superfici più grandi di WisejPerfLab. La griglia dei ticket collega 50.000 entità complete con le proprietà di navigazione: sostituisci il binding con una proiezione TicketGridRow delle sole colonne visibili, imposta VirtualMode e RowCount e fornisci le celle da un gestore CellValueNeeded appoggiato a un servizio di query paginate. L'albero dei clienti costruisce tutti i nodi all'avvio: carica invece i figli all'espansione, usando un segnaposto con il conteggio per i rami chiusi. Misura ogni schermata prima e dopo con CPU Usage e .NET Object Allocation sul server e con il pannello di rete del browser per la dimensione del payload degli aggiornamenti. Deliverable: proiezione TicketGridRow collegata al posto delle entità complete, con le sole colonne visualizzate; griglia in virtual mode con RowCount e un gestore CellValueNeeded servito da un servizio di query paginate; albero dei clienti che carica i nodi figli all'espansione con un segnaposto con il conteggio per i rami chiusi; numeri di CPU e allocazioni prima/dopo per gli scenari di caricamento della griglia ed espansione dell'albero; prove di rete del browser che confrontano la dimensione del payload degli aggiornamenti prima e dopo, con l'avvertenza sulla compressione.
Modulo 6: Database, I/O su file, async e attese esterne
Modulo 6 di Prestazioni e profiling — misura, analizza e ottimizza le app Wisej.NET perché le sessioni restino veloci su larga scala. Leggi la guida della lezione e la guida al lab / esame, guarda la videoguida su database e async, supera la verifica delle conoscenze e completa il lab pratico in WisejPerfLab.
- LetturaGuida della lezione · 14 min
La latenza che CPU Usage non vede: lo strumento Database per i tempi delle query e i pattern N+1, File I/O per il lavoro di importazione ed esportazione e .NET Async per le catene bloccate o involontariamente sequenziali. Che cosa significa per uno sviluppatore Wisej.NET che diagnostica i colli di bottiglia in un'app in produzione — e come affrontare questo modulo.
- LetturaGuida al lab / esame · 10 min
Che cosa costruirai nel lab pratico, l'approccio suggerito e i deliverable richiesti.
- Lezione videoCPU bassa, schermata lenta: profiling dell'attesa · 14 min
CPU bassa, schermata lenta: profiling dell'attesa — una videoguida del Modulo 6, costruita passo dopo passo in WisejPerfLab. Parte direttamente qui nel player.
Trascrizione della narrazione
Un processore silenzioso può accompagnare un'applicazione lenta. Utilizzare la traccia di aggiornamento precedente per esaminare l'attesa invece di provare a ottimizzare il calcolo che non spiega il ritardo.
Attribuire il tempo mancante alle operazioni del database, all'accesso ai file e ai thread bloccati. Queste attese richiedono misurazioni proprie perché i campioni del processore descrivono principalmente il lavoro svolto durante l'esecuzione.
Controlla come lo schermo ottiene le sue righe. Ricerche ripetute e campi in eccesso aggiungono lavoro evitabile al database; proiettare insieme i campi richiesti può rimuovere diversi problemi contemporaneamente.
Unisci il nome del cliente alla query e seleziona solo i campi visualizzati. Ordina e impagina i risultati, utilizzando letture non tracciate quando lo schermo non necessita del rilevamento delle modifiche.
Attendere le operazioni di input e output in modo che una richiesta in attesa non occupi inutilmente un thread. Ciò migliora la disponibilità delle risorse; non rende più veloce il database o il disco sottostante.
Rimuovi il blocco dell'accesso ai risultati e trasmetti in streaming l'esportazione invece di emettere molte piccole scritture. Invia i progressi a intervalli significativi in modo che il feedback non diventi un'altra fonte di sovraccarico.
Confronta i conteggi delle query dopo la modifica. Il calo da duecentouno domande a due conferma questa correzione, anche se un altro costo impedisce ancora allo scenario di rispettare il budget.
Ripeti l'esportazione con sessioni simultanee. Un blocco che sembra innocuo per un utente può esaurire i thread disponibili e ritardare schermate non correlate quando molti utenti lo eseguono insieme.
Collega ogni query alla relativa azione dell'interfaccia, quindi confronta il prima e il dopo. Spiegare sia il lavoro del database rimosso sia il modo in cui l'esportazione evita di bloccare il percorso dei clic.
- LetturaEsercizio di coding con l'IA · 20 min
Costruisci il progetto OpsMonitor di questo modulo con ChatGPT o Claude partendo da un prompt già pronto che indirizza il modello alla specifica del modulo, poi rivedi, esegui ed estendi quello che ti restituisce — confrontandolo anche con la nostra build di riferimento su GitHub.
- VerificaVerifica delle conoscenze — Modulo 6 · 10 min · Soglia di superamento 80%
- Laboratorio praticoLab — Tracce delle query e l'esportazione bloccata · 45 min
Obiettivo: Esegui il profiling dei due scenari dominati dalle attese in WisejPerfLab. Esegui la ricerca dei ticket sotto lo strumento Database e abbina ogni query all'azione di UI: il caricamento della griglia lancia una query sul cliente per ogni riga visualizzata e la query dei dettagli preleva grandi colonne di testo che nessuno mostra. Sostituisci entrambe con un'unica query di proiezione no-tracking che seleziona solo le colonne della griglia e pagina il risultato. Poi esegui l'esportazione CSV sotto File I/O e .NET Async, trova la chiamata bloccante .Result nel gestore del clic e le piccole scritture ripetute, e sposta la generazione in un flusso in background con Application.StartTask che scrive il file in streaming e segnala l'avanzamento in modo limitato invece di inviare ogni singolo passo. Deliverable: traccia Database che abbina le query alle azioni di UI, con il numero di query N+1 prima della correzione; un'unica query di proiezione no-tracking con paginazione al posto delle query per riga e di quelle che prelevano troppo; prove File I/O e .NET Async per l'esportazione, che indicano la chiamata bloccante e il pattern di scrittura; esportazione spostata in un task in background che scrive in streaming e invia l'avanzamento solo nei passi significativi; numero di query, durata delle query e tempo reale dell'esportazione prima/dopo, con i rischi residui.
Modulo 7: Scalabilità, health check, bilanciamento del carico e ottimizzazione finale
Modulo 7 di Prestazioni e profiling — misura, analizza e ottimizza le app Wisej.NET perché le sessioni restino veloci su larga scala. Leggi la guida della lezione e la guida al lab / esame, guarda la videoguida su scalabilità e health check, supera la verifica delle conoscenze e completa il lab pratico in WisejPerfLab.
- LetturaGuida della lezione · 14 min
Trasformare le misure in un modello di capacità, le soglie di HealthCheck.json, l'affinità di sessione e il bilanciamento del carico compatibile con WebSocket, i contatori di produzione e il report finale sulle prestazioni che giustifica ogni modifica. Che cosa significa per uno sviluppatore Wisej.NET che diagnostica i colli di bottiglia in un'app in produzione — e come affrontare questo modulo.
- LetturaGuida al lab / esame · 10 min
Che cosa costruirai nel lab pratico, l'approccio suggerito e i deliverable richiesti.
- Lezione videoDa una traccia locale a un modello di capacità · 14 min
Da una traccia locale a un modello di capacità — una videoguida del Modulo 7, costruita passo dopo passo in WisejPerfLab. Parte direttamente qui nel player.
Trascrizione della narrazione
Tradurre i risultati della profilazione in limiti operativi. Un'applicazione più veloce necessita comunque di una capacità di sessione difendibile e di un piano per allontanare i nuovi utenti da un server completo.
Moltiplicare la memoria della sessione misurata per il conteggio delle sessioni proposte e confrontarla con la memoria utilizzabile. Mantieni margine perché le sessioni inattive non descrivono ogni picco di allocazione.
Preserva l'affinità di sessione nell'intera distribuzione e consente gli aggiornamenti WebSocket tramite proxy. I controlli stateful necessitano del server corretto e gli aggiornamenti live necessitano di un percorso di trasporto ininterrotto.
Imposta soglie di integrità in base alla capacità misurata anziché a ipotesi convenienti. La risposta non integra e la guida ai nuovi tentativi forniscono all'infrastruttura un segnale quando l'istanza dovrebbe smettere di ricevere nuove sessioni.
Monitorare il segnale che corrisponde a ciascun problema corretto. Le durate degli scenari, le dimensioni dell'heap gestito e le code del pool di thread rivelano regressioni diverse e non devono essere trattate come intercambiabili.
Scrivi un rapporto che colleghi lo scenario originale alla sua causa, correzione e prova. Includere rischi e controlli operativi in modo che un collega possa verificare il miglioramento dopo l'implementazione.
Guarda cosa succede quando l'istanza A raggiunge la capacità massima. Il nuovo traffico si sposta verso l'istanza B mentre le sessioni stabilite continuano, separando il controllo dell'ammissione dall'interruzione degli utenti esistenti.
Confronta ogni scenario con il suo budget originale. Mantenere l'esportazione contrassegnata come rischio perché un obiettivo assente e test di concorrenza limitati non possono supportare una richiesta di successo.
Fornisci insieme il calcolo della capacità, la configurazione dell'integrità, le note di distribuzione e il report riproducibile. Le operazioni necessitano sia dei limiti scelti che delle prove che spiegano perché tali limiti sono appropriati.
- LetturaEsercizio di coding con l'IA · 20 min
Costruisci il progetto OpsMonitor di questo modulo con ChatGPT o Claude partendo da un prompt già pronto che indirizza il modello alla specifica del modulo, poi rivedi, esegui ed estendi quello che ti restituisce — confrontandolo anche con la nostra build di riferimento su GitHub.
- VerificaVerifica delle conoscenze — Modulo 7 · 10 min · Soglia di superamento 80%
- Laboratorio praticoLab — Modello di capacità e report del capstone · 45 min
Obiettivo: Consegna il capstone di WisejPerfLab. Ricava un modello di capacità dalle tue misure: memoria trattenuta per sessione inattiva, CPU per scenario comune, concorrenza di picco prevista e il margine che tieni. Scrivi un HealthCheck.json i cui maxSessions, maxMemory e maxCPU derivano da quei numeri e spiega ogni soglia, restituendo 503 con un retry-after così che un load balancer indirizzi altrove i nuovi utenti mentre le sessioni esistenti continuano a funzionare. Scrivi le note di deployment per due istanze dietro un load balancer con affinità di sessione e supporto WebSocket, e componi il report finale: scenari, ambiente, prove di baseline, cause radice, modifiche, prove successive, rischi residui e i contatori di produzione che mostreranno se una regressione ritorna. Deliverable: modello di capacità che ricava le sessioni per server dalla memoria per sessione e dalla CPU per scenario misurate; HealthCheck.json con maxSessions, maxMemory, maxCPU, codice di ritorno e retry-after, ogni soglia motivata; note di deployment che coprono affinità di sessione, supporto WebSocket e fallback con polling; report finale sulle prestazioni con baseline, causa radice, modifica e prove successive per ogni correzione dei moduli; piano di monitoraggio che indica i contatori, le soglie e gli alert che intercetterebbero ogni regressione.