.NET-Leistung

Leistungsdiagnosen für .NET-Anwendungen mittels ETW

Subramanian Ramaswamy

Beispielcode herunterladen

Sie erstellen eine verwaltete Anwendung und testen sie – und sie ist langsam. Ihre Anwendung ist in funktionaler Hinsicht korrekt, die Leistung lässt jedoch zu wünschen übrig. Sie würden die Leistungsprobleme gerne diagnostizieren und lösen. Die Anwendung wird jedoch in einer Produktionsumgebung ausgeführt, sodass Sie keine Profilierungstools installieren oder die Ausführung der Anwendung unterbrechen können. Oder Ihre Anwendung wird nicht häufig genug verwendet, sodass die Anschaffung von Visual Studio Profiler für die CPU-Profilerstellung gerechtfertigt wäre.

Glücklicherweise kann Event Tracing for Windows (ETW) diese Probleme für Sie lösen. Diese leistungsfähige Protokollierungstechnologie ist in zahlreiche Komponenten der Windows-Infrastruktur integriert und wird im Microsoft .NET Framework 4 CLR genutzt, um die Profilerstellung für Ihre verwaltete Anwendung einfacher zu gestalten. ETW erfasst die Systemdaten und erstellt Profile sämtlicher Ressourcen (CPU, Festplatte, Netzwerk und Speicher). So erhalten Sie eine umfassende Übersicht. Die ETW-Umgebung kann außerdem angepasst werden, sodass sie wenig Overhead verursacht. Damit ist das Tool für die Produktionsdiagnose geeignet.

Mit diesem Artikel sollen Ihnen Informationen zu den Möglichkeiten bereitgestellt werden, die Ihnen ETW für die Profilierung Ihrer verwalteten Anwendung bietet. Ich werde nicht alle Themen hier behandeln. Es gibt einige Betriebssystemereignisse und CLR-ETW-Ereignisse, die zu Diagnosezwecken verfügbar sind, die wir nicht betrachten werden. Sie werden jedoch erfahren, wie die Leistung und Funktionalität Ihrer verwalteten Anwendung mittels des ETW-Systems deutlich verbessert werden können. Für die ersten Schritte mit der ETW-basierten Diagnose für Ihren verwalteten Code zeige ich eine Beispieluntersuchung mittels des kostenlos verfügbaren ETW-Tools, das Sie von bcl.codeplex.com/releases/view/49601 herunterladen können.

PerfMonitor

PerfMonitor ermöglicht Ihnen die schnelle und einfache Erfassung von ETW-Leistungsdaten und die Generierung nützlicher Berichte. Das Tool soll keine tiefgehenden Analysetools wie Visual Studio Profiler ersetzen, soll Ihnen jedoch eine Übersicht über die Leistungsmerkmale der Anwendung bieten und einige schnelle Analysen ermöglichen.

Es gibt ein weiteres Tool für ETW-Diagnosen namens XPerf, das kostenlos mit dem Windows Performance Toolkit verfügbar ist. XPerf ist zwar hervorragend für die Profilerstellung für systemeigenen Code auf Windows geeignet, verfügt jedoch über keine tiefgehende Unterstützung für die Profilerstellung für verwalteten Code. PerfMonitor stellt Ihnen hingegen den gesamten Leistungsumfang der Profilerstellung für verwalteten Code mittels ETW bereit. PerfMonitor kann symbolische Informationen erfassen, die mit dem Laufzeitcode von .NET Framework verknüpft sind, und ist daher für Untersuchungen der Leistung von .NET Framework nützlich. Es unterstützt jedoch keine der tiefgehenden Analysen, die XPerf leisten kann.

PerfMonitor ist ein vollständig unabhängiges Tool und verfügt über sämtliche Funktionen, die Sie für Profilerstellung und Diagnose in Bezug auf Ihre verwaltete Anwendung benötigen. Die einzige weitere Voraussetzung ist, dass Sie mindestens Windows Vista oder Windows Server 2008 ausführen müssen. PerfMonitor ist ein Befehlszeilentool, und durch die Eingabe von „PerfMonitor.exe usersGuide“ am Speicherort wird eine Übersicht angezeigt. Wenn Sie einen Kunden haben, dessen Programm Sie unter Betriebsbedingungen diagnostizieren möchten – zum Beispiel auf einem Produktionsserver – müssen Sie nur die Datei auf diesen Computer kopieren und können mit der Erfassung von Profilen beginnen. Die Profile können offline analysiert werden, wenn nötig.

Während einer Leistungsuntersuchung werden in der Regel vier Faktoren betrachtet: CPU, Festplatten-I/O, Speicher und Skalierbarkeit. Die meisten Untersuchungen beginnen mit der CPU. Diese hat Auswirkungen auf die Start- und Ausführungszeit der Anwendung. Die Untersuchung der Festplatten-I/O ist am nützlichsten, wenn Sie lange Startzeiten analysieren (die Festplatten-I/O ist ein wesentlicher Faktor für die Kaltstartzeit, die Zeit, die eine Anwendung zum Starten benötigt, wenn sie nicht im Speicher vorhanden ist, wie z. B. nach einem Neustart). Ein übermäßiger Speicherverbrauch (oder Lecks) kann dazu führen, dass die Anwendung mit der Zeit immer langsamer ausgeführt wird. Die Skalierbarkeit spielt eine Rolle, wenn der Durchsatz der Anwendung relativ zur Anzahl der Prozessoren zunehmen soll.

PerfMonitor hilft Ihnen, sich schnell einen Überblick über all diese Faktoren zu verschaffen, außer der Skalierbarkeit, und stellt Ihnen außerdem genügend Informationen bereit, um mittels anderer spezialisierter Tools fundiertere Analysen zu erstellen. Wenn Sie z. B. Probleme mit dem CLR .NET-Speicherbereinigungsheap diagnostizieren möchten, ist der CLRProfiler die bessere Wahl. PerfMonitor informiert Sie jedoch schnell über Probleme und ob Sie mittels anderer Tools weitere Untersuchungen durchführen müssen. In einigen Fällen identifiziert PerfMonitor das Problem bereits und stellt Ihnen alle Informationen bereit, die Sie für die Behebung eines Leistungsproblems benötigen, wie Sie gleich sehen werden. Lesen Sie die CLR Inside Out-Kolumne „Prüfung der Speichernutzung für .NET-Anwendungen“ (msdn.microsoft.com/magazine/dd882521), in der die Bedeutung von Prüfungen der Speichernutzung und der Planung der Leistung für Ihr Programm besprochen werden. In Erweiterung dieser Philosophie ermöglicht PerfMonitor Ihnen die schnelle Prüfung zahlreicher Leistungsaspekte Ihres verwalteten Programms, und nicht nur des Speichers.

Eine Beispieluntersuchung: CsvToXml

Das Beispielprogramm, das ich mittels ETW diagnostizieren werde, konvertiert CSV-Dateien in XML-Dateien. Der Quellcode ist zusammen mit dem Lösungspaket (und einer Beispiel-SCV-Datei namens „data.csv“) auf code.msdn.microsoft.com/mag201012ETW verfügbar. Zur Ausführung des Programms führen Sie den Befehl "CsvToXml.exe data.csv output.xml“ aus.

Wie viele andere Programme auch, wurde CsvToXml schnell geschrieben, und der Entwickler sah nicht voraus, dass es für große CSV-Dateien verwendet werden würde. Als ich es in der Praxis verwendete, stellte sich heraus, dass es zu langsam war. Es benötigte mehr als 15 Sekunden, um eine Datei mit 750 KB zu verarbeiten! Ich wusste, dass es ein Problem geben musste. Ohne ein Tool für die Profilerstellung konnte ich über den Grund für die Langsamkeit jedoch nur Vermutungen anstellen. (Können Sie den Grund erkennen, wenn Sie sich den Quellcode ansehen?) Glücklicherweise kann Ihnen PerMonitor dabei helfen.

Generieren und Anzeigen der Programmablaufverfolgung

Der erste Schritt besteht in einer schnellen Prüfung der Anwendung, indem der folgende Befehl in einem Fenster für die Befehlseingabe durch Administratoren ausgeführt wird (ETW erfasst die Daten systemweit, weswegen Administratorrechte erforderlich sind):

PerfMonitor runAnalyze CsvToXml.exe data.csv out.xml

Damit wird die ETW-Protokollierung gestartet, die CsvToXml.exe ausgeführt, auf den Abschluss der Ausführung von CsvToXml gewartet, die Protokollierung gestoppt und schließlich eine Webseite angezeigt, auf der die Analyse für CsvToXml angezeigt wird. Mit einem einfachen Schritt haben Sie umfassende Daten zur Verfügung, die Ihnen helfen, die Engpässe in CsvToXml ausfindig zu machen.

Das Ergebnis dieses Befehls wird in Abbildung 1 gezeigt. Die Seite enthält neben anderen Daten die Prozess-ID, die verwendete Befehlszeile und die Analyse der Leistungsdaten einschließlich CPU-Statistiken, Speicherbereinigungsstatistiken und Just-in-Time (JIT)-Statistiken. PerfMonitor stellt Ihnen auch eine anfängliche Analyse mit Angaben dazu bereit, wo Sie mit der Diagnose beginnen sollten, und enthält nützliche Links zu Artikeln mit Informationen oder anderen Tools.

Abbildung 1 Leistungsanalyse für CsvToXml

Der Bericht zeigt, dass die Formatkonvertierung beinahe 14 Sekunden benötigte. 13,6 Sekunden hierfür wurden von der CPU benötigt, mit einer durchschnittlichen Nutzung von 99 Prozent. Das Szenario war also CPU-basiert.

Die insgesamt für die Speicherbereinigung und die Speicherbereinigungspause benötigte Zeit ist gering, was gut ist. Die maximale Speicherbereinigungszuweisungs-Geschwindigkeit beträgt jedoch 105,1 MB/s, was sehr viel ist und weiterer Untersuchungen bedarf.

CPU-Analyse

Die detaillierte CPU-Analyse stellt die Details für die von der CPU benötigte Zeit dar, wie in Abbildung 2 gezeigt, und es gibt drei Möglichkeiten, wie die Profildaten für die CPU gelesen werden können. Die Sicht von unten nach oben zeigt Ihnen schnell, welche Methoden die meiste CPU-Zeit beanspruchen und daher zuerst analysiert werden sollten. Die Sicht von oben nach unten ist nützlich, um herauszufinden, ob Architektur- oder Strukturänderungen für den Code erforderlich sind, und hilft Ihnen, die Leistung des Programms insgesamt zu verstehen. Die Aufrufer-Aufgerufener-Sicht zeigt die Beziehung zwischen den Methoden an, z. B. welche Methoden welche Methoden aufrufen.

Abbildung 2 Analyse von unten nach oben von CsvToXml.exe

Wie andere Tools für die CPU-Profilerstellung, zeigt PerfMonitor die inklusive Zeit (die Zeit, die in einer bestimmten Methode verbracht wird, einschließlich der Zeit, die in den von dieser aufgerufenen Methoden verbracht wird) und die exklusive Zeit an (die Zeit, die in einer bestimmten Methode verbracht wird, ausschließlich der Zeit, die in den von dieser aufgerufenen Methoden verbracht wird). Wenn die inklusive und die exklusive Zeit gleich sind, wird die Aufgabe in dieser bestimmten Methode durchgeführt. PerfMonitor stellt außerdem einen CPU-Nutzungsgraphen bereit, der die CPU-Nutzung über die Zeit für eine bestimmte Methode darstellt. Wenn Sie mit dem Mauszeiger auf die Spaltenüberschriften des Berichts zeigen, werden Ihnen Details zu deren Bedeutungen angezeigt.

Die meisten Leistungsuntersuchungen beginnen mit der Sicht von unten nach oben. Dies ist die Auflistung der Methoden nach exklusiver Zeit (diese Sicht wird in Abbildung 2gezeigt). Nach der Auswahl der Sicht von unten nach oben können Sie erkennen, dass „mscorlib method System.IO.File.OpenText“die Methode ist, die die CPU am meisten beansprucht. Durch Klicken auf diesen Link wird die Aufrufer-Aufgerufener-Sicht für die OpenText-Methode angezeigt. Sie können sehen, dass die CsvToXml.CsvFile.get_ColumnNames-Methode OpenText aus dem Programm aufruft, und dass „get_ColumnNames“ beinahe 10 Sekunden der von der CPU benötigten Zeit verbraucht (Abbildung 3). Außerdem wird diese Methode von „CsvToXml.CsvFile.XmlElementForRow“ in einer Schleife aufgerufen (XmlElementForRow selbst wird von der Main-Methode aufgerufen).

Abbildung 3 Aufrufer-Aufgerufener-Sicht für get_ColumnNames

Es scheint, als ob in diesen Methoden etwas fehlt. Die Betrachtung des Codes dieser Methoden führt Sie zur Ursache des Problems, wie in Abbildung 4 gezeigt: Die Datei wird in einer Schleife geöffnet und analysiert!

Abbildung 4 ColumnNames-Methode wird durch XmlElementForRow-Methode aufgerufen

public string[] ColumnNames
{
  get
  {
    using (var reader = File.OpenText(Filename))
      return Parse(reader.ReadLine());
  }
}

public string XmlElementForRow(string elementName, string[] row)
{
  string ret = "<" + elementName;
  for (int i = 0; i < row.Length; i++)
    ret += " " + ToValidXmlName(ColumnNames[i]) + "=\"" + EscapeXml(row[i]) + "\"";
  ret += "/>";
  return ret;
}

Ähnliche Szenarien gibt es häufiger als Sie vermuten. Als die Methode geschrieben wurde, nahm der Entwickler vielleicht an, dass sie nur selten aufgerufen wird (wie es der Fall mit ColumnNames ist), und legte daher keinen großen Wert auf die Leistung. Häufig jedoch ergeben sich zu einem späteren Zeitpunkt Situationen, die dazu führen, dass die Methode in einer Schleife aufgerufen und die Leistung der Anwendung beeinträchtigt wird.

In einer CSV-Datei haben alle Zeilen das gleiche Format. Es ist daher sinnlos, dies jedes Mal auszuführen. Sie können die ColumnNames-Funktionalität in den Konstruktor verschieben, wie in Abbildung 5 gezeigt, sodass die Eigenschaft die zwischengespeicherten Spaltennamen bereitstellt. Dies stellt sicher, dass die Datei nur einmal gelesen wird.

Abbildung 5 Zwischenspeichern der Spaltennamen für eine bessere Leistung

public CsvFile(string csvFileName)
{
  Filename = csvFileName;

    using (var reader = File.OpenText(Filename))
      ColumnNames = Parse(reader.ReadLine());
        
}

public string Filename { get; private set; }

public string[] ColumnNames { get; private set;}

Nach der Überarbeitung führen wir den Befehl erneut aus und stellen fest, dass die Anwendung wesentlich effizienter geworden ist. Sie benötigt nun nur noch 2,5 Sekunden.

Dennoch können Sie erkennen, dass die CPU-Zeit immer noch ausschlaggebend ist. Wir untersuchen die CPU-Zeit erneut und betrachten die Analyse von unten nach oben. Sie können erkenne,n dass „Regex.Replace“ nun die aufwendigste Methode ist, und dass sie von „EscapeXml“ und „ToValidXmlName“ aufgerufen wird. Da „EscapeXml“ die aufwendigere Methode ist (330 ms exklusive Zeit), betrachten wir den Quellcode:

private static string EscapeXml(string str)
{
  str = Regex.Replace(str, "\"", "&quote;");
  str = Regex.Replace(str, "<", "&lt;");
  str = Regex.Replace(str, ">", "&gt;");
  str = Regex.Replace(str, "&", "&amp;");
  return str;
}

„EscapeXml“ wird außerdem in einer Schleife in „XmlElementForRow“ aufgerufen und stellt daher möglicherweise einen Engpass dar. Reguläre Ausdrücke sind für diese Ersetzungen ein wenig zu mächtig. Die Verwendung einer Zeichenkettenersetzungs-Methode wäre effizienter. Ersetzen wir daher „EscapeXml“ durch Folgendes:

private static string EscapeXml(string str)
{
  str = str.Replace("\"", "&quote;");
  str = str.Replace("<", "&lt;");
  str = str.Replace(">", "&gt;");
  str = str.Replace("&", "&amp;");
  return str;
}

Mit dieser Transformation haben Sie die insgesamt benötigte Zeit auf ungefähr zwei Sekunden reduziert. Die CPU-Zeit ist weiterhin dominant. Dies ist eine akzeptable Leistung. Sie haben die Ausführungsgeschwindigkeit beinahe um das Siebenfache beschleunigt.

Zu Übungszwecken habe ich einige weitere Leistungsprobleme im Beispielprogramm belassen, die mittels ETW-Ereignissen identifiziert werden können.

Untersuchung von Speicherbereinigungsstatistiken

Die PerfMonitor-Speicherbereinigungsstatistiken stellen schnell eine Übersicht über das Speicherprofil bereit. Wie Sie sich erinnern, empfehle ich nachdrücklich die Prüfung der Speichernutzung. Die Informationen, die durch die ETW-Speicherbereinigungsstatistiken bereitgestellt werden, bieten einen schnellen Überblick über alle Probleme mit dem .NET GC-Heap. Die Kurzzusammenfassung zeigt Ihnen die aggregierte Größe des Speicherbereinigungsheaps, die Zuteilungsraten und die Speicherbereinigungspausenzeiten. Durch die Auswahl des Links für die Analyse der für die Speicherbereinigungs benötigten Zeit werden Ihnen die Details der Speicherbereinigungen angezeigt, wann sie aufgetreten sind, wie viel Zeit sie benötigt haben usw.

Mithilfe dieser Informationen können Sie feststellen, ob Sie die Speicherprobleme weiter mit dem CLRProfiler oder anderen Tools für die Profilerstellung bearbeiten müssen. Im Artikel „Erstellung von Profilen für den .NET-Speicherbereinigungsheap“ (msdn.microsoft.com/magazine/ee309515) wird gezeigt, wie das Debugging des .NET-Speicherbereinigungsheaps mittels des CLRProfiler durchgeführt wird.

Für dieses Programm ergeben sich keine Probleme für die Speicherbereinigungsstatistiken. Die Zuteilungsgeschwindigkeit ist hoch. Sie sollte im Allgemeinen unter 10 MB/s liegen. Die Pausenzeiten sind jedoch sehr kurz. Für die CPU-Zeit werden hohe Zuteilungsgeschwindigkeiten angezeigt. In der Regel bedeutet dies, dass die CPU-Zeit optimiert werden kann, wie Sie bereits gesehen haben. Nach der Bearbeitung des Codes sind die Zuteilungsgeschwindigkeiten jedoch nach wie vor hoch. Dies bedeutet, dass viele Zuteilungen durchgeführt werden (können Sie dies beheben)? Die Speicherbereinigungs-Pausenzeit von wenigen Millisekunden belegt die Selbstoptimierung und Effizienz der Speicherbereinigung, die die .NET Framework-Laufzeit bereitstellt. Die .NET Framework-Speicherbereinigung übernimmt also automatisch die Speicherverwaltung.

Untersuchung von Just-in-Time (JIT)-Statistiken

Um die Startzeit zu verkürzen, müssen Sie zuerst die Zeit untersuchen, die für die JIT-Kompilierung von Methoden benötigt wird. Wenn sehr viel Zeit benötigt wird (wenn z. B. die die JIT-Kompilierung den größten Teil der Zeit beim Start der Anwendung in Anspruch nimmt), kann die Anwendung möglicherweise von der systemeigenen Imagegenerierung profitieren (NGen), die die JIT-Kompilierungszeit durch die Vorabkompilierung der Assembly und deren Speicherung auf der Festplatte überflüssig macht. Für die Assembly wird eine JIT-Kompilierung durchgeführt, die auf der Festplatte gespeichert wird. Dies beseitigt die Notwendigkeit einer JIT-Kompilierung für nachfolgende Ausführungen. Bevor Sie das NGen-Verfahren anwenden, sollten Sie auch die Verschiebung einiger Methoden, für die JIT-Kompilierungen durchgeführt werden, an einen späteren Punkt des Programms in Betracht ziehen, sodass die JIT-Kompilierung keine Auswirkungen auf die Startzeit hat. Weitere Informationen finden Sie im Artikel „Die Leistungsvorteile von NGen“ (msdn.microsoft.com/magazine/cc163610).

Die Beispielanwendung „CsvToXml.exe“ benötigte nicht viel Zeit zum Starten, und es ist in Ordnung, die JIT-Kompilierung jedes Mal durchzuführen. Die Statistiken für die JIT-Kompilierung belegen auch, dass die Anzahl der mittels JIT-Kompilierung kompilierten Methoden 17 ist (was nahelegt, dass alle aufgerufenen Methoden mittels JIT-Kompilierung kompiliert wurden), und dass die für die JIT-Kompilierung benötigte Zeit 23 ms betrug. Keiner dieser Werte stellt ein Problem für die Leistung dieser Anwendung dar. Im Fall größerer Anwendungen, bei denen die für die JIT-Kompilierung benötigte Zeit eine Rolle spielt, sollte die Verwendung von NGen jedoch alle Probleme beseitigen. In der Regel spielt die für die JIT-Kompilierung benötigte Zeit dann eine Rolle, wenn eine Anwendung Hunderte oder Tausende von Methoden mittels JIT-Kompilierung kompiliert. In diesen Fällen ist NGen die Lösung, um den Aufwand für die JIT-Kompilierung zu beseitigen.

Weitere Informationen zur Verbesserung der Startzeit finden Sie in anderen Artikeln im MSDN-Magazin, und die ETW-Ereignisse können Ihnen helfen, Engpässe zu identifizieren und zu beseitigen. Es sind einige weitere JIT-Ereignisse verfügbar, einschließlich JIT-Inlineereignissen, die Informationen dazu bereitstellen, warum für eine Methode kein Inline durchgeführt wurde.

CLR-ETW-Ereignisse in .NET Framework 4

Das CLR-Team hat einen Blog über die Nachverfolgung von DLL-Ladevorgängen veröffentlicht, indem auch beschrieben wird, wie Sie feststellen können, ob eine bestimmte DLL während des Starts geladen werden muss. ETW-Ereignisse vereinfachen die Feststellung, ob eine DLL während des Starts geladen werden muss. Mittels der ETW Module Load-Ereignisse, die in .NET Framework 4 verfügbar sind, können wir ermitteln, welche Module geladen werden und warum. Es gibt auch Ereignisse für das Entladen von Modulen usw.

Es gibt einige andere Ereignisse in .NET Framework 4, mit denen die Diagnose von verwalteten Anwendungen einfacher als je zuvor wird. Abbildung 6 fasst diese Ereignisse zusammen. Alle Ereignisse, die während der Ausführung ausgelöst wurden, können mittels des runPrint-Befehls von PerfMonitor gespeichert werden. Das CLR-Team hat auch Ereignisse vorgestellt, mit denen Sie die ETW-Profilerstellung anfügen und entfernen können, und das Team plant die Hinzufügung weiterer ETW-Ereignisse, damit das Debuggen verwalteter Anwendungen in zukünftigen Versionen einfacher wird.

Abbildung 6 ETW-Ereignisse in .NET Framework 4

Im Ausführungsverzeichnis befinden sich zwei Dateien mit dem Suffix „PerfMonitorOutput“. Dies sind die ETW-Protokolldateien. Es gibt außerdem Dateien mit dem Suffix „kernel“. Diese enthalten die Betriebssystemereignisse. Die von PerfMonitor gesammelten Daten sind die gleichen Daten, die auch von XPerf verwendet werden. Daher können Sie PerfMonitor zur Vereinfachung der Datensammlung und für die einfache Berichterstellung und XPerf für erweiterte Analysen dieser Daten verwenden. Der Mergebefehl von PerfMonitor konvertiert die ETW-Dateien in ein Format, das von XPerf gelesen werden kann.

Zusammenfassung

Die Untersuchung der Leistung mittels ETW ist einfach, aber effektiv. Es sind mehrere kostenlose ETW-Tools verfügbar, die geringen Aufwand verursachen und das effiziente Debuggen von verwaltetem Code ermöglichen. Ich habe Ihnen hier nur einen ersten Eindruck von den ETW-Ereignissen vermittelt, die in der .NET Framework-Laufzeit verfügbar sind. Mein Ziel war es, Ihnen mit den ersten Schritten beim Debuggen Ihrer verwalteten Anwendung mittels ETW-Ereignissen und -Tools zu helfen. Mit dem Download von PerfMonitor und der Verwendung der MSDN-Dokumentation zu ETW-Ereignissen in CLR sowie des CLR Perf-Blogs können Sie die Untersuchung der Leistung Ihrer verwalteten Anwendungen beschleunigen.

Ich möchte Vance Morrison, Partnerarchitekt für die CLR-Leistung, für seine Beratung und Unterstützung in Bezug auf diesen Artikel danken.

Subramanian Ramaswamy* ist CLR Performance Program Manager bei Microsoft. Er verfügt über einen Ph.D. in Elektro- und Computertechnik des Georgia Institute of Technology.*