Bei der Evaluierung eines neuen Systems ist die Performanz ein wichtiges Kriterium, welches häufig ausschlaggebend für die Einführungsentscheidung ist. Aus welchen Perspektiven die Performanz des Team Foundation Servers ermittelt werden kann, soll in diesem Beitrag kurz zusammengefasst werden.
Der TFS teilt sich logisch (und evtl. auch physisch) in Applikationsschicht und Datenschicht. Auf der Applikationsschicht laufen die Web Services, welche u.a. Operationen für die TFS-Komponenten Versionskontrolle, Build und Work-Item-Tracking anbieten. Die Datenschicht besteht aus einem SQL Server, der die Datenbanken für all diese Komponenten enthält. Demnach muss auch bei einer detailierten Performanzanalyse auf beiden Schichten angesetzt werden.
Die Web Services der Applikationsschicht bieten ein Trace-Log an, welches auch zeitliche Informationen über die Operationsausführung enthält. Dieses Trace-Log muss allerdings aktiviert werden, da es per-default abgeschalten ist. Das bedeutet auch, dass es nach einer Analyse wieder deaktiviert werden sollte. Hieraus erwachsen auch kleinere Abweichungen in den Messungen gegenüber der Verwendung ohne Trace-Log, die aber die grundsätzlichen Aussagen zur Performanz des Systems nicht beeinträchtigen.
Das Trace-Log kann via Web Service aktiviert werden. Dazu dient folgende URL: http://<tfsserver>:<port>/<WebService>/tftrace.aspx?[traceWriter=<true|false>][&][All=<traceLevel>], wobei <WebService> für die Werte Build, services, VersionControl, Warehouse und WorkItemTracking stehen kann. Das <traceLevel> kann auf None, Errors, Warnings, Info und Verbose gesetzt werden. Folgende URL setzt zum Beispiel das Trace-Log für das Work-Item-Tracking auf das Level Information: http://tfs:8080/WorkItemTracking/tftrace.aspx?traceWriter=true&All=Info. Der Output kann dann in etwa so aussehen, wie in der Abbildung WIT Trace Log Beispiel dargestellt.
Für eine genauere Performanzanalyse auf Seiten der Datenschicht dient der SQL Server Profiler. Mit ihm lassen sich alle Operationen auf dem SQL Server und deren Dauer, Lese- und Schreibzyklen sowie CPU-Auslastung mitloggen. Ein typischer Log während der Ausführung einer Work-Item-Query stellt sich in etwa wie in Abbildung SQL Server Profiling einer Work-Item-Query dar.
Sollten diese Möglichkeiten noch nicht ausreichend sein, können auch andere Tools weiterhelfen. Mit einem Netzwerk-Tracing-Tool kann so zum Beispiel die Netzwerklast bei TFS-Anfragen protokolliert werden. So lassen sich evtl. Performanzverluste auf Seiten des Client zurückverfolgen. Ein sehr hilfreiches Tool ist zum Beispiel WireShark…
Es bieten sich also verschiedene Möglichkeiten für das Profiling des TFS. Es sollte allerdings ausreichend sein, diese nur in größeren Abständen oder nach größeren Änderungen an der Infrastruktur durchzuführen. Durch eine rechtzeitige Analyse und das Erkennen von “Performanzlöchern” sollten sich dann schnell Maßnahmen zur Verbesserung ableiten und auch umsetzen lassen.