Analyse von .NET-Anwendungen mit Visual-Studio-Bordmitteln

Was läuft hier eigentlich?
Kommentare

Mit dem Performance and Diagnostics Hub, der in Visual Studio 2013 eingeführt wurde, hat der Entwickler einen zentralen Zugangspunkt zu verschiedenen Profiling-Tools. Dieser Artikel gibt einen Überblick über die Funktionsweise des Performance and Diagnostics Hubs und erläutert, welches Tool sich für welchen Einsatz eignet.

Die Analysewerkzeuge, die in Visual Studio 2013 vorhanden sind, bieten ein enormes, oft unterschätztes Potenzial. Sie ermöglichen Einsichten in .NET-Anwendungen, die ohne die Tools nur sehr aufwändig zu gewinnen wären. Allerdings gibt es noch immer viele Entwickler, die die Profiling-Tools von Visual Studio nicht benutzen oder nicht kennen. Woran liegt das? Der Hauptgrund mag sein, dass der Profiler bis Visual Studio 2010 ausschließlich in den Premium- und Ultimate-Ausgaben zur Verfügung stand. Für die große Zahl der Entwickler war er deshalb kein Thema, und sie mussten auf kostenpflichtige Drittherstellerprodukte wie die Profiler von JetBrains oder Redgate zurückgreifen.

Doch das hat sich geändert, als Microsoft entschied, den Profiler ab der Version 2012 von Visual Studio in allen Editionen von Professional bis Ultimate auszuliefern. Mit Visual Studio 2013 ging das Visual-Studio-Team noch einen Schritt weiter, denn in vorigen Versionen waren die Profiling- und Analysewerkzeuge über verschiedene Menüs verteilt. In Visual Studio 2013 wurden sie an einer zentralen Stelle, dem Performance and Diagnostics Hub, zusammengefasst (Abb. 1), der sich über das Hauptmenü analyze | Performance and Diagnostics öffnen lässt. Neben der Zusammenfassung wurden die Werkzeuge zudem um neue Tools für die Analyse von Apps für den Windows Store oder das Windows Phone erweitert.

Abb. 1: Der Perfomance and Diagnostic Hub

Abb. 1: Der Perfomance and Diagnostic Hub

 

Tabelle 1 gibt einen Überblick über die zur Verfügung stehenden Tools und zeigt, welches Tool für welchen Anwendungstyp eingesetzt werden kann. Nach der Erläuterung der Profiling-Grundlagen wird die Funktionsweise der Tools aufgezeigt. Am Ende des Artikels wird in einem Praxisbeispiel eine Performanceanalyse beschrieben.

Tabelle 1: Übersicht der pro Applikationstyp verfügbaren Tools (Stand: Visual Studio 2013 Update 4).

Tabelle 1: Übersicht der pro Applikationstyp verfügbaren Tools (Stand: Visual Studio 2013 Update 4).

Profiling: Sampling, Instrumentation und ETW

Zunächst stellt sich die Frage, was genau unter Application Profiling zu verstehen ist. Im Buch „Practical Performance Profiling“ von Jean-Philippe Gouigoux hält der Autor eine passende Definition bereit: „Using test strategies and a specialized toolset, a developer attempts to find all the bottlenecks in the code, and corrects them.“

Es geht also darum, die Flaschenhälse im Code mithilfe einer Strategie und einem spezialisierten Toolset zu finden und zu beheben. Das Thema Profiling-Strategie ist so umfassend, dass es ein ganzes Buch füllen würde. Deshalb geht dieser Artikel nur auf die zweite Komponente ein, das Toolset. Die in diesem Artikel vorgestellten Werkzeuge können von der Vorgehensweise her grob in drei Kategorien eingeteilt werden:

  1. Sampling
  2. Instrumentierung
  3. Event Tracing for Windows (ETW)

Der klassische Visual-Studio-Profiler, auch Performance-Wizard genannt, benutzt für das Sammeln der Daten die gängigen Profiling-Techniken Sampling und Instrumentierung. Beim Sampling wird der Prozessor in fixen Zeitintervallen angehalten, und es werden für jeden Prozessorkern die Methoden aufgezeichnet, die von diesem gerade verarbeitet werden. Diese Aufzeichnungen werden statistisch ausgewertet, und es wird ermittelt, zu welcher Zeit und vor allem wie lange eine bestimmte Methode ausgeführt wurde. Sampling ist ein sehr einfaches Vorgehen und hat nur minimalen Einfluss auf die zu untersuchende Applikation. Es bietet sich an, um einen Überblick über die Anwendungsperformance zu bekommen oder um prozessorintensive Anwendungen genauer zu erkunden.

