Performance und Profiling
Schnelle Apps halten ihre Benutzer – und bei großer Last ist Performance eine Frage der Architektur, kein nachträglicher Gedanke. Dieser Kurs zeigt Ihnen, wie Sie Wisej.NET-Anwendungen messen, profilieren und optimieren, damit Sessions auch unter Last schnell bleiben. Sie lernen, Engpässe mit echtem Profiling zu finden, zu verstehen, wohin Serverzeit und Speicher pro Session fließen, und die Techniken anzuwenden, mit denen eine stark ausgelastete Wisej.NET-App auch im großen Maßstab reaktionsschnell bleibt.
Wisej.NET-Apps messen, profilieren und optimieren – Engpässe finden und Sessions auch bei hoher Last schnell halten.
- Niveau: Advanced
- Dauer: 9 Stunden
- Module: 7
Lehrplan
Modul 1: Das Performance-Modell von Wisej.NET
Modul 1 von Performance und Profiling – Wisej.NET-Apps messen, profilieren und optimieren, damit Sessions auch bei hoher Last schnell bleiben. Lesen Sie den Lektionsleitfaden und den Lab- und Prüfungsleitfaden, sehen Sie sich den Video-Walkthrough zum Performance-Modell an, bestehen Sie den Wissenstest und schließen Sie dann das praktische Lab in WisejPerfLab ab.
- LektüreLektionsleitfaden · 14 Min.
Der Request- und Event-Zyklus, WebSocket-Push, der Session-Zustand als Kapazitätseinheit, die fünf Kostenkategorien und die Disziplin aus Szenario plus Baseline, an der jeder spätere Trace gemessen wird. Was das für Wisej.NET-Entwickler bedeutet, die Engpässe in einer produktiven App diagnostizieren – und wie Sie dieses Modul am besten durcharbeiten.
- LektüreLab- und Prüfungsleitfaden · 10 Min.
Was Sie im praktischen Lab bauen, das vorgeschlagene Vorgehen und die geforderten Ergebnisse.
- VideolektionWohin die Zeit in einer Wisej.NET-Session wirklich geht · 14 Min.
Wohin die Zeit in einer Wisej.NET-Session wirklich geht – ein geführter Video-Walkthrough zu Modul 1, Schritt für Schritt in WisejPerfLab aufgebaut. Läuft direkt hier im Player.
Transkript der Sprecherstimme
Beginnen Sie mit der langsamen Aktualisierung in WisejPerfLab. Die verstrichene Zeit gibt Aufschluss über das Problem, aber eine sinnvolle Untersuchung muss klären, wo diese Zeit vergangen ist, bevor eine Lösung ausgewählt wird.
Folgen Sie dem Klick vom Browser zum Server und zurück. Serversteuerelemente verbrauchen Speicher, während ihre Änderung auch Verarbeitungs-, Transport- und Rendering-Arbeit verursacht.
Separate Berechnung, Warten, Speicher, Datenzugriff und übertragene Aktualisierungen. Diese Klassifizierung bestimmt, welche Messung die Verzögerung erklären kann; Eine Prozessorverfolgung kann nicht alle Browserkosten aufdecken.
Fügen Sie ein ScenarioProbe um die Aktion herum hinzu. Ein verfügbarer Bereich zeichnet den Abschluss auf jedem Exit-Pfad auf, und benannte Felder für Dauer und Zeilenanzahl machen einzelne Läufe vergleichbar.
Zählen Sie die von jeder Sitzung beibehaltenen Objekte, einschließlich Steuerelementen und zwischengespeicherten Zeilen. Ein kleines Leck wird zu einem Kapazitätsproblem, wenn jede verbundene Sitzung eine weitere Kopie behält.
Messen Sie die Abfrage und die Schnittstellenänderungen gemeinsam. Andernfalls lässt die aufgezeichnete Dauer einen Teil der Arbeit aus, auf die der Benutzer während der Aktualisierung tatsächlich wartet.
Zeichnen Sie Aktualisierung, Suche und Baumerweiterung separat in der erwärmten Anwendung auf. Diese Einzelsitzungszeiten sind Referenzpunkte; Sie erklären das Verhalten bei gleichzeitiger Nutzung noch nicht.
Notieren Sie den Aufbau, den Datensatz und das Aufwärmen neben jeder Baseline. Geben Sie jedem Szenario ein Ziel und ein Messinstrument, damit spätere Verbesserungen konsistent bewertet werden können.
Instrumentieren Sie alle drei Laborszenarien, bevor Sie sie optimieren. Die Ausgangslage und das Budget dienen als Beweismittel für nachfolgende Module, um eine Verbesserung von einer unerklärten zeitlichen Änderung zu unterscheiden.
- LektüreKI-Coding-Übung · 20 Min.
Erstellen Sie das Beispielprojekt OpsMonitor dieses Moduls mit ChatGPT oder Claude aus einem fertigen Prompt, der das Modell auf die Spezifikation des Moduls verweist – und prüfen, starten und erweitern Sie dann, was Sie erhalten, auch im Vergleich mit unserem eigenen Referenz-Build auf GitHub.
- WissenstestWissenstest – Modul 1 · 10 Min. · Bestehensgrenze 80%
- Praktisches LabLab – Szenarien, Messpunkte und das erste Budget · 45 Min.
Ziel: Legen Sie die WisejPerfLab-Solution mit einem Support-Dashboard, einem Ticket-Grid und einem Kundenbaum an, die aus Seed-Daten gespeist werden, und machen Sie sie anschließend messbar. Fügen Sie einen ScenarioProbe-Service hinzu, der ein Szenario in einen Stopwatch-Scope einschließt und strukturierte PERF-Start/Ende-Logs mit dem Szenarionamen, der Benutzeraktion, den verstrichenen Millisekunden und der Zeilenanzahl schreibt, registrieren Sie ihn im Host-Builder und umschließen Sie damit drei Szenarien: Dashboard aktualisieren, Tickets suchen und Kundenbaum aufklappen. Führen Sie jedes Szenario einmal zum Aufwärmen aus, halten Sie dann die Baseline fest und schreiben Sie ein Performance-Budget, das Umgebung, Build-Konfiguration, Datenmenge und einen Abnahme-Schwellenwert pro Szenario nennt. Ergebnisse: WisejPerfLab-Solution mit Dashboard, Ticket-Grid und Kundenbaum auf Seed-Daten; ScenarioProbe-Service, der strukturierte PERF-Start/Ende-Logs mit verstrichenen Millisekunden und Zeilenanzahl schreibt; drei instrumentierte Szenarien: Dashboard aktualisieren, Tickets suchen und Kundenbaum aufklappen; Baseline-Notiz mit Umgebung, Build-Konfiguration, Datenmenge und Aufwärmverfahren; Performance-Budget mit einem Abnahme-Schwellenwert pro Szenario und dem Tool, das ihn jeweils belegen würde.
Modul 2: Profiling-Workflow in Visual Studio für Wisej.NET
Modul 2 von Performance und Profiling – Wisej.NET-Apps messen, profilieren und optimieren, damit Sessions auch bei hoher Last schnell bleiben. Lesen Sie den Lektionsleitfaden und den Lab- und Prüfungsleitfaden, sehen Sie sich den Video-Walkthrough zum Profiling-Workflow an, bestehen Sie den Wissenstest und schließen Sie dann das praktische Lab in WisejPerfLab ab.
- LektüreLektionsleitfaden · 14 Min.
Den Performance Profiler richtig gegen eine Wisej.NET-App einsetzen: Release-Builds ohne Debugger, die Matrix zur Tool-Auswahl, das Anhängen an dotnet oder w3wp und das Lesen von Zusammenfassungs-Timeline, Aufrufstruktur, Hot Path sowie Caller/Callee-Ansichten. Was das für Wisej.NET-Entwickler bedeutet, die Engpässe in einer produktiven App diagnostizieren – und wie Sie dieses Modul am besten durcharbeiten.
- LektüreLab- und Prüfungsleitfaden · 10 Min.
Was Sie im praktischen Lab bauen, das vorgeschlagene Vorgehen und die geforderten Ergebnisse.
- VideolektionEinen Trace erfassen, der wirklich etwas beweist · 14 Min.
Einen Trace erfassen, der wirklich etwas beweist – ein geführter Video-Walkthrough zu Modul 2, Schritt für Schritt in WisejPerfLab aufgebaut. Läuft direkt hier im Player.
Transkript der Sprecherstimme
Eine Profilerstellungserfassung ist nur dann sinnvoll, wenn sie ein bekanntes Experiment darstellt. Halten Sie den Build, das Szenario und das ausgewählte Tool explizit, damit ein anderer Entwickler das Ergebnis interpretieren kann.
Erwärmen Sie einen Release-Build, zeichnen Sie eine Aktion auf und stoppen Sie dann. Durch den Ausschluss von Startup- und nicht damit zusammenhängenden Aktivitäten wird verhindert, dass deren Kosten mit dem von Ihnen untersuchten Verhalten verwechselt werden.
Wählen Sie den Profiler aus den vermuteten Kosten aus. Die Stichprobenerhebung erklärt die Berechnung; Warten, Zuordnungen, Datenbankzugriff und Dateioperationen benötigen unterschiedliche Ansichten, um ihren Beitrag anzuzeigen.
Bereiten Sie die Trace-Notiz vor der Aufnahme vor. Hosting, Datensatz, Browser und Budget erklären die Bedingungen hinter den Proben und machen die Erfassung später reproduzierbar.
Hängen Sie es an den Prozess an, der den Antrag tatsächlich bedient. Bestätigen Sie die Kennung, insbesondere wenn mehrere Standorte oder Anwendungspools Prozesse mit demselben Namen der ausführbaren Datei erstellen.
Wählen Sie das Klickintervall aus, bevor Sie dem Hot Path folgen. Die große inklusive Zeit im Versandcode unterscheidet sich von der Selbstzeit in FormatRow, wo die Prozessorarbeit tatsächlich stattfindet.
Wiederholen Sie den gleichen geordneten Arbeitsablauf für jede Aufnahme. Bei Internetinformationsdiensten führt die Auswahl des falschen Arbeitsprozesses dazu, dass die Messungen ungültig werden, bevor die Analyse überhaupt beginnt.
Vergleichen Sie die Probenahme mit der Instrumentierung für dieselbe Aktualisierung. Formatiereraufrufe erklären die Berechnung, während die separate Wartezeit zeigt, warum eine reine Prozessoruntersuchung einen Teil der Verzögerung ungeklärt lassen würde.
Speichern Sie beide Aktualisierungsspuren mit ihren Notizen. Geben Sie eine vermutete Ursache und Beweise an, die diese widerlegen würden, damit die nächste Änderung eher eine Hypothese als eine Vermutung testet.
- LektüreKI-Coding-Übung · 20 Min.
Erstellen Sie das Beispielprojekt OpsMonitor dieses Moduls mit ChatGPT oder Claude aus einem fertigen Prompt, der das Modell auf die Spezifikation des Moduls verweist – und prüfen, starten und erweitern Sie dann, was Sie erhalten, auch im Vergleich mit unserem eigenen Referenz-Build auf GitHub.
- WissenstestWissenstest – Modul 2 · 10 Min. · Bestehensgrenze 80%
- Praktisches LabLab – CPU-Auslastung und Instrumentierungs-Traces · 45 Min.
Ziel: Profilieren Sie die langsame Dashboard-Aktualisierung in WisejPerfLab richtig. Wechseln Sie zu Release, wärmen Sie die App einmal auf, erfassen Sie dann mit Alt+F2 einen CPU Usage-Trace genau dieses einen Szenarios, grenzen Sie die Zusammenfassungs-Timeline auf den Klick selbst ein und finden Sie mit Show Hot Path den obersten Pfad unterhalb der Dispatch-Frames von Wisej.NET. Erfassen Sie einen zweiten Instrumentation-Trace desselben Szenarios, um Aufrufanzahlen und Wall-Clock-Zeit zu erhalten, entscheiden Sie anhand der beiden Traces, ob die Kosten CPU-Zeit in Ihrem Code oder Wartezeit sind, und speichern Sie beide .diagsession-Dateien unter einem Namen, der Modul, Szenario, Build, Datenmenge und Zeitstempel enthält. Ergebnisse: Release-CPU Usage-Trace des Szenarios Dashboard-Aktualisierung, Timeline auf den Klick eingegrenzt; Hot-Path-Screenshot, der die oberste Anwendungsfunktion und ihre eigene gegenüber der gesamten CPU-Zeit nennt; Instrumentation-Trace desselben Szenarios mit Aufrufanzahlen und Wall-Clock-Zeit; Trace-Notiz mit Kurs, Modul, Szenario, Build, Hosting, Tool, Browser und erwartetem Budget; ein Absatz zur vermuteten Ursache, der angibt, auf welche der fünf Kostenkategorien die Belege hinweisen.
Modul 3: CPU-Hotpaths, Event-Handler und serverseitige UI-Arbeit
Modul 3 von Performance und Profiling – Wisej.NET-Apps messen, profilieren und optimieren, damit Sessions auch bei hoher Last schnell bleiben. Lesen Sie den Lektionsleitfaden und den Lab- und Prüfungsleitfaden, sehen Sie sich den Video-Walkthrough zu CPU-Hotpaths an, bestehen Sie den Wissenstest und schließen Sie dann das praktische Lab in WisejPerfLab ab.
- LektüreLektionsleitfaden · 14 Min.
Teurer serverseitiger UI-Code in Event-Handlern, Timern, Layout-Aktualisierungen und Formatierungslogik – und die Caching-, Batching- und View-Model-Muster, die einen Klick wieder günstig machen. Was das für Wisej.NET-Entwickler bedeutet, die Engpässe in einer produktiven App diagnostizieren – und wie Sie dieses Modul am besten durcharbeiten.
- LektüreLab- und Prüfungsleitfaden · 10 Min.
Was Sie im praktischen Lab bauen, das vorgeschlagene Vorgehen und die geforderten Ergebnisse.
- VideolektionDen Aktualisieren-Button günstig machen · 14 Min.
Den Aktualisieren-Button günstig machen – ein geführter Video-Walkthrough zu Modul 3, Schritt für Schritt in WisejPerfLab aufgebaut. Läuft direkt hier im Player.
Transkript der Sprecherstimme
Beginnen Sie mit den gemessenen Straftätern: wiederholte Zeilenformatierung und Neuaufbau des Indikatorfelds. Ihre Anrufmuster sagen uns, welche Arbeit wir aus dem Klick des Benutzers entfernen müssen.
Suchen Sie nach ansonsten sinnvollen Vorgängen, die bei häufigen Ereignissen wiederholt werden. Formatierung, Bildkonvertierung, Spiegelung und Sortierung werden teuer, wenn ihre Platzierung den Arbeitsaufwand vervielfacht.
Unterscheiden Sie zu viele Anrufe von zu viel Arbeit pro Anruf. Durch die Reduzierung der Frequenz wird das erste Problem gelöst. Indem man eine Operation billiger macht, geht es um die zweite.
Überprüfen Sie den Handler, bevor Sie ihn ändern. Durch die Neuerstellung von Steuerelementen und die Formatierung aller Zeilen entstehen unterschiedliche Kosten, sodass bei einer einzigen kosmetischen Neufassung das zugrunde liegende Verhalten erhalten bleiben würde.
Berechnen Sie stabile Ergebnisse vorab, führen Sie stapelbezogene Änderungen durch und aktualisieren Sie vorhandene Kontrollen. Nur unveränderliche Daten zwischenspeichern; Durch das Verschieben der Berechnung in eine asynchrone Methode wird diese Berechnung nicht entfernt.
Verschieben Sie die Formatierung nach GetSnapshot und lassen Sie den Handler die Ergebnisse zuweisen. Behalten Sie den ursprünglichen Messbereich bei und stellen Sie die Schaltfläche in finally wieder her, damit die Schnittstelle bei Fehlern weiterhin verwendbar bleibt.
Wiederholen Sie dieselben Erfassungs- und Inspektionsaufrufe, nicht nur die verstrichene Zeit. Das Verschwinden des Formatierers aus dem Hot-Pfad zeigt, dass die beabsichtigte Arbeit tatsächlich entfernt wurde.
Die Aktualisierung entspricht jetzt ihrem Budget, allerdings ist die Veralterung des Dokument-Snapshots ein Kompromiss. Das separat identifizierte Warten bleibt für eine spätere Untersuchung ein anderes Problem.
Ersetzen Sie beide teuren Muster im Labor und reichen Sie vergleichbare Messungen ein. Ihre Beweise sollten den Snapshot und den Batch-Handler mit den geänderten Anrufzahlen in Verbindung bringen.
- LektüreKI-Coding-Übung · 20 Min.
Erstellen Sie das Beispielprojekt OpsMonitor dieses Moduls mit ChatGPT oder Claude aus einem fertigen Prompt, der das Modell auf die Spezifikation des Moduls verweist – und prüfen, starten und erweitern Sie dann, was Sie erhalten, auch im Vergleich mit unserem eigenen Referenz-Build auf GitHub.
- WissenstestWissenstest – Modul 3 · 10 Min. · Bestehensgrenze 80%
- Praktisches LabLab – Vom Hotpath zum gecachten View-Model · 45 Min.
Ziel: Reparieren Sie den Aktualisieren-Button in WisejPerfLab. Profilieren Sie das Aktualisierungsszenario mit CPU Usage, öffnen Sie das Flammendiagramm und Show Hot Path und identifizieren Sie die beiden Verursacher: einen Formatter, der bei jeder Aktualisierung pro Zelle läuft, und einen Control-Neuaufbau, der das KPI-Panel jedes Mal neu erzeugt. Ersetzen Sie beide durch ein DashboardSnapshot-View-Model, dessen Anzeigetexte einmal im Service berechnet werden, ändern Sie die Labels und die Datenquelle des Diagramms einmal innerhalb eines Probe-Scopes statt Zeile für Zeile, und halten Sie den Button während der Arbeit in einem try/finally deaktiviert. Führen Sie das identische Szenario erneut aus und erfassen Sie den neuen Hot Path. Ergebnisse: CPU Usage-Trace vorher, der den wiederholten Formatter und den Control-Neuaufbau mit ihrer gesamten und eigenen CPU-Zeit nennt; DashboardSnapshot-View-Model mit im Service vorberechneten Anzeigetexten; gebündelter Aktualisierungs-Handler, der die Controls einmal innerhalb eines Probe-Scopes ändert und den Button per try/finally wieder aktiviert; CPU Usage-Trace nachher vom identischen Szenario mit dem neuen Hot Path; Vorher-nachher-Tabelle mit gesamter CPU-Zeit, oberster Funktion und Aufrufanzahl sowie dem verbleibenden Risiko.
Modul 4: Speicher, Allokationen und Session-Lecks
Modul 4 von Performance und Profiling – Wisej.NET-Apps messen, profilieren und optimieren, damit Sessions auch bei hoher Last schnell bleiben. Lesen Sie den Lektionsleitfaden und den Lab- und Prüfungsleitfaden, sehen Sie sich den Video-Walkthrough zu Speicher und Lecks an, bestehen Sie den Wissenstest und schließen Sie dann das praktische Lab in WisejPerfLab ab.
- LektüreLektionsleitfaden · 14 Min.
Allokationsdruck im Vergleich zu gehaltenem Speicher, der Workflow zum Vergleichen von Snapshots, die Retention-Muster in Wisej.NET (statische Events, Timer, Hintergrund-Tasks, globale Caches) und die Dispose-Checkliste, die belegt, dass ein Leck beseitigt ist. Was das für Wisej.NET-Entwickler bedeutet, die Engpässe in einer produktiven App diagnostizieren – und wie Sie dieses Modul am besten durcharbeiten.
- LektüreLab- und Prüfungsleitfaden · 10 Min.
Was Sie im praktischen Lab bauen, das vorgeschlagene Vorgehen und die geforderten Ergebnisse.
- VideolektionDas Formular finden, das nie freigegeben wurde · 14 Min.
Das Formular finden, das nie freigegeben wurde – ein geführter Video-Walkthrough zu Modul 4, Schritt für Schritt in WisejPerfLab aufgebaut. Läuft direkt hier im Player.
Transkript der Sprecherstimme
Eine schnelle Aktualisierung ist kein Beweis für eine gesunde Speichernutzung. Das wiederholte Öffnen und Schließen eines Formulars zeigt, ob Objekte verschwinden, wenn ihre sichtbare Lebensdauer endet.
Messen Sie Allokation und Retention getrennt. Temporäre Objekte erzeugen Sammlungsarbeit, während Objekte, die erreichbar bleiben, so lange Kapazität verbrauchen, wie ihre Referenzen bestehen.
Machen Sie einen warmen Grundlinien-Schnappschuss, wiederholen Sie fünfzig Zyklen, kehren Sie in den Leerlauf zurück und vergleichen Sie. Durch Wiederholung lässt sich anhaltendes Wachstum leichter von gewöhnlichen vorübergehenden Zuweisungen unterscheiden.
Folgen Sie den Verweisen auf den erhaltenen Formularen. Durch ein statisches Ereignis und einen Timer-Rückruf bleibt das Formular auch nach dem Schließen des Fensters erreichbar.
Untersuchen Sie Ereignisse, Timer, Aufgaben, Caches, Felder und Bindungen auf Referenzen mit längerer Lebensdauer. Die Bereinigung muss die Eigentümerschaft freigeben, wenn die Sitzung oder das Formular sie nicht mehr benötigt.
Stellen Sie Abmeldung und Entsorgung neben die Lebensdauerverwaltung des Formulars. Durch die Überprüfung von IsDisposed wird ungültige Arbeit verhindert, die Referenz wird jedoch nicht freigegeben, sodass das Formular am Leben bleibt.
Vergleichen Sie Suchzuordnungen, nachdem Sie die Daten einmal projiziert haben. Das reduzierte String-Volumen zeigt weniger wiederholte Arbeit beim Neuzeichnen, unabhängig davon, ob ein Objekt ausgelaufen ist.
Wiederholen Sie die gleichen fünfzig Zyklen nach der Reinigung. Bestätigen Sie, dass sowohl die Anzahl der beibehaltenen Formulare als auch der Referenzpfad verschwinden. Beide Prüfungen allein lassen die Erklärung unvollständig.
Reichen Sie Zuordnungs- und Aufbewahrungsnachweise getrennt ein. Verwenden Sie die resultierende Speicherzahl pro Sitzung, um ein Kapazitätsbudget festzulegen, das spätere Bereitstellungsprüfungen durchsetzen können.
- LektüreKI-Coding-Übung · 20 Min.
Erstellen Sie das Beispielprojekt OpsMonitor dieses Moduls mit ChatGPT oder Claude aus einem fertigen Prompt, der das Modell auf die Spezifikation des Moduls verweist – und prüfen, starten und erweitern Sie dann, was Sie erhalten, auch im Vergleich mit unserem eigenen Referenz-Build auf GitHub.
- WissenstestWissenstest – Modul 4 · 10 Min. · Bestehensgrenze 80%
- Praktisches LabLab – Allokationsdruck und Retention-Roots · 45 Min.
Ziel: Gehen Sie in WisejPerfLab beide Hälften des Speicherproblems an. Führen Sie das Szenario Tickets suchen unter .NET Object Allocation aus, finden Sie die pro Suche allokierten Zeilenmodelle und Strings und reduzieren Sie sie, indem Sie einmal projizieren, statt Objekte bei jedem Neuzeichnen neu aufzubauen. Erstellen Sie danach nach dem Aufwärmen einen Memory Usage-Snapshot, öffnen und schließen Sie das Ticket-Detailformular fünfzigmal, erstellen Sie einen zweiten Snapshot und vergleichen Sie: Die gehaltenen Formulare werden von einem statischen GlobalTicketBus.TicketChanged-Abonnement und einem nie gestoppten Aktualisierungs-Timer verankert. Melden Sie das Abonnement ab und stoppen Sie den Timer in einem überschriebenen Dispose, leeren Sie die Datenquelle der BindingSource, führen Sie dann das Öffnen/Schließen-Szenario erneut aus und zeigen Sie, dass der gehaltene Heap wieder nahe an Snapshot A liegt. Ergebnisse: Allokations-Trace, der den am stärksten allokierenden Typ und Aufrufpfad des Suchszenarios nennt, vorher und nachher; Vergleich von Snapshot A/B, der die Anzahl gehaltener Detailformular-Instanzen vor dem Fix zeigt; Path-to-Root-Screenshot, der das statische Event-Abonnement und den laufenden Timer identifiziert; Dispose-Override, das das statische Event abmeldet, den Timer stoppt und verwirft und das Binding löst; Speicherbudget pro Session und eine Dispose-Checkliste, wobei der Snapshot nachher belegt, dass der Retention-Pfad beseitigt ist.
Modul 5: Daten-Controls, Browser-Payloads und große UI-Flächen
Modul 5 von Performance und Profiling – Wisej.NET-Apps messen, profilieren und optimieren, damit Sessions auch bei hoher Last schnell bleiben. Lesen Sie den Lektionsleitfaden und den Lab- und Prüfungsleitfaden, sehen Sie sich den Video-Walkthrough zu großen UI-Flächen an, bestehen Sie den Wissenstest und schließen Sie dann das praktische Lab in WisejPerfLab ab.
- LektüreLektionsleitfaden · 14 Min.
Grids, Listen, Bäume und Repeater im großen Maßstab: Virtual Mode, Paging, Projektion und verzögertes Laden von Knoten – und Netzwerkbelege aus dem Browser neben den Belegen aus Visual Studio, um die Größe des Update-Payloads zu bestimmen. Was das für Wisej.NET-Entwickler bedeutet, die Engpässe in einer produktiven App diagnostizieren – und wie Sie dieses Modul am besten durcharbeiten.
- LektüreLab- und Prüfungsleitfaden · 10 Min.
Was Sie im praktischen Lab bauen, das vorgeschlagene Vorgehen und die geforderten Ergebnisse.
- VideolektionFünfzigtausend Zeilen ohne fünfzigtausend Controls · 14 Min.
Fünfzigtausend Zeilen ohne fünfzigtausend Controls – ein geführter Video-Walkthrough zu Modul 5, Schritt für Schritt in WisejPerfLab aufgebaut. Läuft direkt hier im Player.
Transkript der Sprecherstimme
Modul fünf. Große Gitter und Bäume können eine Anwendung verlangsamen, bevor der Benutzer etwas tut. Wir werden die auf einmal geladenen Daten und Steuerelemente reduzieren und dann die Auswirkung auf den Server und den Browser messen.
Ein großes Netz verursacht an vier Stellen Kosten. Der Server speichert die Objekte und bereitet das Update vor. Das Netzwerk überträgt es und der Browser rendert es. Allein die Messung der Serverleistung wird einen Teil des Problems übersehen.
Projizieren Sie zunächst jeden Datensatz in ein kleineres Objekt, das die für den Bildschirm erforderlichen Felder enthält. Verwenden Sie dann den virtuellen Modus, um zu vermeiden, dass jede Zeile im Speicher bleibt. Diese Änderungen lösen verschiedene Teile des Problems, also wenden Sie beide an.
Legen Sie RowCount aus einer Zählabfrage fest. Wenn CellValueNeeded einen Wert anfordert, lesen Sie ihn aus der ausgelagerten Projektion. Vermeiden Sie eine Datenbankabfrage für jede Zelle und führen Sie die Formatierung außerhalb dieses Handlers durch.
Wenden Sie das gleiche Prinzip auf andere Steuerelemente an. Laden Sie untergeordnete Baumstrukturen, wenn ihre übergeordneten Elemente erweitert werden, virtualisieren Sie lange Listen, halten Sie Repeater-Vorlagen einfach und aktualisieren Sie nur die geänderten Dashboard-Zeilen.
Während der Baumknoten reduziert ist, behalten Sie eine Anzahl und einen untergeordneten Platzhalter bei. Der Platzhalter behält die Erweiterungssteuerung bei. Erstellen Sie die echten untergeordneten Knoten nur, wenn der Benutzer diesen Zweig öffnet.
Vergleichen Sie die Servermessungen. Das Raster enthält vierzig Zeilenobjekte statt fünfzigtausend. Der Speicher sinkt von 186 auf neun Megabyte und die Verarbeitungszeit sinkt von 1.410 auf 95 Millisekunden. Überprüfen Sie als Nächstes, was sich im Browser geändert hat.
Überprüfen Sie nun den Browserverkehr. Das Grid-Update schrumpft von 4,8 Megabyte auf 96 Kilobyte. Sechs kleinere Updates dienen dem späteren Scrollen. Geben Sie sowohl die Anzahl als auch den Umfang der Anfragen an, damit die Messungen die Gesamtkosten anzeigen.
Für Übung fünf projizieren und virtualisieren Sie das Raster und laden dann bei Bedarf Baumzweige. Verwenden Sie Visual Studio, um den Server zu messen, und das Netzwerkpanel, um den Browserverkehr zu messen. Ihre Beweise sollten beides abdecken.
- LektüreKI-Coding-Übung · 20 Min.
Erstellen Sie das Beispielprojekt OpsMonitor dieses Moduls mit ChatGPT oder Claude aus einem fertigen Prompt, der das Modell auf die Spezifikation des Moduls verweist – und prüfen, starten und erweitern Sie dann, was Sie erhalten, auch im Vergleich mit unserem eigenen Referenz-Build auf GitHub.
- WissenstestWissenstest – Modul 5 · 10 Min. · Bestehensgrenze 80%
- Praktisches LabLab – Virtuelles Grid und verzögert geladener Baum · 45 Min.
Ziel: Verkleinern Sie die beiden größten UI-Flächen in WisejPerfLab. Das Ticket-Grid bindet 50.000 vollständige Entitäten mit Navigationseigenschaften: Ersetzen Sie das Binding durch eine TicketGridRow-Projektion nur der sichtbaren Spalten, setzen Sie VirtualMode und RowCount und liefern Sie die Zellen aus einem CellValueNeeded-Handler, hinter dem ein Service mit seitenweisen Abfragen steht. Der Kundenbaum baut beim Start jeden Knoten auf: Laden Sie die Kindknoten stattdessen beim Aufklappen und verwenden Sie für zugeklappte Zweige einen Platzhalter mit der Anzahl. Messen Sie jede Maske vorher und nachher mit CPU Usage und .NET Object Allocation auf dem Server sowie mit dem Netzwerk-Panel des Browsers für die Größe des Update-Payloads. Ergebnisse: TicketGridRow-Projektion statt vollständiger Entitäten gebunden, nur mit den angezeigten Spalten; Grid im Virtual Mode mit RowCount und einem CellValueNeeded-Handler, der aus einem Service mit seitenweisen Abfragen bedient wird; Kundenbaum, der Kindknoten beim Aufklappen lädt, mit einem Platzhalter mit der Anzahl für zugeklappte Zweige; CPU- und Allokationswerte vorher und nachher für die Szenarien Grid laden und Baum aufklappen; Netzwerkbelege aus dem Browser, die die Größe des Update-Payloads vorher und nachher vergleichen, mit dem Hinweis zur Komprimierung.
Modul 6: Datenbank, Datei-I/O, Async und externe Wartezeiten
Modul 6 von Performance und Profiling – Wisej.NET-Apps messen, profilieren und optimieren, damit Sessions auch bei hoher Last schnell bleiben. Lesen Sie den Lektionsleitfaden und den Lab- und Prüfungsleitfaden, sehen Sie sich den Video-Walkthrough zu Datenbank und Async an, bestehen Sie den Wissenstest und schließen Sie dann das praktische Lab in WisejPerfLab ab.
- LektüreLektionsleitfaden · 14 Min.
Die Latenz, die CPU Usage nicht sieht: das Database-Tool für Abfragezeiten und N+1-Muster, File I/O für Import- und Exportarbeit und .NET Async für Ketten, die blockiert oder versehentlich sequenziell sind. Was das für Wisej.NET-Entwickler bedeutet, die Engpässe in einer produktiven App diagnostizieren – und wie Sie dieses Modul am besten durcharbeiten.
- LektüreLab- und Prüfungsleitfaden · 10 Min.
Was Sie im praktischen Lab bauen, das vorgeschlagene Vorgehen und die geforderten Ergebnisse.
- VideolektionWenig CPU, langsame Maske: das Warten profilieren · 14 Min.
Wenig CPU, langsame Maske: das Warten profilieren – ein geführter Video-Walkthrough zu Modul 6, Schritt für Schritt in WisejPerfLab aufgebaut. Läuft direkt hier im Player.
Transkript der Sprecherstimme
Ein leiser Prozessor kann mit einer langsamen Anwendung einhergehen. Verwenden Sie die frühere Aktualisierungsverfolgung, um die Wartezeit zu untersuchen, anstatt zu versuchen, die Berechnung zu optimieren, die die Verzögerung nicht erklärt.
Führen Sie die fehlende Zeit auf Datenbankoperationen, Dateizugriffe und blockierte Threads zurück. Für diese Wartezeiten sind eigene Messungen erforderlich, da Prozessorbeispiele hauptsächlich die während der Ausführung ausgeführten Arbeiten beschreiben.
Überprüfen Sie, wie der Bildschirm seine Zeilen erhält. Wiederholte Suchvorgänge und überschüssige Felder führen zu vermeidbarer Datenbankarbeit. Durch die gemeinsame Projektion der erforderlichen Felder können mehrere Probleme gleichzeitig behoben werden.
Fügen Sie den Kundennamen in die Abfrage ein und wählen Sie nur die angezeigten Felder aus. Ordnen und paginieren Sie die Ergebnisse, indem Sie nicht verfolgte Lesevorgänge verwenden, wenn der Bildschirm keine Änderungsverfolgung benötigt.
Warten Sie auf Eingabe- und Ausgabevorgänge, damit eine wartende Anforderung einen Thread nicht unnötig belegt. Dies verbessert die Ressourcenverfügbarkeit; Dadurch wird die zugrunde liegende Datenbank oder Festplatte nicht schneller.
Entfernen Sie den blockierenden Ergebniszugriff und streamen Sie den Export, anstatt viele kleine Schreibvorgänge auszuführen. Senden Sie den Fortschritt in sinnvollen Abständen, damit Feedback nicht zu einer weiteren Overhead-Quelle wird.
Vergleichen Sie die Anzahl der Abfragen nach der Änderung. Der Rückgang von zweihundertein Abfragen auf zwei bestätigt diese Korrektur, auch wenn weitere Kosten immer noch verhindern, dass das Szenario sein Budget einhält.
Wiederholen Sie den Export mit gleichzeitigen Sitzungen. Eine Blockierung, die für einen einzelnen Benutzer harmlos erscheint, kann die verfügbaren Threads erschöpfen und unabhängige Bildschirme verzögern, wenn viele Benutzer sie gemeinsam ausführen.
Verbinden Sie jede Abfrage mit ihrer Schnittstellenaktion und vergleichen Sie dann Vorher und Nachher. Erklären Sie, wie die entfernte Datenbank funktioniert und wie der Export eine Blockierung des Klickpfads vermeidet.
- LektüreKI-Coding-Übung · 20 Min.
Erstellen Sie das Beispielprojekt OpsMonitor dieses Moduls mit ChatGPT oder Claude aus einem fertigen Prompt, der das Modell auf die Spezifikation des Moduls verweist – und prüfen, starten und erweitern Sie dann, was Sie erhalten, auch im Vergleich mit unserem eigenen Referenz-Build auf GitHub.
- WissenstestWissenstest – Modul 6 · 10 Min. · Bestehensgrenze 80%
- Praktisches LabLab – Abfrage-Traces und der blockierte Export · 45 Min.
Ziel: Profilieren Sie die beiden wartelastigen Szenarien in WisejPerfLab. Führen Sie die Ticketsuche unter dem Database-Tool aus und ordnen Sie jede Abfrage der UI-Aktion zu: Das Laden des Grids setzt pro angezeigter Zeile eine Kundenabfrage ab, und die Detailabfrage holt große Textspalten, die niemand anzeigt. Ersetzen Sie beide durch eine einzige No-Tracking-Projektionsabfrage, die nur die Grid-Spalten auswählt und das Ergebnis seitenweise liefert. Führen Sie dann den CSV-Export unter File I/O und .NET Async aus, finden Sie den blockierenden .Result-Aufruf im Klick-Handler und die wiederholten kleinen Schreibvorgänge, und verlagern Sie die Erzeugung in einen Application.StartTask-Hintergrund-Workflow, der die Datei streamt und gedrosselten Fortschritt meldet, statt jeden Schritt zu pushen. Ergebnisse: Database-Trace, der Abfragen den UI-Aktionen zuordnet, mit der Anzahl der N+1-Abfragen vor dem Fix; eine einzige No-Tracking-Projektionsabfrage mit Paging anstelle der Abfragen pro Zeile und der zu breiten Abfragen; File I/O- und .NET Async-Belege für den Export, die den blockierenden Aufruf und das Schreibmuster nennen; Export in einen Hintergrund-Task verlagert, der die Ausgabe streamt und Fortschritt nur bei sinnvollen Schritten pusht; Abfrageanzahl, Abfragedauer und Wall-Clock-Zeit des Exports vorher und nachher, mit verbleibenden Risiken.
Modul 7: Skalierung, Health Checks, Load Balancing und abschließendes Tuning
Modul 7 von Performance und Profiling – Wisej.NET-Apps messen, profilieren und optimieren, damit Sessions auch bei hoher Last schnell bleiben. Lesen Sie den Lektionsleitfaden und den Lab- und Prüfungsleitfaden, sehen Sie sich den Video-Walkthrough zu Skalierung und Health Checks an, bestehen Sie den Wissenstest und schließen Sie dann das praktische Lab in WisejPerfLab ab.
- LektüreLektionsleitfaden · 14 Min.
Messwerte in ein Kapazitätsmodell überführen, Schwellenwerte in HealthCheck.json, Session-Affinität und WebSocket-fähiges Load Balancing, Produktivzähler und der abschließende Performance-Bericht, der jede Änderung begründet. Was das für Wisej.NET-Entwickler bedeutet, die Engpässe in einer produktiven App diagnostizieren – und wie Sie dieses Modul am besten durcharbeiten.
- LektüreLab- und Prüfungsleitfaden · 10 Min.
Was Sie im praktischen Lab bauen, das vorgeschlagene Vorgehen und die geforderten Ergebnisse.
- VideolektionVom lokalen Trace zum Kapazitätsmodell · 14 Min.
Vom lokalen Trace zum Kapazitätsmodell – ein geführter Video-Walkthrough zu Modul 7, Schritt für Schritt in WisejPerfLab aufgebaut. Läuft direkt hier im Player.
Transkript der Sprecherstimme
Übersetzen Sie die Profilierungsergebnisse in Betriebsgrenzen. Eine schnellere Anwendung benötigt immer noch eine vertretbare Sitzungskapazität und einen Plan, um neue Benutzer von einem vollen Server wegzuleiten.
Multiplizieren Sie den gemessenen Sitzungsspeicher mit der vorgeschlagenen Sitzungsanzahl und vergleichen Sie ihn mit dem nutzbaren Speicher. Behalten Sie Spielraum bei, da Leerlaufsitzungen nicht jede Spitzenzuweisung beschreiben.
Behalten Sie die Sitzungsaffinität in der gesamten Bereitstellung bei und ermöglichen Sie WebSocket-Upgrades über Proxys. Zustandsbehaftete Kontrollen benötigen den richtigen Server und Live-Updates benötigen einen unterbrechungsfreien Transportpfad.
Legen Sie Gesundheitsschwellenwerte anhand der gemessenen Kapazität fest und nicht anhand bequemer Vermutungen. Die fehlerhafte Antwort und die Anleitung für Wiederholungsversuche geben der Infrastruktur ein Signal, wann die Instanz keine neuen Sitzungen mehr empfangen sollte.
Überwachen Sie das Signal, das jedem behobenen Problem entspricht. Szenariodauer, verwaltete Heap-Größe und Thread-Pool-Warteschlangen weisen unterschiedliche Regressionen auf und sollten nicht als austauschbar behandelt werden.
Schreiben Sie einen Bericht, der das ursprüngliche Szenario mit seiner Ursache, Korrektur und Beweisen verbindet. Beziehen Sie Risiken und Betriebsprüfungen ein, damit ein Kollege die Verbesserung nach der Bereitstellung überprüfen kann.
Beobachten Sie, was passiert, wenn Instanz A ihre Kapazität erreicht. Neuer Datenverkehr wandert in Richtung Instanz B, während bestehende Sitzungen weiterlaufen, wodurch die Zugangskontrolle von der Störung bestehender Benutzer getrennt wird.
Vergleichen Sie jedes Szenario mit seinem ursprünglichen Budget. Markieren Sie den Export als Risiko, da ein fehlendes Ziel und eingeschränkte Parallelitätstests eine bestandene Behauptung nicht stützen können.
Stellen Sie die Kapazitätsberechnung, die Gesundheitskonfiguration, Bereitstellungshinweise und den reproduzierbaren Bericht zusammen bereit. Für den Betrieb sind sowohl die gewählten Grenzwerte als auch Belege erforderlich, die erklären, warum diese Grenzwerte angemessen sind.
- LektüreKI-Coding-Übung · 20 Min.
Erstellen Sie das Beispielprojekt OpsMonitor dieses Moduls mit ChatGPT oder Claude aus einem fertigen Prompt, der das Modell auf die Spezifikation des Moduls verweist – und prüfen, starten und erweitern Sie dann, was Sie erhalten, auch im Vergleich mit unserem eigenen Referenz-Build auf GitHub.
- WissenstestWissenstest – Modul 7 · 10 Min. · Bestehensgrenze 80%
- Praktisches LabLab – Kapazitätsmodell und Abschlussbericht · 45 Min.
Ziel: Liefern Sie das WisejPerfLab-Abschlussprojekt ab. Leiten Sie aus Ihren eigenen Messungen ein Kapazitätsmodell ab: gehaltener Speicher pro inaktiver Session, CPU pro häufigem Szenario, erwartete Spitzenlast an gleichzeitigen Sessions und die Reserve, die Sie einplanen. Schreiben Sie eine HealthCheck.json, deren maxSessions, maxMemory und maxCPU aus diesen Zahlen stammen, begründen Sie jeden Schwellenwert und geben Sie 503 mit retry-after zurück, damit ein Load Balancer neue Benutzer anderswohin leitet, während bestehende Sessions weiterlaufen. Schreiben Sie die Deployment-Notizen für zwei Instanzen hinter einem Load Balancer mit Session-Affinität und WebSocket-Unterstützung und stellen Sie den Abschlussbericht zusammen: Szenarien, Umgebung, Baseline-Belege, Ursachen, Änderungen, Belege nachher, verbleibende Risiken und die Produktivzähler, die zeigen, falls eine Regression zurückkehrt. Ergebnisse: Kapazitätsmodell, das die Sessions pro Server aus dem gemessenen Speicher pro Session und der CPU pro Szenario ableitet; HealthCheck.json mit maxSessions, maxMemory, maxCPU, Rückgabecode und retry-after, jeder Schwellenwert begründet; Deployment-Notizen zu Session-Affinität, WebSocket-Unterstützung und dem Polling-Fallback; abschließender Performance-Bericht mit Baseline, Ursache, Änderung und Belegen nachher für jeden Fix aus den Modulen; Monitoring-Plan, der die Zähler, Schwellenwerte und Alarme nennt, die jede Regression erkennen würden.