Testing und Lasttests: Infrastruktur unter kontrollierten Bedingungen prüfen

Ob eine Umgebung ihre Spitzenlast verkraftet, ein Regelwerk sich nach einem Umbau gleich verhält oder ein Storage-Mount unter realen Zugriffsmustern durchhält, zeigt sich nicht im Datenblatt, sondern im Test. Diese Seite bündelt die Methodik, die allen Testarten gemeinsam ist: Was gemessen wird, wie ein Testablauf aufgebaut ist, welche Werkzeuge Last erzeugen und auffangen, und wie aus Rohdaten belastbare Aussagen werden.

Die wichtigste Regel steht vor jeder Methodik: Last- und Störtests gehören ausschliesslich auf eigene Systeme oder in ausdrücklich dafür freigegebene Umgebungen. Ein Burst gegen fremde Infrastruktur ist ein Angriff; ein Mailtest mit erfundenen Absendern gegen produktive Ziele erzeugt Backscatter und Blocklisten-Einträge.

Funktionstest und Lasttest trennen

Ein Test beantwortet immer genau eine Frage, und die beiden Grundfragen verlangen unterschiedliche Aufbauten. Der Funktionstest prüft, ob ein Pfad korrekt funktioniert: eine einzelne SMTP-Transaktion mit voller Kontrolle über jeden Schritt, ein einzelner Dateizugriff, ein einzelner Regelpfad durch ein Gateway. Der Lasttest prüft, wie sich das System unter Volumen verhält: Durchsatz, Latenzverteilung, Warteschlangen, Ressourcenverbrauch.

Die Reihenfolge ist zwingend: erst der Funktionstest, dann die Last. Ein Burst über einen fehlerhaften Pfad misst nichts; er produziert nur zehntausend gleichartige Fehler. Ein Fehlerzähler von 100 Prozent bei Antwortzeiten nahe null bedeutet fast immer, dass der Fehler vor dem Netzwerk passiert und der Test das Zielsystem nie erreicht hat.

Die vier Messgrössen

Lasttests in mehrstufigen Umgebungen messen vier verschiedene Dinge, und jede Grösse verlangt einen eigenen Blickwinkel:

1. Annahmerate: Wie viele Vorgänge pro Sekunde nimmt der erste Hop entgegen? Das ist der Wert, den Lastgeneratoren direkt liefern.
2. Session-Latenz: Wie lange dauert eine einzelne Transaktion? Unter Last steigt dieser Wert oft lange, bevor die Annahmerate einbricht.
3. Ende-zu-Ende-Latenz: Wie lange braucht ein Vorgang über alle Zwischenstufen bis zum Ziel? Das ist die Grösse, die Anwender wahrnehmen.
4. Queue-Verhalten: Wie tief wächst die Warteschlange während der Spitze, und wie schnell läuft sie danach leer? Ein System, das alles annimmt und stundenlang abarbeitet, besteht den Annahmetest und fällt trotzdem durch.

Testablauf: Baseline, Burst, Soak

Ein belastbarer Test läuft in drei Stufen mit je eigener Fragestellung. Die Baseline legt mit moderater, bekannter Last die Referenzwerte für Latenz und Ressourcenverbrauch fest und deckt Konfigurationsfehler auf, bevor sie in der Spitzenmessung untergehen. Der Burst ist die eigentliche Spitzenlastmessung; mehrere Durchläufe mit steigender Parallelität zeigen, wo die Annahmerate abflacht und die Latenz stark ansteigt. Der Soak fährt die erwartete Dauerlast über Stunden; erst hier zeigen sich Speicherlecks, volllaufende Spool-Partitionen und Verbindungs-Limits, die ein kurzer Burst nie erreicht.

Dazu gehören drei Handwerksregeln. Erstens der Generator-Selbsttest: Vor dem ersten Lauf gegen das Zielsystem läuft der Generator direkt gegen die Senke; das belegt, dass der Aufbau die Zielrate überhaupt erzeugen kann, und liefert die Obergrenze, mit der spätere Messungen verglichen werden. Zweitens die Markierung: Jeder Testvorgang trägt einen eindeutigen Marker (eigener Header, Betreffkonvention, Lauf-Nummer), damit sich Läufe in den Logs sauber trennen und Testdaten nachher restlos aufräumen lassen. Drittens der Kontrollversuch: Eine unabhängige Zählung auf der Empfangsseite bestätigt, dass angekommen ist, was der Generator gesendet hat; stimmen die Zahlen nicht überein, ist unterwegs etwas verloren gegangen.

Werkzeuge: Generator und Senke

Ein Lasttest besteht immer aus drei Teilen: Lastgenerator, Testsystem und kontrollierter Senke. Für SMTP-Last sind die gängigen Generatoren smtp-source aus dem Postfix-Paket (maximale Rohlast mit minimalem Aufwand), Postal (Dauerlast mit Zielrate und variierenden Nachrichten), Apache JMeter (Lastprofile, Perzentile und HTML-Report, unter Windows erste Wahl) und eigene Skripte, wenn der Test realistische Vorgangsmixe braucht. swaks ist kein Lastgenerator, gehört aber als Funktionstester vor jeden Burst.

Auf der Empfangsseite nimmt eine Senke alles an und verwirft es: smtp-sink, das zu Postal gehörende bhm oder ein kleiner aiosmtpd-Server in wenigen Zeilen Python, der nebenbei die Kontrollzählung übernimmt. Entwickler-Werkzeuge mit Web-Oberfläche sind als Lasttest-Senke ungeeignet; bei zehntausenden Vorgängen wird sonst das Analysewerkzeug statt des Testsystems vermessen.

Auswertung: Perzentile, Pivot, Verlauf

Aus Rohdaten werden Aussagen erst durch drei Auswertungsschritte. Perzentile statt Mittelwerte: Ein Durchschnitt von zwei Sekunden kann bedeuten, dass alles zwei Sekunden dauert, oder dass 95 Prozent in einer halben Sekunde abgeschlossen sind und der Rest deutlich länger brauchte; p50, p95 und p99 unterscheiden diese Fälle. Fehler pivotieren: Die Verteilung der Fehlercodes über die Zeit zeigt, wann ein System zu drosseln beginnt und welcher Schutzmechanismus zuerst greift. Verlauf statt Endstand: Durchsatz und Queue-Tiefe über die Zeit aufgetragen zeigen Ramp-up, Plateau und Auslauf; für die Interpretation zählt das Plateau, nicht der Durchschnitt über den Gesamtlauf, denn der enthält An- und Auslauf und unterschätzt die erreichte Dauerrate.

Zur Auswertung gehört zuletzt die ehrliche Abgrenzung: Jeder Testbericht hält fest, was der Lauf belegt und was nicht. Eine Messung ohne TLS sagt nichts über TLS-Handshake-Kosten; eine lokale Senke nichts über das Queue-Verhalten des echten Ziels; ein Burst nichts über Speicherlecks im Dauerbetrieb. Diese Grenzen benennen die nächsten Testläufe.

Die Artikel unten führen die Methodik an konkreten Fällen durch: Werkzeugvergleich und Testplanung für Mail-Lasttests, ein vollständig durchgeführter JMeter-Lauf mit HTML-Report, schichtweise SMTP-Diagnose mit Bordmitteln, ein Testplan für Cloud-Storage-Mounts und die wissenschaftliche Methode hinter kontrollierten Experimenten im Mailfluss.