Bei der Instrumentierung wird Code in die Assembly injiziert. Dieser Code zeichnet zur Laufzeit für alle Methoden exakt auf wann, wie oft und wie lange die Methoden ausgeführt wurden. Der große Vorteil der Instrumentierung ist, dass es sich um eine exakte Messung handelt. Im Gegensatz dazu handelt es sich beim Sampling lediglich um eine statistische Annäherung an die tatsächlichen Werte. Eine weitere Stärke der Instrumentierung ist, dass die gemessenen Zeiten nicht allein auf die Prozessoraktivität beschränkt sind. Das bedeutet, dass die Resultate auch zeigen, wenn der Code beispielsweise auf Disk-I/O, Netzwerkzugriff oder Antworten externer Systeme warten muss. Der große Nachteil der Instrumentierung ist, dass die Messresultate durch die Instrumentierung selbst beeinflusst werden können. Im schlimmsten Fall kann es auch vorkommen, dass die Instrumentierung einen negativen Einfluss auf die Anwendung selbst hat. Deshalb eignet sie sich sehr gut für Probleme, die auf externe Systeme (Disk, Netzwerk, Web Services etc.) zurückzuführen sind. Auch für die detailliertere Analyse eines bestimmten Applikationsteils kann die Instrumentierung eine große Hilfe sein.

Die anderen Tools aus dem Performance and Diagnostics Hub basieren auf Event Tracing for Windows, kurz ETW genannt. ETW ist eine tief im Windows-Kernel implementierte Tracing-Plattform, die nach dem Publish-Subscribe-Verfahren funktioniert. ETW ermöglicht es beliebigen Komponenten im Windows-Ökosystem, Events abzusetzen, die von Empfängern nach Bedarf abonniert werden können. Dabei ist das gesamte System darauf ausgelegt, in sehr kurzer Zeit und mit minimalstem Einfluss auf die Beteiligten oder das Betriebssystem eine hohe Anzahl an Meldungen zu verarbeiten. Mittlerweile ist ETW so weit in Windows integriert, dass es eine unüberschaubare Anzahl an ETW-Events gibt. Es gibt sogar die Möglichkeit, eigene Events programmatisch an die ETW-Infrastruktur zu übergeben, beispielsweise in einer C#-Anwendung. Bevor der Performance and Diagnostics Hub in Visual Studio 2013 eingeführt wurde, war es sehr umständlich, Daten aus ETW aufzuzeichnen. Die Tools, die dafür zur Verfügung stehen, sind das Performance-Analyzer-Command-Line-Tool (xperf.exe) für die Aufzeichnung und der Windows Performance Analyzer (wpa.exe) für die Darstellung und Analyse. Beide sind Bestandteile des Windows Performance Toolkits (WPT). Dieses wiederum gibt es entweder im Windows Software Development Kit (SDK) oder im Windows Assessment and Deployment Kit (WADK). Die Tools sind schon bezüglich der Installation eine Herausforderung und erfordern einiges an Erfahrung, um effizient eingesetzt werden zu können. Mit den neuen Performancetools in Visual Studio gestaltet sich die Auswertung von ETW-Daten hingegen sehr angenehm. Das Tool GPU Usage beispielsweise fragt die relevanten ETW-Events ab, korreliert diese mit weiteren Datenquellen und bereitet die konsolidierten Daten grafisch anspruchsvoll auf.

Profiling starten

