pixelio.de, A. Reis

Wie schnell ein Mailserver arbeiten wird, wenn ihn 1000 User gleichzeitig traktieren, klärt vorab nur eine strenge Prüfung. Dieses Benchmarking erledigt Mstone im Alleingang für alle relevanten Protokolle.

Die User klagen, der Admin flucht: Der uralte Mailserver oder das nagelneue CMS seien viel zu lahm, meinen die ersten. Er kann es nicht nachvollziehen, schimpft der zweite. Ihm fehlt ein Werkzeug, das die objektive Geschwindigkeit misst, in Form von Antwortzeiten und Durchsatz. Weil solche Messungen meist im Laborbetrieb anfallen, wenn keine realen User Anfragen stellen, muss das Tool selbst für eine realistische und reproduzierbare Last sorgen.

Diese Aufgabe stellt sich neben Admins auch Entwicklern. Beide wollen sehen, wie ein Server auf Anfragen reagiert. Bei Mailservern ist das besonders komplex, da etliche Protokolle und Komponenten im Spiel sind: Mails treffen per SMTP ein, der Mailserver versucht vielleicht Spam und Mailwürmer zu erkennen, sortiert alles in die Benutzermailboxen und liefert die Nachrichten dann via IMAP wieder aus. Dabei besteht der Mailserver aus vielen Einzelkomponenten und zu allem kommt noch eine Benutzerverwaltung hinzu.

Mstone [1] nimmt es mit der Komplexität auf. Als Kombination eines Lastgenerators und eines Benchmarkprogramms wurde es Ende der 90er Jahre bei Netscape geboren und auf den Namen Mailstone getauft. Die Firma nutzte Mailstone intern, um die vielen E-Mail-Protokolle zu testen, die ihr Netscape Messaging Server unterstützte. Zudem gab sie an die eigenen Kunden kompilierte Binary-Versionen heraus, damit auch diese ihre Mailserver testen konnten.

Im Jahr 2000 hat die inzwischen von AOL gekaufte Firma Netscape ihr Mailstone in Mstone umbenannt und nach Mozilla-Vorbild als Open Source freigegeben. Seither ist Mstone einen weiten Weg gegangen in Richtung eines universellen Benchmarking-Tools. Heute misst Mstone die Performance von HTTP, POP3, IMAP (und des Netscape-eigenen Ablegers WMAP) sowie SMTP. Bei installiertem Gnuplot stellt Mstone die Resultate grafisch dar. Laut Roadmap planen die Entwickler auch Instant Messaging (ICQ), DNS, LDAP und Festplattenperformance zu messen.

Für Mailserver-Benchmarks [2] kam im Linux-Magazin bisher Postal ([3], [4]) zum Einsatz. Der Kasten “Mstone vs. Postal” vergleicht die beiden Programme. Für Webserver-Tests ist die Auswahl an Alternativen größer, etwa Jmeter [5], Siege [6], Httperf [7] oder der Apache-Bench »ab« [8].

Keine Pakete

Mstone steht unter der Netscape Public License. Weder unter Red Hat (YUM) noch unter Ubuntu (Aptitude) oder Mac OS X (Fink) sind fertige Mstone-Pakete zu finden. Daher ist beim Test bereits zu Beginn Handarbeit angesagt. Die Installation ist zwar im Prinzip einfach, doch erschwert die Dokumentation diese Aufgabe: Sie beschreibt einige Prozeduren falsch oder unvollständig. Die nachfolgend erklärten Schritte führten beim Autor mit Mstone 4.9.1 unter Ubuntu 6.10 zum Erfolg.

Zum Kompilieren sind GCC und Make nötig. Wer die Ergebnisse als HTML verbreiten will, sollte noch Apache installieren, und für grafische Resultate ist Gnuplot nötig. Beides lässt sich auch später nachholen. Ein Alias-Eintrag in der Apache-Konfiguration bindet das Results-Verzeichnis von Mstone ein:

Alias /results/ /Pfad/mstone-4.9.1/results/

Mstone setzt sich im Wesentlichen aus zwei Teilen zusammen: einem Shellskript namens »mstone«, das alle weiteren Schritte steuert, und einer binären Applikation namens »mailclient«, die es zu kompilieren gilt. Das erledigt der Aufruf »make rpackage« im ausgepackten Mstone-Verzeichnis, er kompiliert das Binary in einem neuen Unterverzeichnis »build/Linux2.6_x86«. Diese Struktur ist praktisch, wenn man das Mstone-Verzeichnis per NFS auf unterschiedliche Plattformen verbreitet – das Shellskript sucht sich immer das zur Plattformarchitektur passende Binary.

Setup aufsetzen

