Frühe kleine Lasttests

09.03.2007 Permalink

Jede Art von Test ist ein Mittel, Risiken zu entdecken mit dem ultimativen Zweck, entweder ihre Nichtrelevanz zu zeigen oder sie anderenfalls einschätzen und beseitigen zu können.

Während der Erstellung oder Änderung eines Systems schleichen sich leicht Lösungen ein, die sich negativ auf Antwortzeitverhalten, Durchsatz, Ressourcenverbrauch und Stabilität auswirken können. Performantes Verhalten einer Anwendung ist aber eine gewichtige geschäftliche Anforderung. Lange Wartezeiten können Benutzer, insbesondere Kunden, dazu veranlassen, die bearbeiteten Vorgänge abzubrechen, also z.B. keine Bestellung auszuführen, womit unmittelbar wirtschaftlicher Schaden entsteht.

Jedes System, das einer größeren Menge von Benutzern bereitgestellt werden soll, sollte vor Inbetriebnahme einem Lasttest unterzogen werden, um nachzuweisen, dass es in der Produktionsumgebung das erforderliche Verhalten zeigt. Diese Tests sind i.d.R. aufwändig, da

erstens eine produktionsnahe, möglichst voll mit Fremdsystemen integrierte Umgebung bereitgestellt werden muss, und
zweitens zahlreiche Parameter an den verschiedenen Hardware- und Software- Komponenten eingestellt und ggf. optimiert werden müssen, und
drittens die beteiligten Anwendungen funktional annähernd vollständig implementiert sein müssen,

damit sich am Ende betriebsrelevante Aussagen ableiten lassen.

Lauten diese Aussagen dann z.B., dass erheblich mehr Hardware-Ressourcen benötigt werden als geplant, oder gar, dass sich das System nicht mittels Clustering skalieren lässt, dann ist „das Kind in den Brunnen gefallen“, denn dann sind schnell Release-Termine gefährdet oder Mehrkosten unumgänglich.

Daher ist es erforderlich, früh und regelmäßig Tests im Rahmen der Entwicklung durchzuführen. Diese Tests werden zwar keine betriebsrelevanten Aussagen liefern und sicher auch gewisse Probleme unentdeckt lassen, die sich erst beim „großen Lasttest“ feststellen lassen.

(Da wären dann nämlich

Probleme im Zshg. mit der Integration mehrerer Systeme und deren Interaktionen,
Probleme beim Zusammenspiel der Hard- und Softwarekomponenten der Produktion, und
Netzwerkprobleme bei Erreichbarkeit (Firewalls), Durchsatz und Latenz.

)

Folgende Schwachstellen des einzelnen Systems können dennoch frühzeitig gefunden und eliminiert werden:

Nicht performante und/oder instabile Produkte oder Produktteile
Sehr ungünstige Parametereinstellungen bei Produkten
Ineffiziente Algorithmen
Ineffiziente Datenbankabfragen oder ungünstiges DB-Schema Design
Probleme durch Multithreading und Parallelität
Speicher- und sonstige Ressourcenlecks
Unnötiges wiederholtes Laden/Bearbeiten von Daten

Man kann diese entwicklungsbegleitenden Lasttests mit Unittests vergleichen, die lange vor einem teuren Systemtest naheliegende Fehler finden und beseitigen helfen. So, wie Unittests eine Pflicht für die tägliche Entwicklungsarbeit sind, gehören regelmäßige Lasttests meines Erachtens auch zum 1x1 eines Entwicklungsteams.

Und ebenso, wie es frei verfügbare und preiswerte Werkzeuge für Unittests gibt, sind auch Capture-Werkzeuge, Lastsimulatoren und Instrumentierungshilfen frei erhältlich und in wenigen Stunden einsatzbereit.

Wer seine Tool-Favoriten dafür noch nicht hat, kann folgendes mal ausprobieren:

The Grinder 3 zur Aufzeichnung und Lastsimulation.
JAMon für Zeiterfassung an Messpunkten.
Spring 2.0 AOP für eine elegante Messpunktkonfiguration.

Der Aufwand für die Konfiguration bis zu ersten Tests beläuft sich je nach System nur auf wenige Stunden bis einige Personentage. Das ist preiswert genug, um so früh zum Einsatz zu kommen, dass die böse Überraschung kurz vor Inbetriebnahme hoffentlich ausbleibt.