Performance-Messung

Aus SDQ-Wiki

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.

Ein aktuelles Buch zum Thema ist Systems Benchmarking For Scientists and Engineers von Samuel Kounev et al., das über Springerlink aus dem KIT Netz heruntergeladen werden kann und zu dem weiteres Lehrmaterial verfügbar ist (bitte Betreuer:in und Anne Koziolek nach Zugangsdaten fragen).

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].

Performance-Messung bei Logging

log4j

Diese Methode kann man bei Application Servers Tomcat (log4j for Apache Tomcat), JBoss sowie WildFly einsetzen. Die log4j-Konfiguration findet über die Dateidefinition von log4j.properties statt und erlaubt die anwenderspezifische Einstellung von Logs. Dabei kann die ConversionPattern-Variable verwendet werden, um die Konfiguration von log4j basierend auf dessen PatternLayout anzupassen. Im Folgenden sind die notwendingen Parameter für die Konfiguration des Loggers bezogen auf ausgewählte Funktionen/Eigenschaften aufgelistet:

  • Zeitstempel:
    • %d: Einfache Zeitstempel
    • %d{dd MMM yyyy HH:mm:ss,SSS}: Hiermit kann man die Zeitangabe formatieren
  • Request/ Request-ID:
    • %t: Used to output the name of the thread that raised this log entry
    • %C: Used to output the fully qualified class name of the caller issuing the logging request
    • %F: Used to output the file name where the logging request was issued.
    • %L: Used to output the line number from where the logging request was issued.
    • %M: Used to output the method name where the logging request was issued.

NOTE: Ausnutzung von Konfigurationsparametern, die für die Erstellung von Lokation-spezifischen Informationen zuständig sind, können hohe Ressourcen kosten. Die Ausgabe der Zeilennummer ist daher sehr ressourcenbelastend.

Eine mögliche Konfiguration für die Verwendung der Logs mit für Palladio günstigen Patterns könnte in der log4j.properties-Datei wie folgt aussehen: 

log4j.appender.LOCALHOST.layout = org.apache.log4j.PatternLayout<br />
log4j.appender.LOCALHOST.layout.ConversionPattern = %d [%t] %-5p %c - %m %n

The Valve Component für Tomcat

Eine weitere Möglichkeit bei Tomcat die Messdaten für HTTP-Requests zu erfassen, ist der Einsatz der sogenannten „The Valve Component“ [7], die eine Komponente repräsentiert, die in die Request-Pipeline für den assozierten Catalina-Container hinzugefügt wird, der auch die gängige log4j und dazugehörige Konfigurationsdateien beinhaltet. Die Access Log Valve erstellt Logs (im ähnlichen Format wie z.B. log4j-Logs) mit zusätzlichen Daten für die spätere Performance-Analyse. Die Konfigurationsvariable „pattern“ bietet eine Formatvorlage, die die sämtlichen zu erfassenden Informationen von Requests und Antoworten identifiziert. Die folgenden Parameter für die Pattern-Konfioguration stehen zur Verfügung:

  • %a - Remote IP address
  • %A - Local IP address
  • %b - Bytes sent, excluding HTTP headers, or '-' if zero
  • %B - Bytes sent, excluding HTTP headers
  • %h - Remote host name (or IP address if resolveHosts is false)
  • %H - Request protocol
  • %l - Remote logical username from identd (always returns '-')
  • %m - Request method (GET, POST, etc.)
  • %p - Local port on which this request was received
  • %q - Query string (prepended with a '?' if it exists)
  • %r - First line of the request (method and request URI)
  • %s - HTTP status code of the response
  • %S - User session ID
  • %t - Date and time, in Common Log Format
  • %u - Remote user that was authenticated (if any), else '-'
  • %U - Requested URL path
  • %v - Local server name
  • %D - Time taken to process the request, in millis
  • %T - Time taken to process the request, in seconds
  • %I - current request thread name (can compare later with stacktraces)

NOTE: Die genannte Komponente kann auf dieselbe Art (eventuell mit spezifischen Einstellungen) auch für den JBoss AS zum Einsatz gebracht werden. Im Folgenden ist eine Beispielkonfiguration für AccessLogValve angegeben[8]: 

<Valve
    className="org.apache.catalina.valves.AccessLogValve"
    directory="${catalina.base}/logs"
    prefix="access_log"
    fileDateFormat="yyyy-MM-dd.HH"
    suffix=".log"
    pattern="%t %H cookie:%{SESSIONID}c request:%{SESSIONID}r  %m %U %s %q %r"
/>

Es gibt zwei Möglichkeiten die Valve-Komponente einzusetzen:

  • Erfassen der Logs für die einzelne Web-Applikation: Hinzufügen der AccessLogValve in die Kontextdatei (META-INF/context.xml) der Applikation
  • Erfassen der Logs von allen Requests für einen Server: Hinzufügen der AccessLogValve in das „Host“-Element (conf/server.xml) des Servers

NOTE: Ab Tomcat 7 ist eine AccessLogValve-Konfiguration bereits in „conf/server.xml“ definiert.

JBoss Operations Network

Eine Alternative zum Einsatz von log4j in JBoss AS wäre der Einsatz von JBoss Operations Network [9]. Es stellt die sogenannten „response time filters“ als ein weiteres Monitoring-Tool zum Erfassen von Zeitdauer, die eine URL gebraucht hat, um auf ein HTTP-Request zu reagieren. Die folgenden Schritte müssen unternommen werden:

JBoss ON bietet eine benutzerfreundliche grafische Oberfläche, mit der man die Messdaten erfassen und interpretieren kann.

Unix-basierte System-Monitore

iostat

Input/output statistics (iostat) [10] ist ein Monitoring-Werkzeug für Überwachung und Ausgabe von CPU-Statistiken sowie Systemprozessen mit I/O-Logik. Eingesetzt wird es in UNIX-basierten Betriebssystemen meistens für die Identifikation von Leistungsproblemen bzgl. Speichergeräten (zB. lokale/netzwerk-basierte Speicher, etc.). Command-Eingabemuster: 

iostat [ -c ] [ -d ] [ -N ] [ -n ] [ -h ] [ -k | -m ] [ -t ] [ -V ] [ -x ] [ -z ] [ device [...] | ALL ] [ -p [ device [,...] | ALL ] ] [ interval [ count ] ]

Mit iostat werden drei Arten von Berichten mit jeweils eigenen Formaten erstellt: CPU-Auslastungsbericht:

  • %user: Anteil der CPU-Auslastung während Ausführung auf Anwendungsebene
  • %system: Anteil der CPU-Auslastung während Ausführung auf Systemebene
  • %iowait: Anteil der CPU-Wartezeit auf einer I/O-Anfrage
  • %idle: Anteil der CPU-Wartezeit während keine I/O-Aufgaben durchgeführt werden

Device-Auslastungsbericht (I/O-Antwortzeit für HDD etc.)

  • tps: Indicate the number of transfers per second that were issued to the device. A transfer is an I/O request to the device.
  • kB_read/s: Indicate the amount of data read from the device expressed in kilobytes per second.
  • kB_wrtn/s: Indicate the amount of data written to the device expressed in kilobytes per second.
  • await: The average time (in milliseconds) for I/O requests issued to the device to be served.
  • svctm: The average service time (in milliseconds) for I/O requests that were issued to the device.
  • %util: Percentage of CPU time during which I/O requests were issued to the device (bandwidth utilization for the device). Device saturation occurs when this value is close to 100%.

Netzwerkdateisystembericht (I/O-Antwortzeit für Netzwerk etc.)

  • ops/s: Indicate the number of operations that were issued to the filesystem per second.
  • rops/s: Indicate the number of 'read' operations that were issued to the filesystem per second.
  • wops/s: Indicate the number of 'write' operations that were issued to the filesystem per second.

Diese Berichte stellen noch weitere Informationen zur Verfügung, die für die Performanceevaluierungszwecke näher betrachtet werden können. Die Optionen dieses Commands, die für die Erstellung der Berichte relevant sind, sind unten aufgelistet:

  • -x: Liefert die erweiterte Statistik
  • -c: Gibt nur den CPU-Auslastungsbericht aus
  • -d: Gibt nur den Geräte-Auslastungsbericht aus
  • -h: Erstellt den NFS-Bericht mit der Option –n leichter lessbar für einen Mensch
  • -n: Gibt den Auslastungsbericht vom Netzwerk-basierten Dateisystem (NFS) aus (Diese Option funktioniert nur mit Kernels 2.6.17 oder neuer)
  • -t: Gibt den Zeitpunkt der Erstellung für jeden Bericht aus
  • [0..9]+: Anzahl Sekunden für Monitoring-Interval

Für relevante Messzeitpunkte: 

iostat -t -x 3600

top

top [11], ein Unix -Command, ist verantworlich für die Beobachtung und Ausgabe einer kontinuierlich aktualisierten Liste von laufenden Systemprozessen. Es ist mächtig, flexibel konfigurierbar und kann eine interaktive Schnittstelle für die Anpassung der Prozesse zur Verfügung stellen. Prozesse können nach ihrer aktuellen Prozessorauslastung, Speicherbenutzung oder Laufzeit unterschiedlich betrachtet und (aus-)sortiert werden. Die Konfiguration des Commands kann entweder über den interaktiven Einsatz vom Command oder über die Definition von einer globalen Konfigurationsdatei erfolgen. Command-Eingabemuster: 

top [-] [d delay] [p pid] [q] [c] [C] [S] [s] [i] [n iter] [b]

Im Folgenden sind die relevanten Anweisungsparameter für die ausgewählten System-Performance-Eigenschaften aufgelistet, die bei der Konfiguration ausgenutzt werden sollen. Zu beachten ist es, dass die folgenden Parameter in erster Linie in der interaktiven Schnittstelle eingesetzt werden können:

  • Schreiben von kontinuierlichen Werten in Datei: Nicht direkt unterstützt
  • CPU-Auslastung: Eingabe “P” wird die Prozesse nach deren CPU-Auslastung aussortieren und ausgeben.
  • User: Eingabe „u“ (bzw. „U“) wird die Auswahl eines bestimmten Anwender ermöglichen, nachdem zusätzlich ein Anwendername bzw. ein UID eingegeben wird. Damit werden nur die Prozesse, die zu einem Anwender gehört, ausgegeben.
  • Speicher-Auslastung: Eingabe “M“ wird die Prozesse nach deren CPU-Auslastung aussortieren und ausgeben.

NOTE: Ein an top angelehntes, aber benutzerfreundlicheres Tool mit Vorteilen wie grafischer Darstellung und Möglichkeiten Prozess-Signale per Tastenkombinationen zu versenden ist htop, was –wie folgt beschrieben- über das gleichnamige Paket installiert werden, z.B. unter Debian, kann: 

aptitude install htop

iotop

iotop [12] ist ebenfalls ein simples Command auf Unix-basierten Systemen und kann als eine Erweiterung von top für Systemprozesse mit Ein-/-Ausgabelogik interpretiert werden. Es überwacht die Ein- und Ausgabennutzungen und gibt die Liste von aktuellen I/0-Prozessen im System aus. NOTE: Zumindest sollten CONFIG_TASK_DELAY_ACCT and CONFIG_TASK_IO_ACCOUNTING Optionen in der Linux-Kernelkonfiguration freigeschaltet werden, die von CONFIG_TASKSTATS abhängig sind. Command-Eingabemuster: 

iotop [*]

Überwachte Elemente:

  • -o, --only
    • Statt alle Prozesse oder Threads werden nur die Prozesse oder Threads ausgegeben, die tatsächilich I/O durchführen. Dynamische Umwechslung via die Eingabe von o möglich.
  • -p PID, --pid=PID
    • Eine Liste von Prozessen/Threads zum Monitorn (Standardmäßig alle)
  • -u USER, --user=USER
    • Eine Liste von Benutzern zum Monitorn (Strandardmäßig alle)
  • -P, --processes
    • Nur Prozesse werden ausgegeben. Normal werden alle Threads gezeigt.

Zeitstempel:

  • -t, --time
    • Fügt ein Zeitstempel zu den einzelnen Zeilen hinzu. Jede Zeile wird dann am Beginn mit dem aktuellen Zeitpunkt versehen

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 [13] beschreibt der Sun Mitarbeiter David Holmes Details zu den beiden genannten Methoden sowie deren Implementierung unter Windows.
  • Performance Counter Library (PCL):
    PCL[14] 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 [15] 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 [16] 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 [17].

.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 [18].

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. [19] 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 [20].

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
Abgerufen von „https://sdq.kastel.kit.edu/mediawiki-sdq-extern/index.php?title=Performance-Messung&oldid=32290“