Anschließend ist das Mstone-Shellskript an der Reihe. Es erzeugt mit »./mstone setup« eine zum System passende Konfiguration. Wer etwa Gnuplot nachträglich installiert, ruft anschließend »./mstone setup« erneut auf. Damit erfährt Mstone, dass es jetzt Grafen malen soll. Gleichzeitig synchronisiert dieser Aufruf alle vom Testmaster kontrollierten Clients (siehe Abbildung 1).

Abbildung 1: Ein typisches Mstone-Setup besteht aus einem Testmaster (Mitte) und mehreren Testclients (rechts). Der Master versorgt die Clients mit Aufträgen und synchronisiert ihre Systemzeit. Die Clients wiederum stressen die Server (links) mit SMTP-Traffic und holen Mails via IMAP ab.

Seit Version 4 kompiliert Mstone auf Windows und Linux, allerdings nur dann, wenn es alle Komponenten am erwarteten Platz vorfindet. Änderungen am Makefile sind recht schwierig. Für die nächste Release will Mstone-Entwickler Dan Christian deshalb sein Build-System auf Cmake [9] umstellen sowie das Tar-Archiv aufräumen.

Test-Topologie

Mstone arbeitet nach dem Client-Server-Prinzip. Ein Testmaster konfiguriert alle Testclients und sammelt deren Resultate. Im einfachsten Fall befinden sich Master und Client auf einem gemeinsamen Rechner, diese Infrastruktur bleibt vor dem Tester verborgen. In einer verteilten Umgebung (Abbildung 1) müssen die Testclients so konfiguriert sein, dass sich der Testmaster per SSH ohne Benutzerinteraktion einloggen kann. Dazu gilt es, die ».shosts«-Dateien der Clients anzupassen oder den SSH-Key des Testmasters in die Authorized-Keys-Dateien der Testclients einzutragen.

Im Test hat die Kommunikation von Master und Clients erstaunlich gut funktioniert. Diese Konstruktion hat den großen Vorteil, dass mehr Clients auch mehr Last erzeugen können und dass sie die Realität besser abbilden.

Die Installation von Mstone auf Testmaster und Testclient ist identisch. Wichtig ist nur, dass die Systemzeit auf allen physikalischen Testclients nicht mehr als 2 Sekunden divergiert. Am besten ist das zu erreichen, wenn der Testmaster als NTP-Server dient.

Die Konfiguration von Mstone ist derzeit in einer ärgerlichen Umbruchphase. Früher genügte es, »./mstone config« aufzurufen, alle Fragen zu beantworten und die Clients mit »./mstone setup« zu synchronisieren. Der Mailserver musste dann noch die Testbenutzer-Konten kennen – und ab ging die Post mit »./mstone smtp -t 60m«. Heute funktioniert das leider nicht mehr so einfach.

Moderne Konfiguration

Der Dialog in »./mstone config« schreibt nur noch eine LDIF-Datei (LDAP Data Interchange Format, RFC 2849), sie ist für den Import in einen LDAP-Server gedacht. Dummerweise stellt Mstone das dazu passende Schema nicht bereit. Die LDIF-Datei ist auf einen Netscape Messaging Server und Netscape Directory Server zugeschnitten. Diese Produkte hießen zwischenzeitlich I-Planet Messaging Server und I-Planet Directory Server, heute tragen sie die Namen Sun One Messaging Server und Sun One Directory Server. Ohne passendes Schema können freie Alternativen wie OpenLDAP mit der LDIF-Datei aber nichts anfangen.

Die Idee an sich ist dennoch gut. Bei komplexeren Tests mit IMAP und POP3 muss der Admin drei Faktoren pro Testaccount passend konfigurieren: E-Mail-Adresse, Username und Passwort. Da ein sinnvoller Test vielleicht 500 oder 5000 Konten braucht, ist das manuell nicht mehr machbar. Ein LDIF für den LDAP-Server ist hier durchaus charmant. Da dies aber nicht klappte, übernahm im Test ein selbst geschriebenes Shellskript die Aufgabe. Die Mstone-Konfiguration empfiehlt lapidar, das LDIF selbst anzupassen oder andere Wege zu finden.

Arbeitslast

Für alle interessanten Einstellungen ist Handarbeit an den Konfigurationsdateien angesagt, die im Mstone-Jargon Workload-Dateien heißen und auf ».wld« enden. Diese Files sind in einer XML-Sprache verfasst, die alle Parameter zu funktionellen Elementen gruppiert. Jedes Element beginnt mit einem öffnenden »<Tag>« und endet mit einem schließenden »</Tag>«.