Das Vorgehen ist für alle Profiling-Tools identisch. Allerdings funktionieren sie nur, wenn Visual Studio mit administrativer Berechtigung ausgeführt wird. Im ersten Schritt wird der Performance and Diagnostics Hub geöffnet. Dies geschieht über das Menü analyze | Performance and Diagnostics (alternativ Debug | Performance and Diagnostics) oder die Tastenkombination ALT + F2. Danach kann die Zielanwendung, im folgenden Target genannt, ausgewählt werden. Folgende Targets stehen zur Verfügung:

  • Startup Project: Analysiert das in der Solution konfigurierte Start-up-Projekt.
  • Running App: Analyse einer laufenden Windows-Store-App auf dem lokalen oder einem Remote-Rechner.
  • Installed App: Analyse einer installierten Windows-Store-App.
  • Internet Explorer on Windows Phone: Profiling einer Website im Internet Explorer auf dem Windows Phone.
  • Executable: Analyse einer ausführbaren Assembly (*.exe).
  • ASP.NET: Profiling einer Webapplikation auf dem lokalen IIS.

Durch die Selektion des Targets zeigt Visual Studio automatisch, welche Tools für diesen Applikationstyp verwendet werden können. Durch die Selektion eines oder mehrerer Tools und dem Klick auf Start beginnt das Profiling. Die Applikation erscheint und der Entwickler kann Benutzeraktivität simulieren. Sobald die Applikation beendet oder der Stopp-Knopf gedrückt wird, bricht Visual Studio die Aufzeichnung ab und bereitet die Daten zu einem Bericht auf. Nach der Analyse des Berichts kann dieser zur späteren Auswertung oder zum Vergleich mit einem anderen Bericht gespeichert werden.

Übersicht über die Tools

In Visual Studio 2013 Update 4 stehen uns neun verschiedene Tools zur Verfügung. Im folgenden Abschnitt wird deren Funktionsweise erklärt.

Performance-Wizard

Der Performance-Wizard ist der klassische Profiler und schon seit längerer Zeit in Visual Studio vorhanden. Er erstellt eine Performancesession und bietet folgende Analysevarianten: CPU-Sampling, Instrumentation, .NET Memory Allocation und Concurrency.

Der Performance-Wizard wurde in Visual Studio 2013 ohne Änderung übernommen und passt deshalb nicht exakt zur Philosophie des Hubs. In den kommenden Versionen von Visual Studio werden die Features des Performance-Wizards tiefer in den Hub eingebaut. Eine detaillierte Beschreibung des Performance-Wizards gibt es im MSDN.

JavaScript Function Timing

Das JavaScript-Function-Timing-Tool misst die Ausführungszeiten im JavaScript-Code, indem Anfang und Ende von Methodenaufrufen aufgezeichnet werden. Die Resultate der Aufzeichnung sind tabellarische und grafische Darstellungen dieser Messungen. Mit Visual Studio 2013 Update 2 wurde das CPU-Usage-Tool eingeführt, das in etwa die gleichen Daten misst wie das JavaScript-Function-Timing-Tool und dieses somit ersetzt.

CPU Usage

Das CPU-Usage-Tool kann für Desktopanwendungen und Windows-Store-Apps gleichermaßen benutzt werden. Während der Aufzeichnung wird die CPU-Auslastung durch Sampling ermittelt und als Livegrafik angezeigt. Das CPU-Usage-Tool ist vor allem dann sinnvoll, wenn es sich um eine rechenintensive Anwendung handelt. Durch Analyse und eventuellem Redesign der Codestellen mit hohem CPU-Verbrauch kann die Anwendung optimiert werden.

GPU Usage

Das GPU-Usage-Tool analysiert Anwendungen, die ihre Grafik über die DirectX-Grafikschnittstelle zeichnen. In der aktuellen Version werden Windows-Desktop- und Store-Apps unterstützt. Das Tool bietet sich besonders für grafikintensive 2-D- oder 3-D-Anwendungen an, wie beispielsweise WPF-Applikationen oder Spiele. Ziel der Analyse ist es, herauszufinden, wie die Applikation die Nutzung der CPU und der GPU aufteilt und auf welchem der beiden Prozessoren sich möglicherweise ein Flaschenhals bildet. Für den Fall, dass im Rechner eine unterstützte Grafikkarte vorhanden ist, können sogar herstellerspezifische (Intel, Nvidia, AMD) Grafikkarten-Events aufgezeichnet und ausgewertet werden.

XAML/HTML UI Responsiveness

