Inventage > Unser Angebot > Dienstleistungen > Beratung in Software Entwicklung > Performance- und Lasttests

Performance- und Lasttests

Performance stellt eines der Hauptkriterien dar, die über den Erfolg eines J2EE-Projekts entscheiden. Umso wichtiger ist es, im gesamten System den Überblick zu behalten, wie sich die einzelnen Produkte und Komponenten im Betrieb bezüglich ihrer Performance verhalten.

Hierbei hat sich folgendes Vorgehen bewährt

  • Assessment - Workload estimation
  • Measurement - Benchmarking
  • Interpretation - Analyse
  • Optimierung - Prognose
Performancekriterien gehören zum Abschnitt "Nicht-funktionale Anforderungen" der Softwarespezifikation und sind möglichst präzise zu definieren.


Ziele
Mit Hilfe der Lasttests werden Performance-Kennzahlen für die Kapazitätsplanung ermittelt. Somit wird sichergestellt, dass die vorhandenen System-Ressourcen den Business-Bedürfnissen gerecht werden. Mit Lasttests werden Skalierbarkeit, Durchsatz und Stabilität der folgenden Komponenten und Produkte analysiert:

  • Anwendung
  • Betriebssystem
  • Applikationsserver
  • Datenbank
  • Netzwerk

Tools
Neben verschiedenen kommerziellen Tools (z.B. Mercury LoadRunner) setzen wir auch diverse OpenSource Alternativen (z.B. The Grinder oder Apache JMeter) ein.

Die verschiedenen System- und Konfigurationsparameter können optimal konfiguriert werden.


Begriffe
Unter einem Lasttest versteht man einen (nicht funktionalen) Softwaretest, mit dem eine gewisse Last auf dem laufenden System erzeugt und das Verhalten desselbigen beobachtet und untersucht wird. Ziel dabei ist es

  • Fehler aufzudecken, die im funktional orientierten Systemtest/Integrationstest nicht gefunden wurden und
  • nichtfunktionale Anforderungen nachzuweisen.
Wird ein Lasttest im oberen Grenzbereich gefahren, spricht man auch von einem Stresstest. Damit werden die Performanzgrenzen des Systems ausgelotet und die Komponenten identifiziert, die für eine Systemerweiterung in Frage kommen.

Im Gegensatz dazu dient der Niederlasttest, der absichtlich mit einer geringen Intensität betrieben wird, der Untersuchung des Interaktionsverhaltens der virtuellen User und des von ihnen erzeugten Nachrichtenverkehrs auf dem System. Dieser Test kann parallel zum Funktionstest durchgeführt werden.

Ein Lastest über einen längeren Zeitraum (z.B. 48-72 Stunden) wird als Dauerlasttest bezeichnet.


Scripts und Szenarios
Basierend auf den ermittelten Kennzahlen werden verschiedene Lasttest-Scripts erstellt. Die Zusammenfassung verschiedener Scripts, die Definition einer Startup-Rampe und weitere Runtime-Einstellungen werden als Szenario bezeichnet. Um eine gute Verteilung der Transaktionen zu erhalten wird ein %-Wert der Wartezeit im Script sowie eine sinnvolle Startup-Rampe, z.B. ein neuer Benutzer alle 15 Sekunden verwendet. Häufig ist die Anzahl der Benutzer entweder durch eine Software-Lizenz oder die vorhandenen Systemressourcen der Lastgeneratoren beschränkt. Um eine höhere Systemlast zu erhalten, kann auch die Wartezeit zwischen den Interaktionen bewusst niedrig gehalten werden.


Assessment - Workload estimation
Basierend auf Auswertungen des Kundenverhaltens und Vorhersagen über das Wachstum des Systems werden die folgenden Messpunkte und Metriken ermittelt:

  • Anzahl Benutzer
  • Art der Transaktionen
  • Sequenz der Transaktionen
  • Komplexität der Transktionen
  • Wartezeit zwischen Interaktionen
  • Durchsatz
  • Antwortzeit
  • Auslastung der beteiligten Software- und Hardwarekomponenten

Measurement - Benchmarking
Die notwendigen Sytemressourcen für das Aufzeichnen und die Präsentation der Messdaten sind abhängig von

  • Typ und Frequenz der Messung
  • Methode der Datenpräsentation (textuell und / oder grafisch)
  • Speicherung der Daten (Memory und / oder Disk)
  • Aktivität des Systems (abhängig von der Anzahl Benutzer / Transaktionen)

Vorgehen
Zuerst werden die Kennzahlen des Systems mit einer akzeptablen Antwortzeit gemessen. Diese Messung wird auch Baseline genannt und später als Referenz bzw. Vergleichswert gegenüber weiteren Ergebnissen verwendet. Um die Grenzen des Systems zu untersuchen, gibt es zwei Möglichkeiten:

  • Anzahl der Benutzer erhöhen
  • Verfügbare Systemressourcen reduzieren
Durch dieses Vorgehen kann das System und die Applikation optimiert werden.


Interpretation - Analyse
Da das Gesamtsystem aus einer Vielzahl von Einzelkomponenten (Hardware, Storage, Operating System, Middleware, Applikation, Datenbank) besteht, ist die Interpretation sehr aufwändig. Zur Analyse mit dem jeweils eingesetzten Tool gehören auch die folgenden Bereiche:

Optimierung - Prognose
Eine Optimierung sollte sofort auf ihre Wirksamkeit überprüft werden. Pro Messung sollte nur eine Änderung erfolgen. Nur wenn eine definitive Verbesserung gemessen wurde, darf die Änderung permanent gemacht werden. Die folgenden Fragen werden in der Prognose berücksichtigt:

  • Wie muss das System ausgebaut werden, wenn n Benutzer hinzugefügt werden?
  • Wie verhält sich die Antwortzeit, wenn eine neue Funktionalität hinzukommt?
  • Verbessert sich die Performance, wenn ein CPU-Upgrade durchgeführt wird?
Beispiele von Auswertungen