Performances et profilage
Les applications rapides gardent leurs utilisateurs — et à grande échelle, la performance est un problème d’architecture, pas une réflexion après coup. Ce cours vous apprend à mesurer, profiler et optimiser les applications Wisej.NET pour que les sessions restent rapides sous la charge. Vous apprendrez à trouver les goulots d’étranglement grâce à un vrai profilage, à comprendre où partent le temps serveur et la mémoire de chaque session, et à appliquer les techniques qui gardent une application Wisej.NET chargée réactive à grande échelle.
Mesurez, profilez et optimisez vos applications Wisej.NET — trouvez les goulots d’étranglement et gardez des sessions rapides à grande échelle.
- Niveau: Advanced
- Durée: 9 h
- Modules: 7
Programme
Module 1: Le modèle de performance de Wisej.NET
Module 1 du cours Performances et profilage — mesurez, profilez et optimisez les applications Wisej.NET pour que les sessions restent rapides à grande échelle. Lisez le guide de la leçon et le guide du lab / de l’examen, regardez la vidéo pas à pas sur le modèle de performance, réussissez la vérification des connaissances, puis réalisez le lab pratique dans WisejPerfLab.
- LectureGuide de la leçon · 14 min
Le cycle des requêtes et des événements, le push WebSocket, l’état de session comme unité de capacité, les cinq catégories de coût et la discipline scénario-plus-référence à laquelle chaque trace ultérieure est comparée. Ce que cela signifie pour un développeur Wisej.NET qui diagnostique les goulets d’étranglement d’une application en production — et comment aborder ce module.
- LectureGuide du lab / de l’examen · 10 min
Ce que vous allez construire dans le lab pratique, l’approche suggérée et les livrables attendus.
- Leçon vidéoOù passe vraiment le temps dans une session Wisej.NET · 14 min
Où passe vraiment le temps dans une session Wisej.NET — une vidéo pas à pas du Module 1, construite étape par étape dans WisejPerfLab. Elle se lance directement ici, dans le lecteur.
Transcription de la narration
Commencez par l’actualisation lente dans WisejPerfLab. Le temps écoulé établit le problème, mais une enquête utile doit expliquer où s'est écoulé ce temps avant de choisir une solution.
Suivez le clic du navigateur vers le serveur et vice-versa. Les contrôles serveur consomment de la mémoire, tandis que leur modification crée également du travail de traitement, de transport et de rendu.
Séparez le calcul, l'attente, la mémoire, l'accès aux données et les mises à jour transmises. Cette classification détermine quelle mesure peut expliquer le retard ; une trace du processeur ne peut pas révéler tous les coûts du navigateur.
Ajoutez un ScenarioProbe autour de l'action. Une portée jetable enregistre l'achèvement de chaque chemin de sortie, et les champs de durée nommée et de nombre de lignes rendent les exécutions distinctes comparables.
Comptez les objets conservés par chaque session, y compris les contrôles et les lignes mises en cache. Une petite fuite devient un problème de capacité lorsque chaque session connectée conserve une autre copie.
Mesurez la requête et les changements d’interface ensemble. Sinon, la durée enregistrée omet une partie du travail que l'utilisateur attend réellement lors du rafraîchissement.
Enregistrez l'actualisation, la recherche et l'expansion de l'arborescence séparément sur l'application réchauffée. Ces horaires d'une seule session sont des points de référence ; ils n'expliquent pas encore le comportement en cas d'utilisation simultanée.
Notez la construction, l'ensemble de données et l'échauffement à côté de chaque ligne de base. Donnez à chaque scénario un objectif et un outil de mesure afin que les améliorations ultérieures puissent être évaluées de manière cohérente.
Instrumentez les trois scénarios de laboratoire avant de les optimiser. La référence et le budget deviennent les preuves utilisées par les modules suivants pour distinguer une amélioration d'un changement de calendrier inexpliqué.
- LectureExercice de code avec l’IA · 20 min
Construisez l’exemple OpsMonitor de ce module avec ChatGPT ou Claude à partir d’un prompt prêt à l’emploi qui oriente le modèle vers la spécification du module, puis relisez, exécutez et étendez ce qu’il vous renvoie — y compris en le comparant à notre propre solution de référence sur GitHub.
- Quiz de connaissancesVérification des connaissances — Module 1 · 10 min · Note de réussite 80%
- Lab pratiqueLab — Scénarios, sondes et premier budget · 45 min
Objectif: Créez la solution WisejPerfLab avec un tableau de bord de support, une grille de tickets et une arborescence de clients alimentés par des données de départ, puis rendez-la mesurable. Ajoutez un service ScenarioProbe qui encadre un scénario dans une portée Stopwatch et écrit des logs PERF structurés de début et de fin avec le nom du scénario, l’action de l’utilisateur, les millisecondes écoulées et le nombre de lignes, enregistrez-le dans le host builder et encadrez-y trois scénarios : l’actualisation du tableau de bord, la recherche de tickets et le déploiement d’un nœud de l’arborescence des clients. Exécutez chaque scénario une fois pour la mise en température, puis enregistrez la référence et rédigez un budget de performance qui précise l’environnement, la configuration de build, la taille du jeu de données et un seuil d’acceptation par scénario. Livrables : Solution WisejPerfLab avec un tableau de bord, une grille de tickets et une arborescence de clients sur des données de départ ; Service ScenarioProbe écrivant des logs PERF structurés de début et de fin avec les millisecondes écoulées et le nombre de lignes ; Trois scénarios instrumentés : actualisation du tableau de bord, recherche de tickets et déploiement de l’arborescence des clients ; Note de référence consignant l’environnement, la configuration de build, la taille du jeu de données et la procédure de mise en température ; Budget de performance avec un seuil d’acceptation par scénario et l’outil qui permettrait de prouver chacun.
Module 2: Workflow de profilage Visual Studio pour Wisej.NET
Module 2 du cours Performances et profilage — mesurez, profilez et optimisez les applications Wisej.NET pour que les sessions restent rapides à grande échelle. Lisez le guide de la leçon et le guide du lab / de l’examen, regardez la vidéo pas à pas sur la démarche de profilage, réussissez la vérification des connaissances, puis réalisez le lab pratique dans WisejPerfLab.
- LectureGuide de la leçon · 14 min
Exécuter correctement le Performance Profiler sur une application Wisej.NET : builds Release sans débogueur, matrice de choix des outils, attachement à dotnet ou w3wp, et lecture de la chronologie récapitulative, de l’arbre des appels, du chemin critique et des vues appelants/appelés. Ce que cela signifie pour un développeur Wisej.NET qui diagnostique les goulets d’étranglement d’une application en production — et comment aborder ce module.
- LectureGuide du lab / de l’examen · 10 min
Ce que vous allez construire dans le lab pratique, l’approche suggérée et les livrables attendus.
- Leçon vidéoCollecter une trace qui prouve vraiment quelque chose · 14 min
Collecter une trace qui prouve vraiment quelque chose — une vidéo pas à pas du Module 2, construite étape par étape dans WisejPerfLab. Elle se lance directement ici, dans le lecteur.
Transcription de la narration
Une capture de profilage n'est utile que lorsqu'elle représente une expérience connue. Gardez la construction, le scénario et l'outil sélectionné explicites afin qu'un autre développeur puisse interpréter le résultat.
Réchauffez une version Release, enregistrez une action, puis arrêtez. L'exclusion des startups et des activités non liées évite que leurs coûts soient confondus avec le comportement que vous étudiez.
Choisissez le profileur parmi le coût suspecté. L'échantillonnage explique le calcul ; l'attente, les allocations, l'accès à la base de données et les opérations sur les fichiers nécessitent des vues différentes pour exposer leur contribution.
Préparez la note de trace avant l’enregistrement. L'hébergement, l'ensemble de données, le navigateur et le budget expliquent les conditions derrière les échantillons et rendent la capture reproductible ultérieurement.
Attachez-vous au processus qui dessert réellement l'application. Confirmez son identifiant, notamment lorsque plusieurs sites ou pools d'applications créent des processus avec le même nom d'exécutable.
Sélectionnez l’intervalle de clic avant de suivre le chemin rapide. Le temps inclusif important dans le code de répartition diffère du temps propre dans FormatRow, où le travail du processeur se produit réellement.
Répétez le même flux de travail ordonné pour chaque capture. Sur Internet Information Services, la sélection du mauvais processus de travail invalide les mesures avant même que l'analyse ne commence.
Comparez l'échantillonnage avec l'instrumentation pour le même rafraîchissement. Les appels au formateur expliquent le calcul, tandis que l'attente séparée montre pourquoi une enquête portant uniquement sur le processeur laisserait une partie du retard inexpliqué.
Enregistrez les deux traces d'actualisation avec leurs notes. Énoncez une cause suspectée et des preuves qui la réfuteraient, afin que le prochain changement teste une hypothèse plutôt qu'une supposition.
- LectureExercice de code avec l’IA · 20 min
Construisez l’exemple OpsMonitor de ce module avec ChatGPT ou Claude à partir d’un prompt prêt à l’emploi qui oriente le modèle vers la spécification du module, puis relisez, exécutez et étendez ce qu’il vous renvoie — y compris en le comparant à notre propre solution de référence sur GitHub.
- Quiz de connaissancesVérification des connaissances — Module 2 · 10 min · Note de réussite 80%
- Lab pratiqueLab — Utilisation du CPU et traces d’instrumentation · 45 min
Objectif: Profilez correctement l’actualisation lente du tableau de bord de WisejPerfLab. Passez en Release, faites chauffer l’application une fois, puis collectez avec Alt+F2 une trace CPU Usage de ce seul scénario, restreignez la chronologie récapitulative au clic lui-même et utilisez Show Hot Path pour trouver le chemin principal sous les frames de dispatch de Wisej.NET. Collectez une seconde trace Instrumentation du même scénario pour obtenir le nombre d’appels et le temps réel écoulé, déterminez à partir des deux traces si le coût est du CPU dans votre code ou du temps passé à attendre, et enregistrez les deux fichiers .diagsession sous un nom qui porte le module, le scénario, le build, le jeu de données et l’horodatage. Livrables : Trace CPU Usage en Release du scénario d’actualisation du tableau de bord, chronologie restreinte au clic ; Capture d’écran du chemin critique indiquant la principale fonction applicative et son CPU propre par rapport à son CPU total ; Trace Instrumentation du même scénario avec le nombre d’appels et le temps réel écoulé ; Note de trace indiquant le cours, le module, le scénario, le build, l’hébergement, l’outil, le navigateur et le budget attendu ; Paragraphe sur la cause racine soupçonnée, indiquant vers laquelle des cinq catégories de coût pointent les éléments de preuve.
Module 3: Chemins critiques CPU, gestionnaires d’événements et travail d’UI côté serveur
Module 3 du cours Performances et profilage — mesurez, profilez et optimisez les applications Wisej.NET pour que les sessions restent rapides à grande échelle. Lisez le guide de la leçon et le guide du lab / de l’examen, regardez la vidéo pas à pas sur les chemins critiques CPU, réussissez la vérification des connaissances, puis réalisez le lab pratique dans WisejPerfLab.
- LectureGuide de la leçon · 14 min
Le code d’interface coûteux côté serveur dans les gestionnaires d’événements, les timers, les actualisations de mise en page et la logique de formatage, ainsi que les modèles de cache, de traitement groupé et de view model qui rendent un clic de nouveau peu coûteux. Ce que cela signifie pour un développeur Wisej.NET qui diagnostique les goulets d’étranglement d’une application en production — et comment aborder ce module.
- LectureGuide du lab / de l’examen · 10 min
Ce que vous allez construire dans le lab pratique, l’approche suggérée et les livrables attendus.
- Leçon vidéoRendre le bouton Refresh peu coûteux · 14 min
Rendre le bouton Refresh peu coûteux — une vidéo pas à pas du Module 3, construite étape par étape dans WisejPerfLab. Elle se lance directement ici, dans le lecteur.
Transcription de la narration
Commencez par les délinquants mesurés : formatage répété des lignes et reconstruction du panneau indicateur. Leurs modèles d'appel nous indiquent quelle tâche supprimer du clic de l'utilisateur.
Recherchez des opérations par ailleurs raisonnables répétées lors d’événements fréquents. Le formatage, la conversion d'images, la réflexion et le tri deviennent coûteux lorsque leur placement multiplie le travail.
Distinguez trop d’appels de trop de travail par appel. La réduction de la fréquence résout le premier problème ; rendre une opération moins chère équivaut à la seconde.
Inspectez le gestionnaire avant de le changer. La reconstruction des contrôles et le formatage de toutes les lignes introduisent des coûts différents, de sorte qu'une seule réécriture cosmétique laisserait le comportement sous-jacent intact.
Précalculez des résultats stables, effectuez des modifications liées aux lots et mettez à jour les contrôles existants. Mettre en cache uniquement les données immuables ; déplacer le calcul vers une méthode asynchrone ne supprime pas ce calcul.
Déplacez le formatage dans GetSnapshot et laissez le gestionnaire attribuer les résultats. Conservez l'étendue de mesure d'origine et restaurez le bouton dans finally afin que les échecs rendent l'interface utilisable.
Répétez la même capture et inspectez les appels, pas seulement le temps écoulé. La disparition du formateur du hot path démontre que le travail prévu a effectivement été supprimé.
L'actualisation respecte désormais son budget, mais documente l'obsolescence des instantanés comme un compromis. L'attente identifiée séparément reste un problème différent pour une enquête ultérieure.
Remplacez les deux modèles coûteux en laboratoire et soumettez des mesures comparables. Vos preuves doivent relier l'instantané et le gestionnaire par lots au nombre d'appels modifié.
- LectureExercice de code avec l’IA · 20 min
Construisez l’exemple OpsMonitor de ce module avec ChatGPT ou Claude à partir d’un prompt prêt à l’emploi qui oriente le modèle vers la spécification du module, puis relisez, exécutez et étendez ce qu’il vous renvoie — y compris en le comparant à notre propre solution de référence sur GitHub.
- Quiz de connaissancesVérification des connaissances — Module 3 · 10 min · Note de réussite 80%
- Lab pratiqueLab — Du chemin critique au view model en cache · 45 min
Objectif: Corrigez le bouton Refresh de WisejPerfLab. Profilez le scénario d’actualisation avec CPU Usage, ouvrez le flame graph et Show Hot Path, et identifiez les deux coupables : un formateur qui s’exécute pour chaque cellule à chaque actualisation et une reconstruction de contrôles qui recrée le panneau des KPI à chaque fois. Remplacez-les par un view model DashboardSnapshot dont les chaînes d’affichage sont calculées une seule fois dans le service, modifiez les labels et la source de données du graphique une seule fois dans une portée de sonde plutôt que ligne par ligne, et gardez le bouton désactivé dans un try/finally pendant le traitement. Réexécutez le même scénario et capturez le nouveau chemin critique. Livrables : Trace CPU Usage « avant » identifiant le formateur répété et la reconstruction de contrôles avec leur CPU total et propre ; View model DashboardSnapshot avec des chaînes d’affichage précalculées dans le service ; Gestionnaire d’actualisation groupé qui modifie les contrôles une seule fois dans une portée de sonde, avec réactivation dans un try/finally ; Trace CPU Usage « après » du même scénario avec le nouveau chemin critique ; Tableau avant/après du CPU total, de la fonction principale et du nombre d’appels, avec le risque restant.
Module 4: Mémoire, allocations et fuites de session
Module 4 du cours Performances et profilage — mesurez, profilez et optimisez les applications Wisej.NET pour que les sessions restent rapides à grande échelle. Lisez le guide de la leçon et le guide du lab / de l’examen, regardez la vidéo pas à pas sur la mémoire et les fuites, réussissez la vérification des connaissances, puis réalisez le lab pratique dans WisejPerfLab.
- LectureGuide de la leçon · 14 min
La pression d’allocation par opposition à la mémoire retenue, la démarche de comparaison d’instantanés, les schémas de rétention propres à Wisej.NET (événements statiques, timers, tâches en arrière-plan, caches globaux) et la checklist de libération qui prouve qu’une fuite a disparu. Ce que cela signifie pour un développeur Wisej.NET qui diagnostique les goulets d’étranglement d’une application en production — et comment aborder ce module.
- LectureGuide du lab / de l’examen · 10 min
Ce que vous allez construire dans le lab pratique, l’approche suggérée et les livrables attendus.
- Leçon vidéoRetrouver le formulaire qui n’est jamais parti · 14 min
Retrouver le formulaire qui n’est jamais parti — une vidéo pas à pas du Module 4, construite étape par étape dans WisejPerfLab. Elle se lance directement ici, dans le lecteur.
Transcription de la narration
Un rafraîchissement rapide ne prouve pas une utilisation saine de la mémoire. L'ouverture et la fermeture répétées d'un formulaire révèlent si les objets disparaissent à la fin de leur durée de vie visible.
Mesurez l’allocation et la rétention séparément. Les objets temporaires créent un travail de collection, tandis que les objets qui restent accessibles consomment de la capacité aussi longtemps que leurs références survivent.
Après la phase de préchauffage de l’application, prenez un instantané de référence, répétez cinquante cycles, revenez au repos et comparez. La répétition permet de distinguer plus facilement une croissance persistante des allocations temporaires ordinaires.
Suivez les références des formulaires survivants. Un événement statique et un rappel de minuterie maintiennent le formulaire accessible même après la fermeture de sa fenêtre.
Inspectez les événements, les minuteurs, les tâches, les caches, les champs et les liaisons à la recherche de références ayant une durée de vie plus longue. Le nettoyage doit libérer la propriété lorsque la session ou le formulaire n'en a plus besoin.
Mettez le désabonnement et la suppression à côté de la gestion à vie du formulaire. La vérification de IsDisposed empêche les travaux non valides, mais ne libère pas la référence qui maintient ce formulaire en vie.
Comparez les allocations de recherche après avoir projeté les données une fois. Le volume réduit des chaînes démontre moins de travail répété lors des redessins, indépendamment du fait qu'un objet ait fui ou non.
Répétez les mêmes cinquante cycles après le nettoyage. Confirmez que le nombre de formulaires conservés et le chemin de référence disparaissent ; l'une ou l'autre vérification laisse l'explication incomplète.
Soumettez séparément les preuves d’attribution et de conservation. Utilisez le chiffre de mémoire par session obtenu pour établir un budget de capacité que des contrôles de déploiement ultérieurs peuvent appliquer.
- LectureExercice de code avec l’IA · 20 min
Construisez l’exemple OpsMonitor de ce module avec ChatGPT ou Claude à partir d’un prompt prêt à l’emploi qui oriente le modèle vers la spécification du module, puis relisez, exécutez et étendez ce qu’il vous renvoie — y compris en le comparant à notre propre solution de référence sur GitHub.
- Quiz de connaissancesVérification des connaissances — Module 4 · 10 min · Note de réussite 80%
- Lab pratiqueLab — Pression d’allocation et racines de rétention · 45 min
Objectif: Attaquez les deux moitiés du problème de mémoire dans WisejPerfLab. Exécutez le scénario de recherche de tickets sous .NET Object Allocation et repérez les modèles de ligne et les chaînes alloués à chaque recherche, puis réduisez-les en projetant une seule fois au lieu de reconstruire des objets à chaque rafraîchissement de l’affichage. Prenez ensuite un instantané Memory Usage après la mise en température, ouvrez et fermez cinquante fois le formulaire de détail d’un ticket, prenez un second instantané et comparez : les formulaires retenus sont enracinés par un abonnement statique à GlobalTicketBus.TicketChanged et par un timer d’actualisation jamais arrêté. Désabonnez l’un et arrêtez l’autre dans une surcharge de Dispose, videz la source de données du BindingSource, puis réexécutez le scénario d’ouverture/fermeture et montrez que le tas retenu revient à un niveau proche de l’instantané A. Livrables : Trace d’allocation identifiant le type qui alloue le plus et le chemin d’appel pour le scénario de recherche, avant et après ; Comparaison des instantanés A/B montrant le nombre d’instances retenues du formulaire de détail avant la correction ; Capture d’écran du chemin vers la racine identifiant l’abonnement à l’événement statique et le timer actif ; Surcharge de Dispose qui désabonne l’événement statique, arrête et libère le timer et vide le binding ; Budget mémoire par session et checklist de libération, avec l’instantané « après » prouvant que le chemin de rétention a disparu.
Module 5: Contrôles de données, charges utiles du navigateur et grandes surfaces d’UI
Module 5 du cours Performances et profilage — mesurez, profilez et optimisez les applications Wisej.NET pour que les sessions restent rapides à grande échelle. Lisez le guide de la leçon et le guide du lab / de l’examen, regardez la vidéo pas à pas sur les grandes surfaces d’interface, réussissez la vérification des connaissances, puis réalisez le lab pratique dans WisejPerfLab.
- LectureGuide de la leçon · 14 min
Grilles, listes, arborescences et répéteurs à grande échelle : mode virtuel, pagination, projection et chargement différé des nœuds, et utilisation des preuves réseau du navigateur à côté de celles de Visual Studio pour dimensionner la charge utile des mises à jour. Ce que cela signifie pour un développeur Wisej.NET qui diagnostique les goulets d’étranglement d’une application en production — et comment aborder ce module.
- LectureGuide du lab / de l’examen · 10 min
Ce que vous allez construire dans le lab pratique, l’approche suggérée et les livrables attendus.
- Leçon vidéoCinquante mille lignes sans cinquante mille contrôles · 14 min
Cinquante mille lignes sans cinquante mille contrôles — une vidéo pas à pas du Module 5, construite étape par étape dans WisejPerfLab. Elle se lance directement ici, dans le lecteur.
Transcription de la narration
Module cinq. Les grandes grilles et les arbres peuvent ralentir une application avant que l'utilisateur ne fasse quoi que ce soit. Nous réduirons les données et les contrôles chargés en une seule fois, puis mesurerons l'effet à la fois sur le serveur et sur le navigateur.
Un grand réseau a des coûts à quatre endroits. Le serveur stocke les objets et prépare la mise à jour. Le réseau le transporte et le navigateur le restitue. La seule mesure des performances du serveur ne permettra pas de résoudre une partie du problème.
Tout d’abord, projetez chaque enregistrement dans un objet plus petit contenant les champs dont l’écran a besoin. Utilisez ensuite le mode virtuel pour éviter de conserver chaque ligne en mémoire. Ces changements résolvent différentes parties du problème, alors appliquez les deux.
Définissez RowCount à partir d’une requête de comptage. Lorsque CellValueNeeded demande une valeur, lisez-la à partir de la projection paginée. Évitez une requête de base de données pour chaque cellule et conservez le formatage en dehors de ce gestionnaire.
Appliquez le même principe aux autres contrôles. Chargez les enfants de l'arborescence lorsque leur parent se développe, virtualisez de longues listes, gardez les modèles de répéteur simples et mettez à jour uniquement les lignes du tableau de bord qui ont changé.
Pendant que le nœud de l'arborescence est réduit, conservez un décompte et un enfant d'espace réservé. L'espace réservé préserve le contrôle d'expansion. Créez les vrais nœuds enfants uniquement lorsque l'utilisateur ouvre cette branche.
Comparez les mesures du serveur. La grille contient quarante objets de ligne au lieu de cinquante mille. La mémoire passe de 186 à neuf mégaoctets et le temps de traitement de 1 410 à 95 millisecondes. Ensuite, vérifiez ce qui a changé dans le navigateur.
Inspectez maintenant le trafic du navigateur. La mise à jour de la grille passe de 4,8 mégaoctets à 96 kilo-octets. Six mises à jour plus petites servent à un défilement ultérieur. Indiquez à la fois le nombre et la taille des demandes afin que les mesures indiquent le coût complet.
Pour le laboratoire cinq, projetez et virtualisez la grille, puis chargez les branches d'arbre à la demande. Utilisez Visual Studio pour mesurer le serveur et le panneau réseau pour mesurer le trafic du navigateur. Votre preuve doit couvrir les deux.
- LectureExercice de code avec l’IA · 20 min
Construisez l’exemple OpsMonitor de ce module avec ChatGPT ou Claude à partir d’un prompt prêt à l’emploi qui oriente le modèle vers la spécification du module, puis relisez, exécutez et étendez ce qu’il vous renvoie — y compris en le comparant à notre propre solution de référence sur GitHub.
- Quiz de connaissancesVérification des connaissances — Module 5 · 10 min · Note de réussite 80%
- Lab pratiqueLab — Grille virtuelle et arborescence paresseuse · 45 min
Objectif: Réduisez les deux plus grandes surfaces de WisejPerfLab. La grille des tickets est liée à 50 000 entités complètes avec leurs propriétés de navigation : remplacez cette liaison par une projection TicketGridRow limitée aux colonnes visibles, définissez VirtualMode et RowCount et servez les cellules depuis un gestionnaire CellValueNeeded adossé à un service de requêtes paginées. L’arborescence des clients construit tous les nœuds au démarrage : chargez plutôt les enfants au déploiement d’un nœud, avec un espace réservé indiquant le nombre d’enfants pour les branches repliées. Mesurez chaque écran avant et après avec CPU Usage et .NET Object Allocation côté serveur et avec le panneau réseau du navigateur pour la taille de la charge utile des mises à jour. Livrables : Projection TicketGridRow liée à la place des entités complètes, avec uniquement les colonnes affichées ; Grille en mode virtuel avec RowCount et un gestionnaire CellValueNeeded servi par un service de requêtes paginées ; Arborescence des clients chargeant les nœuds enfants au déploiement, avec un espace réservé de comptage pour les branches repliées ; Chiffres CPU et d’allocation avant/après pour les scénarios de chargement de la grille et de déploiement de l’arborescence ; Preuves réseau du navigateur comparant la taille de la charge utile des mises à jour avant et après, avec la réserve concernant la compression.
Module 6: Base de données, E/S fichier, async et attentes externes
Module 6 du cours Performances et profilage — mesurez, profilez et optimisez les applications Wisej.NET pour que les sessions restent rapides à grande échelle. Lisez le guide de la leçon et le guide du lab / de l’examen, regardez la vidéo pas à pas sur la base de données et l’asynchrone, réussissez la vérification des connaissances, puis réalisez le lab pratique dans WisejPerfLab.
- LectureGuide de la leçon · 14 min
La latence que CPU Usage ne voit pas : l’outil Database pour la durée des requêtes et les schémas N+1, File I/O pour les imports et exports, et .NET Async pour les chaînes bloquées ou involontairement séquentielles. Ce que cela signifie pour un développeur Wisej.NET qui diagnostique les goulets d’étranglement d’une application en production — et comment aborder ce module.
- LectureGuide du lab / de l’examen · 10 min
Ce que vous allez construire dans le lab pratique, l’approche suggérée et les livrables attendus.
- Leçon vidéoCPU faible, écran lent : profiler l’attente · 14 min
CPU faible, écran lent : profiler l’attente — une vidéo pas à pas du Module 6, construite étape par étape dans WisejPerfLab. Elle se lance directement ici, dans le lecteur.
Transcription de la narration
Un processeur silencieux peut accompagner une application lente. Utilisez la trace d'actualisation précédente pour étudier l'attente au lieu d'essayer d'optimiser le calcul qui n'explique pas le délai.
Attribuez le temps manquant aux opérations de base de données, à l'accès aux fichiers et aux threads bloqués. Ces attentes nécessitent leurs propres mesures car les échantillons du processeur décrivent principalement le travail effectué lors de l'exécution.
Inspectez comment l’écran obtient ses lignes. Les recherches répétées et les champs excessifs ajoutent du travail de base de données évitable ; projeter les champs requis ensemble peut éliminer plusieurs problèmes à la fois.
Joignez le nom du client à la requête et sélectionnez uniquement les champs affichés. Triez et pagez les résultats, en utilisant des lectures non suivies lorsque l'écran n'a pas besoin de suivi des modifications.
Attendez les opérations d’entrée et de sortie afin qu’une requête en attente n’occupe pas inutilement un thread. Cela améliore la disponibilité des ressources ; cela ne rend pas la base de données ou le disque sous-jacent plus rapide.
Supprimez le blocage de l'accès aux résultats et diffusez l'exportation au lieu d'émettre de nombreuses petites écritures. Envoyez les progrès à intervalles significatifs afin que les commentaires ne deviennent pas une autre source de surcharge.
Comparez le nombre de requêtes après le changement. Le passage de deux cent une requêtes à deux confirme cette correction, même si un autre coût empêche encore le scénario de respecter son budget.
Répétez l'exportation avec des sessions simultanées. Un blocage qui semble inoffensif pour un utilisateur peut épuiser les threads disponibles et retarder les écrans sans rapport lorsque plusieurs utilisateurs l'exécutent ensemble.
Connectez chaque requête à son action d'interface, puis comparez avant et après. Expliquez à la fois le fonctionnement de la base de données supprimée et comment l'exportation évite de bloquer le chemin de clic.
- LectureExercice de code avec l’IA · 20 min
Construisez l’exemple OpsMonitor de ce module avec ChatGPT ou Claude à partir d’un prompt prêt à l’emploi qui oriente le modèle vers la spécification du module, puis relisez, exécutez et étendez ce qu’il vous renvoie — y compris en le comparant à notre propre solution de référence sur GitHub.
- Quiz de connaissancesVérification des connaissances — Module 6 · 10 min · Note de réussite 80%
- Lab pratiqueLab — Traces de requêtes et export bloqué · 45 min
Objectif: Profilez les deux scénarios dominés par l’attente dans WisejPerfLab. Exécutez la recherche de tickets sous l’outil Database et associez chaque requête à l’action d’interface qui l’a produite : le chargement de la grille émet une requête client par ligne affichée et la requête de détail ramène de grandes colonnes de texte que personne n’affiche. Remplacez-les par une seule requête de projection sans suivi qui ne sélectionne que les colonnes de la grille et pagine le résultat. Exécutez ensuite l’export CSV sous File I/O et .NET Async, repérez l’appel bloquant .Result dans le gestionnaire de clic et les petites écritures répétées, et déplacez la génération dans un traitement en arrière-plan Application.StartTask qui écrit le fichier en flux et signale une progression limitée au lieu de pousser chaque étape. Livrables : Trace Database associant les requêtes aux actions d’interface, avec le nombre de requêtes N+1 avant la correction ; Requête unique de projection sans suivi avec pagination, remplaçant les requêtes par ligne et celles qui ramènent trop de données ; Preuves File I/O et .NET Async pour l’export, identifiant l’appel bloquant et le schéma d’écriture ; Export déplacé dans une tâche en arrière-plan qui écrit en flux et ne pousse la progression qu’aux étapes significatives ; Nombre de requêtes, durée des requêtes et temps réel de l’export avant/après, avec les risques restants.
Module 7: Montée en charge, health checks, répartition de charge et optimisation finale
Module 7 du cours Performances et profilage — mesurez, profilez et optimisez les applications Wisej.NET pour que les sessions restent rapides à grande échelle. Lisez le guide de la leçon et le guide du lab / de l’examen, regardez la vidéo pas à pas sur la montée en charge et les health checks, réussissez la vérification des connaissances, puis réalisez le lab pratique dans WisejPerfLab.
- LectureGuide de la leçon · 14 min
Transformer des mesures en modèle de capacité, les seuils de HealthCheck.json, l’affinité de session et un équilibrage de charge compatible WebSocket, les compteurs de production et le rapport de performance final qui justifie chaque modification. Ce que cela signifie pour un développeur Wisej.NET qui diagnostique les goulets d’étranglement d’une application en production — et comment aborder ce module.
- LectureGuide du lab / de l’examen · 10 min
Ce que vous allez construire dans le lab pratique, l’approche suggérée et les livrables attendus.
- Leçon vidéoD’une trace locale à un modèle de capacité · 14 min
D’une trace locale à un modèle de capacité — une vidéo pas à pas du Module 7, construite étape par étape dans WisejPerfLab. Elle se lance directement ici, dans le lecteur.
Transcription de la narration
Traduisez les résultats du profilage en limites de fonctionnement. Une application plus rapide a toujours besoin d'une capacité de session défendable et d'un plan pour éloigner les nouveaux utilisateurs d'un serveur complet.
Multipliez la mémoire de session mesurée par le nombre de sessions proposé et comparez-la à la mémoire utilisable. Gardez une marge, car les sessions inactives ne décrivent pas chaque allocation de pointe.
Préservez l’affinité de session tout au long du déploiement et autorisez les mises à niveau de WebSocket via des proxys. Les contrôles avec état nécessitent le bon serveur et les mises à jour en direct nécessitent un chemin de transport ininterrompu.
Fixez des seuils de santé à partir de la capacité mesurée plutôt que de suppositions pratiques. La réponse malsaine et les instructions de nouvelle tentative donnent à l’infrastructure un signal lorsque l’instance doit cesser de recevoir de nouvelles sessions.
Surveillez le signal qui correspond à chaque problème corrigé. Les durées des scénarios, la taille du tas géré et les files d'attente du pool de threads révèlent différentes régressions et ne doivent pas être traitées comme interchangeables.
Rédigez un rapport qui relie le scénario original à sa cause, sa correction et ses preuves. Incluez les risques et les contrôles opérationnels afin qu’un collègue puisse vérifier l’amélioration après le déploiement.
Regardez ce qui se passe lorsque l'instance A atteint sa capacité. Le nouveau trafic se déplace vers l'instance B tandis que les sessions établies se poursuivent, séparant le contrôle d'admission de la perturbation des utilisateurs existants.
Comparez chaque scénario par rapport à son budget initial. Conservez l'exportation marquée comme un risque, car une cible absente et des tests de concurrence limités ne peuvent pas soutenir une réclamation réussie.
Fournissez ensemble le calcul de la capacité, la configuration de l’état, les notes de déploiement et le rapport reproductible. Les opérations ont besoin à la fois des limites choisies et des preuves expliquant pourquoi ces limites sont appropriées.
- LectureExercice de code avec l’IA · 20 min
Construisez l’exemple OpsMonitor de ce module avec ChatGPT ou Claude à partir d’un prompt prêt à l’emploi qui oriente le modèle vers la spécification du module, puis relisez, exécutez et étendez ce qu’il vous renvoie — y compris en le comparant à notre propre solution de référence sur GitHub.
- Quiz de connaissancesVérification des connaissances — Module 7 · 10 min · Note de réussite 80%
- Lab pratiqueLab — Modèle de capacité et rapport du projet de synthèse · 45 min
Objectif: Réalisez le projet de synthèse WisejPerfLab. Établissez un modèle de capacité à partir de vos propres mesures : mémoire retenue par session inactive, CPU par scénario courant, simultanéité attendue au pic et marge de sécurité que vous conservez. Rédigez un HealthCheck.json dont les valeurs maxSessions, maxMemory et maxCPU découlent de ces chiffres, en expliquant chaque seuil, et qui renvoie 503 avec un retry-after pour qu’un répartiteur de charge oriente les nouveaux utilisateurs ailleurs pendant que les sessions existantes continuent de fonctionner. Rédigez les notes de déploiement pour deux instances derrière un répartiteur de charge avec affinité de session et prise en charge de WebSocket, puis assemblez le rapport final : scénarios, environnement, preuves de référence, causes racines, modifications, preuves « après », risques restants et compteurs de production qui signaleront le retour d’une régression. Livrables : Modèle de capacité déduisant le nombre de sessions par serveur de la mémoire mesurée par session et du CPU par scénario ; HealthCheck.json avec maxSessions, maxMemory, maxCPU, code de retour et retry-after, chaque seuil étant justifié ; Notes de déploiement couvrant l’affinité de session, la prise en charge de WebSocket et le repli sur le polling ; Rapport de performance final avec référence, cause racine, modification et preuve « après » pour chaque correction de module ; Plan de supervision indiquant les compteurs, les seuils et les alertes qui détecteraient chaque régression.