Leider fehlen noch eine DTD (Document Type Definition) oder eine Schema-Datei. Die wären vor allem beim Schreiben mit einem XML-Editor praktisch, der dann automatisch die Syntax prüft.

Zu jedem Service, den Mstone messen kann, gibt es im Unterverzeichnis »conf« ein Beispiel für eine Workload-Datei. Diese verweist in guter XML-Manier per Include auf die »general.wld«, die alle globalen Parameter definiert. Interessant sind dabei nach Auskunft des Entwicklers Dan Christian lediglich die ».wld«-Dateien; alle weiteren Files, zum Beispiel mit der Endung ».wld.in«, sind Überbleibsel aus der Vergangenheit oder Musik der Zukunft und daher zu ignorieren. Als Ausgangspunkt für eine eigene »general.wld« stehen die Dateien »general.wld.in« und »sampl.wld« zur Wahl.

Elementares

Die »general.wld«-Datei kennt die drei Pflichtelemente »<CONFIG>«, »<CLIENT>« und »<DEFAULT>«. Das Config-Element nimmt Parameter für den Testmaster auf, zum Beispiel Testzeit oder Testtitel. Im Client-Element befinden sich Parameter für die Testclients, im einfachsten Fall steht hier nur »localhost«. Parameter, die unabhängig vom getesteten Protokoll sind, stecken praktischerweise im Default-Element.

Die protokollspezifische Datei (für IMAP, SMTP, HTTP …) kann jeden Parameter aus dem »<CONFIG>«-Element der »general.wld« überschreiben und eigene Parameter ergänzen. Listing 1 zeigt eine einfache »smtp.wld«-Datei, die den SMTP-Verkehr testet. Nebenbei füllt sie die Testmailboxen mit Inhalt, um spätere IMAP- oder POP-Tests vorzubereiten. Listing 2 zeigt eine noch einfachere »http.wld« für einen Webserver-Test. Mit Ausnahme des HTTP-Protokolls sind alle Parameter sehr gut in der HTML- und Open-Office-Dokumentation von Mstone beschrieben. Diese ist als eigenes Tar-Archiv auf der Projektseite [1] verfügbar.

01 # Mailzustellung via SMTP, füllen nebenbei die
02 # Mailboxen für spätere POP- und IMAP-Tests
03 
04 <includeOnce conf/general.wld>
05 
06 <CONFIG>        # test specific config
07   title         SMTP message deliveries
08   clientCount   1
09   clientCommand mailclient
10 </CONFIG>
11 
12 # Test-E-Mails verschiedener Größe einbinden, um
13 # eine realitätsnahe Verteilung zu erhalten
14 <include conf/smtp1k.wld>
15 <include conf/smtp5k.wld>
16 <include conf/smtp17k.wld>

01 # Einfache HTTP GETs
02 # funktionieren wenn es einen Default-Server ohne
03 # Redirect gibt; andernfalls komplette URL angeben
04 
05 <includeOnce conf/general.wld>
06 
07 <HTTP>
08   weight 100    # Defaulteinstellung
09   numLoops 1    # der Test wird einmal durchlaufen
10   httpcommand   GET /
11 </HTTP>

Schicke Spamschleuder

Interessant ist, dass Mstone unterschiedliche Protokolle auch kombinieren kann. Sinnvoll ist das zum Beispiel bei POP, IMAP und SMTP: Sie gleichzeitig zu testen kommt dem wirklichen Gebrauch eines Mailservers sehr viel näher als drei Einzeltests. Überhaupt haben es die Programmierer von Mstone sehr ernst genommen, eine realistische Testumgebung zu schaffen. Das reicht bis zu den Testmails, die es via SMTP absetzt.

Im Unterverzeichnis »data« liegen schon elf vorgefertigte Spam-Mails mit einer Größe zwischen 750 Bytes und 32 KByte, verschiedenen Zeichensätzen und zum Teil eingebetteten Bildern. Wer Mstone zum ersten Mal einsetzt, staunt wahrscheinlich nicht schlecht, wenn sich seine Testmailboxen plötzlich mit Spam füllen (Abbildung 2).

Abbildung 2: Mstone meint es ernst mit realistischen Tests und feuert per Default eine Spam-Ladung auf den Mailserver. Die Auswahl an Mails lässt sich recht einfach an eigene Wünsche anpassen: Es genügt, passende Beispiele als »*.eml« in das »data«-Verzeichnis von Mstone zu legen.

Nach der hakeligen Konfiguration beeindruckt Mstone umso mehr. Die sehr umfassenden Parameter erlauben es, den Test exakt an die eigenen Bedürfnisse anzupassen. Im Gespann mit Gnuplot erzeugt Mstone detailreiche, aussagekräftige Grafen.