Das Mantra „Fast and Fluid“, das wichtiger Bestandteil der Windows-Store-App-Design-Guidelines ist, besagt, dass sich eine Windows-Store-App für den Benutzer immer flüssig anfühlen muss. Das heißt, Navigation, Scrolling, Zooming und Animation dürfen keine spürbaren „Ruckler“ zeigen. Die beiden ausschließlich für Windows-Store-Apps verfügbaren Tools XAML UI Responsiveness und HTML UI Responsiveness analysieren, wie flüssig die User Experience einer Anwendung tatsächlich ist. Mit den beiden Tools lässt sich sowohl eine lokal, remote oder auch im Simulator ausgeführte Windows-Store-App analysieren.

Bei der UI-Responsiveness geht es darum, dass der UI-Thread jederzeit genügend Ressourcen zur Verfügung hat, um auf Anfragen des Benutzers oder des Systems sofort reagieren zu können. Im Beispiel einer XAML-basierten Windows-Store-App gibt das Tool präzise Auskunft darüber, wie viel CPU der UI-Thread für die XAML-Verarbeitung verbraucht. Weiter zeigt es detailliert auf, welche anderen Aktivitäten den UI-Thread beschäftigt haben. Dabei wird zwischen Parsing von XAML, Layout, App-Code und anderer XAML-Aktivität unterschieden. Anhand dieser Angaben können Rückschlüsse über Stellen mit Optimierungspotenzial getroffen werden.

Im Fenster „Visual Throughput in Frames per Second“ zeigt das Tool, wie die Last zur Darstellung des Inhalts auf dem Bildschirm über die Ausführungszeit verteilt ist. Die zwei Tabellen Parsing und Hot Elements zeigen, wie viel Zeit das Auslesen der XAML-Dateien benötigt hat bzw. wie viel Zeit jedes einzelne Element aus dem Visual Tree für das Rendering verbraucht hat.

Memory Usage/JavaScript Memory

Die Memory-Usage-Tools stehen ausschließlich für Windows-Store-Apps zur Verfügung. Sie können für Apps eingesetzt werden, die in VB, C#, C++ oder JavaScript geschrieben wurden. Die beiden Hauptfunktionen sind das Analysieren des Speicherverbrauchs einer Anwendung zur Laufzeit und die Arbeit mit Snapshots. Snapshots sind Momentaufnahmen des aktuellen Speicherverbrauchs. Durch den Vergleich mehrerer Snapshots kann der Entwickler komplexeren Problemen wie Memory Leaks auf den Grund gehen. Die Snapshots geben detaillierte Einsicht in den Speicherverbrauch. Dabei ist ersichtlich, von welchen Typen es wie viele Instanzen gibt und wie viel Speicher diese belegen. Neben Anzahl und Größe zeigt das Tool auch, wie die Objekte sich gegenseitig referenzieren. Die Tabelle Paths to Root Tree gibt Auskunft über die Referenzketten, die zwischen den Objekten bestehen. Referenzketten sind besonders dann wichtig, wenn Objekte nicht vom Garbage Collector weggeräumt werden können, da sie noch referenziert werden.

Energy Consumption Profiler

Im Zeitalter der mobilen Softwareentwicklung stehen die Entwickler vor neuen Herausforderungen. Die Programmierung von Apps, die Tablets oder Mobiltelefone als Zielplattform haben, muss nicht nur bezüglich der Performance und dem Speicherverbrauch, sondern auch bezüglich des Stromverbrauchs optimiert werden. Der Energy Comsumption Profiler steht für Windows-Store- und Phone-Apps zur Verfügung. Er zeichnet sämtliche Aktivitäten von Anzeige, Prozessor und Netzwerkschnittstelle auf und berechnet anhand von Heuristiken, wie groß deren Energieverbrauch sein könnte.

Der Energy Comsumption Profiler misst Power und Energy Das Tool unterscheidet zwischen Power und Energy: Power bezeichnet die Leistung, die von der App gefordert wird. In der Physik ist Leistung bekanntlich definiert als Energieumsatz pro Zeiteinheit und wird in Watt angegeben. Der Energy Consumption Profiler macht hier keine Ausnahme und verwendet Milliwatt (mW) als Maßeinheit. Die Power wird in einem Liniendiagramm für die drei Verbraucher Display, Prozessor und Netzwerk kombiniert angezeigt. Energy bezeichnet den Strom- bzw. Energieverbrauch über die gesamte Zeit der Messung. Der Energy Consumption Profiler zeigt am Ende der Messung, wie viele Milliwattstunden (mWh) von der Batterie bezogen wurden und wie sich die Zahl auf die drei Verbraucher aufteilt. Zusätzlich wird angezeigt, wie lange eine Standardbatterie mit diesem Verbrauch halten würde.

