Seite 3: Tipps & Fazit

Inhaltsverzeichnis

Gewusst, wie

Generell gilt, vom Einfachen zum Komplexen zu testen, also gewissermaßen "direkt vor dem Server". Soweit umsetzbar sollte man einzelne Serverschichten oder Anwendungen isoliert und einzeln für sich testen, um sie erst im zweiten Schritt in ihrem Zusammenspiel zu untersuchen. Zwischen dem Last erzeugenden Client und dem Server sollten keine Assets sein – und wenn doch, sollte der Testende das wenigstens als potenzielle Fehlerquelle wahrnehmen.

Ließen sich aus einem bestimmten Fehlersymptom – sei es im Produktivbetrieb, sei es während der Testprozesse – Hypothesen ableiten, können sie am besten in einem Iterations- und Ausschlussverfahren be- oder widerlegt werden. Dabei lassen sich wie in einem naturwissenschaftlichen Experiment einzelne Parameter – getestete Anwendungen, Testtiefen, Lastgrößen – systematisch verändern und die Ergebnisse protokollieren. Sinnvoll ist es auch, aussagekräftige und grafisch aufbereitete Relationen herzustellen zwischen Größen wie: (a) erzeugte Last, (b) Ist-Wert "Lade- und Antwortzeiten" sowie (c) Soll-Wert "Lade- und Antwortzeiten". Oder: (a) Dauer der Maximallast, (b) tatsächliche Zeitspanne bis zur Rückkehr des Servers zum Normalzustand, (c) tolerierbare Zeitspanne bis zur Rückkehr zum Normalzustand.

Zu warnen ist in jedem Fall davor, ohne Gegenchecks scheinbar sicheren Ergebnissen zu vertrauen. Zu groß ist das Risiko, durch eine falsche Diagnose viele Personenstunden auf die Beseitigung nur scheinbar bestehender Probleme zu verschwenden. Testläufe sollte der Tester generell über eine längere Zeitspanne hinweg vornehmen, damit er "Ausreißer" und zufällige Abweichungen nicht als Regel fehlinterpretiert. Sind die Fehler identifiziert, sollte er nach jeder einzelnen Systemmodifikation wiederum untersuchen, ob sie tatsächlich den angestrebten Erfolg bringt. Es empfiehlt sich, mit der geringst möglichen Modifikation zu beginnen und im Trial-and-Error-Verfahren erst dann, falls nötig, umfassendere Veränderungen vorzunehmen.

Neben einer fehlenden oder unzureichend durchgehaltenen Test-Methode sind noch weitere Unachtsamkeiten verantwortlich für verfälschte Testergebnisse. Zu den häufigsten Fehlern, die Ergebnisse verfälschen können, gehört der sogenannte Kaltstart ohne vorangehende Aufwärmphase: Entscheidend ist es, eine Test-Sequenz nicht unmittelbar von "0 auf 100" zu beginnen. Ein solches Szenario ist nicht nur unrealistisch, es kann auch zu Crashes führen, die nichts über die tatsächliche Stabilität der IT-Infrastruktur aussagen. Im Rahmen einer "Start-up Policy" sollten Server und System aufgewärmt werden, damit die zur Verfügung stehenden Verbindungen und Ausführungsstränge durch korrekt aufgebaute Zuteilungen in ihrem vollen Potenzial zur Verfügung steht.

Ein weiterer Punkt: Manchmal lassen sich Last- und Stresstests nicht umfassend kommunizieren, und der Produktivbetrieb läuft während der Testphase weiter. Solche Interferenzen zwischen Produktiv- und Testbetrieb haben nicht nur den Nachteil, dass sie die Testresultate beeinflussen, sondern können dazu führen, dass der künstlich generierte Traffic die realen Nutzer behindert oder die ohnehin bestehenden Verfügbarkeitsprobleme noch verschärft. Fehlt eine klare Abstimmung, können auch nicht deaktivierte Security-Tools wie Intrusion Detection oder eine Firewall die Last- und Stresstests behindern.

Weitere typische Fehler sind: Die Datenbank wird nach dem Test und den künstlich generierten Anfragen nicht zurückgesetzt.

• Im Webshop werden virtuelle Bestellungen nicht "storniert", sondern weiter bearbeitet.
• Es wird kein Backup erstellt, was das Anlegen von Maximallast zu einem unkalkulierbaren Risiko macht. Zu wenig verfügbare Bandbreite und Performance-Defizite auf dem Client, der Zugriffe künstlich erzeugt, verfälschen die Ergebnisse.Verschlüsselung und Authentifizierung werden nicht in die virtuellen Nutzerprofile einbezogen, sodass eine der Hauptursachen für Bottlenecks unberücksichtigt bleibt.

Fazit

Last- und Stresstests sind ein wichtiges Diagnosetool für Webentwickler und IT-Administratoren. Aber wie alle Werkzeuge funktionieren sie erst, wenn sie eindeutig definierten Zwecken dienen: Fragen und Testziele müssen vorher geklärt sein. Dann lassen sich die künstlich generierten Serveranfragen so konfigurieren, dass sie aussagekräftige Daten liefern. Wie in jedem Experiment ist es entscheidend, die Resultate zu dokumentieren und methodisch exakt vorzugehen. Das kann zum Beispiel bedeuten, zunächst die gewünschten sowie die tatsächlichen Klickpfade der User zu bestimmen, bevor man die Last- und Stresstests realitätsnah aufsetzt. Unsystematisch vorzugehen ist wenig effektiv. Um auf das Beispiel aus der Automobilbranche zurückzukommen: Autos einfach gegen die Wand zu steuern ist sicherlich kein Crashtestverfahren, das geeignet wäre, die Fahrgastsicherheit zu erhöhen.

Alexander Kunz
ist seit 2008 Business Development Manager bei Neotys SAS. Als urspünglich studierter Maschinenbauer profiliert er sich seit 20 Jahren unter anderem bei Nextra/Tiscali und Daimler AG im Bereich IT & Netzwerk. (ane)