Mit den fertigen Workload-Dateien ist es sehr einfach, unterschiedliche Protokolle auf einem Server zu testen. So unterzieht der Befehl »./mstone pop -t 60m« den in der Konfigurationsdatei »general.wld« konfigurierten Server einem 60-minütigen Benchmark mit den in der Datei »pop.wld« konfigurierten POP3-Parametern (Usernamen, Passwörter, Anzahl und mehr). Das Kommando »./mstone imap -t 60m« macht Gleiches mit dem IMAP-Protokoll und den in »imap.wld« angegebenen Parametern.

Auswertung

Wenn man weiß, worauf zu achten ist, kann die Auswertung der Mstone-Testergebnisse erfrischend einfach ausfallen. Grob gesagt sind bei Benchmarks wenig Errors und viel Linearität angesagt. Stur die Responsezeiten und Durchsätze messen ohne Linearität und Fehler zu berücksichtigen ist gefährlich: Niemandem nutzt ein Durchsatz von 80 MBit/s, wenn ein Server ab 4 MBit/s nur noch Fehlermeldungen ausspuckt.

Abbildung 3 zeigt den 10-minütigen Verlauf der Verbindungsversuche und der Fehler eines kleinen Webservers bei einem Test mit zehn simulierten Clients. Jede Minute kam ein weiterer Client hinzu, dadurch ergibt sich die Treppenform im oberen Drittel der Abbildung. Jeder Mstone-HTTP-Client sendet 25 Requests pro Sekunde.

Abbildung 3: Oft ergibt sich wertvolle Information aus der Kombination mehrerer Grafen, die Mstone erzeugt hat. Links ist die Anzahl an HTTP-Verbindungsversuchen zu sehen, die zunächst treppenförmig ansteigt bis zur grünen Markierungslinie. Daneben die Anzahl der Verbindungen, die ab dem markierten Zeitpunkt abnimmt. Ursache für die Abweichung vom idealen Verlauf sind Verbindungsfehler, die der rechte Graf zeigt.

Es ist gut zu erkennen, dass schon drei Clients mit ihren 75 Verbindungen pro Sekunde starke Abweichungen von der Linearität und vermehrt Fehler hervorrufen. In dieser Gegend ist offenbar die Leistungsgrenze dieses Servers angesiedelt. Wer die Limits genauer erforschen will, würde den Webserver mit drei, maximal vier Clients weitertesten. Auch empfiehlt es sich, ihn zusätzlich mit längeren Rampen (etwa alle 15 Minuten einen neuen Client) sowie mit konstanter Last (etwa zwei Clients für 12 Stunden) zu untersuchen. Bei Langzeittests bereitet der »process«-Befehl (im Mstone-Wurzelverzeichnis) jederzeit die Zwischenergebnisse auf.

Treten unerwartet viele Fehler auf oder weichen die Ergebnisse stark von den Erwartungen ab, nimmt ein vorsichtiger Tester zudem seine Testumgebung unter die Lupe. Das Error-Log von Mstone enthält eventuell Hinweise auf systematische Fehler (durch falsche Konfiguration). Zudem ist zu klären, ob das Netzwerk einwandfrei arbeitet (Duplex-Konflikte, die Größe von Collision Domains, Einsatz von Switches anstelle von Hubs). Weitere wichtige Störgrößen sind Abhängigkeiten in der zu testenden Applikation, zum Beispiel vom DNS, oder übertriebenes Logging.

Wer vieles gibt

Abgesehen von der schlecht dokumentierten Konfiguration ist Mstone ein zuverlässiger und starker Helfer. Er visualisiert alle Ergebnisse, wenn nötig noch während ein Test läuft. Zusätzlich legt er alle Testergebnisse als CSV-Datei vor. Als sehr wertvoll erweisen sich die Rampen, also die Fähigkeit, die Last über einen vorgegebenen Zeitraum zu steigern. Hieraus leiten sich wertvolle Erkenntnisse ab, die andere Tools (zum Beispiel Postal für SMTP und POP3 oder »ab« für HTTP) nur schwer mittels aufwändiger Handarbeit liefern.

Durch den generischen Aufbau bleiben bei den Tests einzelner Protokolle leider auch Features unberücksichtigt, die in spezialisierten Tools sehr wohl zugänglich sind. Mstone unterstützt beim HTTP-Benchmarking keine Keepalives und auch kein HTTP 1.1. Beim Testen von IMAP- und POP3-Servern gibt es zu Mstone aber keine gute Alternative. Schon sein Stammbaum zeigt, dass das Tool dort seine Wurzeln hat. Die Vielzahl gut dokumentierter Parameter zum Test dieser Protokolle erlaubt detaillierte und exakte Analysen. (fjl)