Praxisbeispiel

Im folgenden Beispiel wird die Windows-Store-App Bing Finance untersucht. Ein interessanter Trick ist die Kombination verschiedener Tools aus dem Performance and Diagnostics Hub. Wir wählen CPU Usage, HTML UI Responsiveness und Energy Consumption. Sobald die App gestartet ist, selektieren wir die Nestlé-Aktie und scrollen durch die angegebenen Kennzahlen durch. Danach beenden wir die App, und der Performancereport wird erstellt (Abb. 2).

Abb. 2: Die Resultate der Profiling-Session

Abb. 2: Die Resultate der Profiling-Session

 

Im oberen Teil sehen wir die drei Grafiken für CPU Utilization, Visual Throughput und Power Usage. Die CPU Usage wird für uns aufgeschlüsselt nach Aktivitäten wie Laden von Daten (HTTP-Requests), Scripting (Ausführung von JavaScript-Code), Garbage Collection, Styling (CSS), Rendering und Image Decoding.

Die Visual-Throughput-Grafik zeigt uns, an welchen Stellen die Framerate gefallen ist und wir in der App möglicherweise ein „Ruckeln“ feststellen konnten. Die Power-Usage-Grafik zeigt auf, dass der Energieverbrauch der App, wie zu erwarten, stark mit der CPU-Auslastung korreliert.

Die Nestlé-Charts werden etwa ab Sekunde 13 angezeigt. Durch Selektion und Zoom der Zeitspanne von Sekunde 13 bis Sekunde 15 bekommen wir eine detailreichere Ansicht (Abb. 3).

Abb. 3: Zoom für mehr Details

Abb. 3: Zoom für mehr Details

 

Nun gibt es viele Ansätze zur weiteren Analyse. Einer wäre, dass wir uns auf die Stellen konzentrieren, an denen die Framerate stark gesunken ist und ermitteln, welche Aktivität dort ausgeführt wurde. Wir wählen aber einen anderen Ansatz und suchen zuerst die Aktivitäten, die im Verhältnis zum Rest sehr viel Leistung verbraucht haben. Dafür schauen wir uns das UI Thread Summary in der unteren rechten Ecke an (Abb. 4).

Abb. 4: Das UI Thread Summary

Abb. 4: Das UI Thread Summary

Dort stellen wir fest, dass mit 27 Prozent der größte Teil für das Styling verbraucht wurde, gefolgt von Wartezeit (21 Prozent) und Timer-Aufrufen (19 Prozent). Durch einen Blick in die Timelinedetails im unteren rechten Fenster erkennen wir, dass es einen Timeraufruf gibt, der mit langen 500 Millisekunden gemessen wurde (Abb. 5). Wir können den Knoten aufklappen und weiter erkunden, welche Aktivitäten für die gesamten 500 Millisekunden verantwortlich sind (Abb. 6). Sobald die Hotspots ermittelt sind, wissen wir, welche Stellen im Code optimiert werden können. Mit einer weiteren Messung würden wir die Resultate überprüfen und bestätigen, dass unsere Maßnahmen die gewünschte Wirkung erzielen.

Abb. 5: Die Timelinedetails

Abb. 5: Die Timelinedetails

Abb.6: Gemessene Aktivitäten im Detail

Abb.6: Gemessene Aktivitäten im Detail

Fazit

Mit der Einführung des Performance and Diagnostics Hubs geht es in Sachen Profiling von .NET-Anwendungen einen großen Schritt voran. Die Tools im Hub eröffnen jedem Entwickler die mächtige Event-Tracing-for-Windows-(ETW-)Infrastruktur und bieten hervorragende Möglichkeiten zur Analyse aller Anwendungstypen. Visual Studio bietet uns Tools für die Analyse von ASP.NET, Windows-Desktop und Store-Apps bis hin zu Windows-Phone-Anwendungen.

Es bleibt spannend, denn es ist davon auszugehen, dass über die nächsten Updates und Versionen von Visual Studio viele weitere interessante Tools Einzug in den Performance and Diagnostics Hub erhalten werden.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -