Personal tools

Performance-Messung

From Wissensbasis

Jump to: navigation, search

Performance-Messungen wurden im Rahmen von Studien- und Diplomarbeiten schon von vielen Studenten in unserer Abteilung durchgeführt. Das folgende Dokument fasst einige ihrer Erfahrungen zusammen und soll helfen, bereits bekannte Problemlösungen für neue Studenten verfügbar zu machen. Um eine Einschätzung der geeignetsten Methode zur Performance-Messung zu erlauben, werden Grundlagen und die Eigenschaften der verfügbaren Zeitgeber angesprochen.

Contents

Hintergrund

TimerMeter

Ein ausführliches Paper zur Zeitmessung sowie ein Werkzeug für die Bestimmung der Accuracy und der Invocation Costs von Timer-Methoden gibt es hier: TimerMeter

Verfügbare Zeitgeber in CPUs

  • Auf der Linux Kernel Mailing Liste hat Vojtech Pavlik eine Übersicht über die verfügbaren Zeitgeber und deren wichtigster Eigenschaften gegeben [1] (Zitat, ergänzt um vollständige Namen der Kürzel):
  1. Real Time Clock (RTC): 0.5 sec resolution, interrupts
  2. Programmable Interval Timer (PIT): takes ages to read, overflows at each timer interrupt
  3. Power Management Timer (PMTMR): takes ages to read, overflows in approx 4 seconds, no interrupt
  4. High Precision Event Timer (HPET): slow to read, overflows in 5 minutes. Nice, but usually not present.
  5. Time Stamp Counter (TSC): fast, completely unreliable. Frequency changes, CPUs diverge over time.
  6. APIC Timer (LAPIC): reasonably fast, unreliable, per-core
  • Microsoft bietet im Rahmen der Windows Hardware Developer Central unter [2] ebenfalls eine gute Übersicht. Diese ist Teil der Beschreibung des High Precision Event Timer (HPET) und folgt als Zitat:
  1. 8254 PIT
    The 8254 Programmable Interval Timer (PIT) was introduced in the IBM PC in 1981. It has a resolution of 1 millisecond and supports both periodic and aperiodic modes. However, because reads from and writes to this hardware require communication through an IO port, programming it takes several cycles, which is prohibitively expensive for the OS. Because of this, the aperiodic functionality is not used in practice. For this reason, this timer is only used in periodic mode to provide the periodic clock interrupt on uni-processor systems.
  2. RTC
    In 1984, the IBM-AT shipped with the first real-time clock (RTC) in addition to the 8254. Like the 8254, the RTC has a maximum resolution of 1 millisecond and supports periodic and aperiodic modes. As with the 8254, communication with this hardware occurs through an IO port, and is therefore prohibitively expensive. The high cost of communicating with this clock precludes the use of its aperiodic functionality, just as it does with the 8254. In addition to these limitations, the RTC was designed to generate Advanced Configuration and Power Interface (ACPI) interrupts on ACPI capable systems, which degrades system performance. The RTC is used in periodic mode to provide the system profiling interrupt on uni-processor systems and the clock interrupt on multi-processor systems.
  3. APIC Timer
    The Advanced Programmable Interrupt Controller (APIC) timer has many of the capabilities of the real-time clock and was designed to be used to synchronize multiple processors, but it has poor resolution and the clocks silicon is sometimes very buggy. Because many of todays systems still do not have an APIC timer, it is not used by default. More importantly however, this timer is subject to pausing during processor power management in some implementations, making it useless for keeping reliable time on modern systems. For these reasons, this timer is seldom used.
  4. PM Clock
    The ACPI timer, also known as the PM clock, was added to the system architecture to provide reliable timestamps independently of the processors speed. Because this was the single goal of this timer, it was designed to provide a time stamp in a single clock cycle, but it does not provide any other functionality.
  5. High Precision Event Timer (formerly: Multimedia Timer)
    The High Precision Event Timer (HPET) was developed jointly by Intel and Microsoft to meet the timing requirements of multimedia and other time-sensitive applications. Originally, the HPET was called the Multimedia Timer (MM Timer), but the name was later changed to avoid confusion with a Microsoft DirectX timer, and to better describe the timer.

    Eine detaillierte Beschreibung des HPET befindet sich auf der genannten Webseite.
  • Time Stamp Counter
    Der Time Stamp Counter (TSC) ist eine prozessorspezifische Zeitangabe mit sehr hoher Auflösung. Die Auflösung ist Abhängig vom aktuellen Prozessortakt. Außerdem gibt es keinen festgelegten Bezugspunkt für die Zeitangabe. Sie kann unter anderem mit dem Assemblerbefehl RDTSC (http://en.wikipedia.org/wiki/RDTSC) abgefragt werden.

Betriebssystemabhängige Eigenschaften

Windows

  • Da Windows XP incl. SP2 und Windows Server 2003 (64-bit) einen Fehler in der Verwaltung der Energieverbrauchssteuerung haben, kann es bei Systemen mit mehr als einem Prozessor oder Kern zu Leistungseinbußen kommen. Auf AMD Dual-Core-Prozessoren wird zudem ein Fehler in der Synchronisation der TSC behoben. Informationen finden sich unter: [3]. Durch Ausschalten der Energiesparoptionen kann zumindest ein Teil der Fehler ausgeschlossen werden. Informationen dazu befinden sich unter [4].
  • Bei Verwendung der Cool'n'Quiet-Technologie von AMD kann die Systemfunktion QueryPerformanceCounter (verwendet je nach Einstellung den TSC) nicht richtig funktionieren. Dies ist die Standardfunktion von Windows für den Zugriff auf den präzisesten Zeitgeber ist. Der von Windows verwendete Zeitgeber kann in der Datei boot.ini über den Parameter /usepmtimer für den jeweiligen Starteintrag verändert werden. Genaue Informationen befinden sich unter: [5].

Linux

Unter Linux führten die Probleme mit dem TSC dazu, dass dieser derzeit überhaupt nicht benutzt wird. Eine Änderung ist jedoch zu erwarten. Informationen über die Probleme und Ansatzpunkte finden sich in [6].

Java

  • Zeitmessung mit System.currentTimeMillis():
    Die Funktion System.currentTimeMillis() bietet im besten Fall eine Auflösung im Millisekundenbereich. Die tatsächliche Auflösung hängt jedoch vom eingesetzten Betriebssystem und dessen Konfiguration ab. Der zurückgegebene Wert bezieht sich auf die seit dem 01.01.1970 00:00 (UTC) vergangenen Millisekunden. Quelle: Java Dokumentation (http://java.sun.com/j2se/1.5.0/docs/api/java/lang/System.html#currentTimeMillis()). Damit ist eine absolute Zeitangabe möglich.
    Bewertung:
    Für Performance-Messungen ist diese Funktion aufgrund ihrer Ungenauigkeit jedoch nur bedingt geeignet.
  • Zeitmessung mit System.nanoTime():
    Mit Java 1.5 wurde die Funktion System.nanoTime() eingeführt. Diese wählt die genaueste verfügbare Zeitquelle aus und gibt deren Wert in Nanosekunden zurück. Der Bezugszeitpunkt der Zeitangabe oder die tatsächliche Genauigkeit bleiben unbekannt. Aus diesen Gründen kann die Angabe nur zur Berechnung von verstrichener Zeit benutzt werden. Quelle: Java Dokumentation (http://java.sun.com/j2se/1.5.0/docs/api/java/lang/System.html#nanoTime()).
    Bewertung:
    Derzeit für Performance-Messungen die beste Wahl. Die Beschränkungen des gewählten Betriebssystems und eventuelle Probleme speziell bei mehreren Prozessoren müssen jedoch beachtet werden.
  • In seinem Blog [7] beschreibt der Sun Mitarbeiter David Holmes Details zu den beiden genannten Methoden sowie deren Implementierung unter Windows.
  • Performance Counter Library (PCL):
    PCL[8] ist eine Bibliothek, die Zugriff auf Performance-Counter von Prozessoren ermöglicht. Sie ist für die Sprachen C, C++, Fortran und Java verfügbar. Die aktuelle Version 2.2 hat den Stand von Januar 2003. Aktuelle Prozessoren sind dementsprechend nicht berücksichtigt. Als Betriebssystem für x86-Prozessoren wird Linux 2.x vorausgesetzt, das mit einem Patch auf die Anwendung der Bibliothek vorbereitet werden muss.
    Bewertung:
    Für Performance-Messungen auf aktueller Hardware nur bedingt geeignet. Die Anwendbarkeit des Patches unter Linux könnte ein Problem darstellen.
  • Performance Application Programming Interface (PAPI):
    PAPI [9] ist eine Bibliothek zum Zugriff auf Performance-Counter von Prozessoren. Zu den unterstützten Sprachen gehören C und Java. Die Liste der unterstützten Prozessoren und Betriebssysteme ist unter [10] zu finden.
    Bewertung:
    Für allgemeine Performance-Messungen sehr gut geeignet. Für reine Zeitmessungen können jedoch sprach- oder betriebssystemeigene Funktionen gleich gut geeignet sein.

.NET

Manuelle Zeitmessung

  • HiResTimer: Die DateTime-Klasse ist viel zu ungenau. Sie liefert zwar Millisekunden, beim Messen von z.B. 100 Durchläufen ergab sich aber, dass viele Werte mehrfach vorkommen. Wenn der Wert 2,437 Sekunden 10mal auftaucht, kann das eigentlich nicht sein. Denn das 10 Prozent aller Durchläufe auf die Millisekunde genau gleich lange benötigen, ist nahezu unmöglich. Daher wird eine Klasse benutzt, die eine genau messende Windows-API-Funktion aus kernel32.dll kapselt. Die Klasse entstammt dem Test-Harness von ? sie ist in allen Projekten enthalten und heißt HiResTimer. (Andreas Kostian)
  • Inkrementelles Kompilieren abschalten: Die erste Anweisung in den meinen Programmen ist, dass die Thread-Priorität auf die höchste gesetzt wird. Vor den Messungen sollten die Testprogramme komplett neu übersetzt werden, da das inkrementelle Kompilieren vermutlich für Performance-Einbußen verantwortlich ist. Evtl. erzeugt es einen Overhead, mit dem der JIT-Compiler irgendwie umgehen muß. (Andreas Kostian)
  • Der PerformanceCounter von Windows kann auch in C# direkt verwendet werden. Ein Beispiel befindet sich unter [11].

.NET-Profiling

Allgemeines

  • Ein Profiler verwendet die Meta-Informationen einer .NET-Assembly sowie die Debug-Informationen, die Visual Studio .NET in einer Debug-Konfiguration erzeugen kann, um eine .NET-Applikation zu analysieren. Dabei muss kein Eingriff in den Code erfolgen, denn die Software kann zur Laufzeit überwacht werden, um z.B. Durchlaufzeiten von Methoden und einzelnen Code-Zeilen zu bestimmen.
    Im Release-Modus erstellte Programme enthalten dementsprechend manchmal nicht genügend Debug-Informationen, um alle Methoden zu erfassen. Dies ist auch so in der Hilfe der Profiler beschrieben, aber ein Erstellen im Debug-Modus ist vielfach keine Option, wenn man realistisch messen will. (Rico Starke)

Bekannte Probleme mit Profilern

  • Problem mit Meta-/Debug-Informationen und automatischen Profilern (.NET Framework 1.1), insbesondere im Fall von AQtime (das beschriebene Problem könnte liegt im .NET-Framework selbst begründet liegen auch andere Produkte betreffen):
    Der Profiler war zunächst nicht in der Lage, meine Applikation zu untersuchen - nach Angaben des Profilers enthielt die Assembly keine Meta- bzw. Debug-Informationen, was jedoch nicht zutraf. Auf anderen PCs konnte ich die exakt gleiche EXE-Datei ohne Probleme laden und untersuchen. Eine nach langer Suche gefundene Lösung war, zusätzlich das .NET Framework SDK in der Version für Windows Server 2003 von Microsoft herunterzuladen (über 100 MB) und zu installieren. Danach funktionierte der Profiler ohne "Änderungen an der Applikation wie gewohnt. Nach dem Abmelden und erneutem Anmelden am Betriebssystem trat der Fehler jedoch erneut auf, so dass das Framework SDK offenbar nach jedem Aus- und Einloggen installiert werden muss. (Rico Starke)

Liste von .NET-Profilern

  • ANTS Profiler
    Der ANTS-Profiler ist ein Werkzeug zur Identifizierung von Performance-Flaschenhälsen in Applikationen, die mit einer beliebigen Programmiersprache geschrieben wurden, die für das .NET-Framework verfügbar sind. Eine Testversion ist für 30 Tage verfügbar, für Studien- und Diplomarbeiten können kostenlose Lizenzen direkt bei der Firma beantragt werden.
    Der Profiler erfaßt sowohl das zeitliche Verhalten der untersuchten Applikation (Durchlaufzeiten) als auch den Speicherverbrauch, heruntergebrochen bis auf die Ebene einzelner Objekte. Die Genauigkeit der Zeitmessungen fest eingestellt (hängt von der Größe des Wertes ab: 1 Millisekunde bzw. 1/10 Sekunde) und kann nicht verändert werden. (Rico Starke)
  • AQtime
    AQtime ist ein Performance und Speicher Optimierungswerkzeug für das .NET-Framework und Visual Studio. Eine Testversion ist für 15 Tage gratis verfügbar. Für Studien- und Diplomarbeiten können Lizenzen beantragt werden. Es bietet neben der Untersuchung von Durchlaufzeiten und Speicherverbrauch weitere Profiler-Typen wie z.B. eine Coverage-Analyse. AQtime bietet wesentlich mehr Möglichkeiten als ANTS. (Rico Starke)

Weitere Bemerkungen

Beim Benchmarken unter Windows den SVNCache-Hintergrundprozess abschiessen: dieser lastet Festplatte und CPU extremst aus und ist nicht konfigurierbar. Abschiessen ist i.A. nicht kritisch - beim nächsten "Commit" oder "Update" aus dem Windows Explorer-Kontextmenü springt der Hintergrundprozess automatisch wieder an. Ausserdem helfen beim Überprüfen der Hintergrundprozesse von Microsoft hinzugekaufte Tools von Sysinternals: http://technet.microsoft.com/en-us/sysinternals/default.aspx


Synchronisation im Netzwerk

Für die Genauigkeit von Performance-Messungen über einem Netzwerk kann die Synchronisation der beteiligten Rechneruhren ausschlaggebend sein.

Network Time Protocol (NTP)

Eine plattformunabhängige Möglichkeit zur Synchronisation bietet NTP. NTP ist ein Standard zur Synchronisierung von Uhren in Computersystemen über paketbasierte Kommunikation. NTP verwendet das verbindungslose Transportprotokoll UDP. Es wurde speziell entwickelt, um eine zuverlässige Zeitgabe über Netzwerke mit variabler Paketlaufzeit zu ermöglichen. Einen sehr guten Einstieg und Überblick bietet die Website [12].

Beispielkonfiguration im LAN

Für eine Synchronisation innerhalb eines LAN wird ein Rechner als NTP Server konfiguriert und die restlichen Rechner verbinden sich über eine NTP Client-Konfiguration. Mit dieser Konfiguration wurde mit einem Intel Celeron 800MHZ, einem 1.7GHZ AMD Duron und einem Intel Pentium M 1.5GHZ über einem 100MBit LAN + Switch ohne sonstige Auslastung eine Genauigkeit von unter einer Millisekunde erreicht. Die verwendete NTP Version ist ntp 4.2.5p212

NTP Server (IP: 192.168.1.68)

driftfile "C:\Programme\NTP\etc\ntp.drift"

server 127.127.1.0 maxpoll 4 iburst true

fudge 127.127.1.0 stratum 0

NTP Client

driftfile "C:\Programme\NTP\etc\ntp.drift"

server 192.168.1.68 maxpoll 4 iburst true

restrict 192.168.1.68

restrict 127.0.0.1

restrict default notrust nomodify nopeer

enable stats

statsdir C:\PerfLogs\

statistics loopstats

Die Genauigkeit der Synchronisation hängt in gewissem Maße von der Rechenleistung der verwendeten Rechner, von der verwendeten NTP Version und von der Netzwerkauslastung ab. [13] bietet hierfür eine Übersicht. Beispielsweise kann durch zu häufiges Abfragen eine hohe Netzlast entstehen.

Betriebssystemspezifisch

Windows

NTP Stolpersteine

  1. Der Dienst Windows-Zeitgeber muss deaktiviert sein.
  2. Bei virtuellen Maschinen muss geprüft werden, ob dem Client eine Verwendung von NTP durch das Hostsystem erlaubt wird.

PsExec

PsExec eignet sich für die Ausführung von entfernten Befehlen über die Konsole. Vor allem im Vergleich zu grafischen Remoteanwendung wird über PsExec wesentlich weniger Last auf dem Netzwerk erzeugt. Weitere Informationen finden sich unter [14].

Lasttreiber und Messframeworks / Load Drivers and Measurement Frameworks

please write notes in English.

  • Faban (http://faban.sunsource.net/, benchmarking framework with load driver and facilities for measurements), infos: Michael Kuperberg
    • facilities for HTTP GET/POST workload generation
  • JAmon, perf4j and JavaSimon: performance measurement frameworks which feature start stop timers, split timers.
    • Gain statistical indicators
      • Mean / Average
      • Min / Max
      • Standard Deviation
      • Counts
    • Support of
      • EJB-code
      • Database Monitoring (JDBC Driver)
      • Servlets
    • infos: Michael Kuperberg
KIT – Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft