Mit dem Mailserver-Benchmark Postal Engpässen auf der Spur

Mailserver jonglieren mit Zigtausenden von Nachrichten und kommunizieren viel mit fremden Servern. Dabei sind sowohl SMTP (Simple Mail Transfer Protocol) als auch das Message-Format reichlich vielseitig. Sich in diesem Zusammenspiel als Admin überhaupt zurechtzufinden ist schon schwer genug. Noch komplizierter wird es, wenn die Aufgabe Optimierung lautet - ohne systematisches Vorgehen und Tools wie den hier vorgestellten Postal-Benchmark ein aussichtsloses Vorhaben.

Mailserver-Benchmarks helfen eine Basislinie zu ermitteln, die als Ausgangs- oder Bezugspunkt für künftige Verbesserungen dient. So lässt sich kontrollieren, wie eine Änderung an einem Parameter die Performance beeinflusst. Der Begriff Benchmark übersetzt sich passenderweise mit Bezugswert, Tauglichkeitstest oder Vergleichstest.

Die Anforderungen an Mailserver und damit an die Messtechnik unterscheiden sich je nach Einsatzgebiet. Der Server kann zum Beispiel als Mailrelay dienen, als Kommunikations- und Groupware-Server mit lokalen Mailboxen arbeiten oder als Virenscanner und Spamfilter zwischengeschaltet sein. Je nach Szenario wechselt auch die Position im Netzwerk, mal steht der Server als Mail-Gateway am Internetzugang (Abbildung 1), mal im internen Firmennetzwerk/LAN oder hinter einem Loadbalancer. All das muss ein Benchmark berücksichtigen.

Abbildung 1: Ein Relay-Mailserver in der DMZ muss viele von außen unabhängig voneinander eintreffende Verbindungen verarbeiten, die sich zeitlich überlappen. Er reicht die Mails dann zum internen Server durch.

Laboraufbau

Es ist relativ einfach, per Mailserver-Reporting-Funktion eine Basislinie im Produktivbetrieb zu ermitteln. Ungleich schwieriger zu entwerfen sind sinnvolle generische Testumgebungen für das Benchmarking verschiedener Mailserver unter Laborbedingungen. Abbildung 2 zeigt die typische Topologie für Labormessungen. Ein leistungsfähiger GBit-Backbone verbindet Server und Clients: den Mailserver, einen Client mit der Benchmark-Applikation Postal und eine E-Mail-Senke (Empfänger). In der Realität haben die Antwortzeiten von Directory Services großen Einfluss auf die Performance (LDAP, DNS oder Active Directory, siehe Artikel in diesem Schwerpunkt). Unter Laborbedingungen schließt die Konfiguration des Mailservers solche Störeinflüsse aus.

Abbildung 2: Im Labortest sind ein Postal-Client (er simuliert die E-Mail-Absender), der Mailserver und eine Mail-Senke (das Ziel der weitergereichten Nachrichten) per Switch verbunden.

Lastgenerator

Geeignet parametrisiert bildet Postal jede Last nach, die der Server zu bewältigen hat. Deren Menge und Charakteristik hängen von der Position und den Aufgaben im Netz ab (Abbildung 1). Bei der Simulation eines Mailrelay ist zudem ein zweiter Mailserver nötig, der wahllos ankommende E-Mails annimmt und vernichtet. Sendmail und Postfix lassen sich mit wenig Aufwand als so genannte Mail Sink konfigurieren. Noch leichter klappt es mit dem Perl-Skript von Thomas Aeby [4] aus Listing 1.

01 #!/usr/bin/perl
02 
03 use Net::SMTP::Server;
04 use Net::SMTP::Server::Client;
05 use Getopt::Long;
06 use strict;
07 
08 my $port = 25;                  # Default listen port
09 my $bindaddr = "localhost";     # Bind to localhost only by default
10 GetOptions ("p=i" => $port, "b=s" => $bindaddr)
11   || die "Usage: $0 [-p port] [-b bind-address]";
12 
13 print "setting up server listening on port $bindaddr:$portn";
14 my $server = new Net::SMTP::Server($bindaddr, $port)
15   || die "Cannot setup server: $!";
16 
17 while(my $conn = $server->accept()) {
18   # Got one incoming connection.
19   # Fork off a child process handling it
20   next if( fork() > 0 );
21   my $client = new Net::SMTP::Server::Client($conn)
22     || die "Unable to handle client connection: $!";
23   # Talk to the client
24   $client->process
25     || die "Client didn't send us mail";
26   # log info and terminate
27   system("logger", "-s", "-p", "local1.notice", "-t", "mailsink",
28     "got mail from ".($client->{"FROM"}).
29     " for ".join(",",@{$client->{"TO"}}).
30     ", message size: ".length($client->{"MSG"})." bytes" );
31   exit(0);
32 }

Ohne E-Mail-Senke bliebe immerhin ein vereinfachter Test, bei dem der Client nur Mailheader sendet und die Verbindung schließt, bevor der Body kommt. Die meisten Mailserver werten die Message Header sofort aus, daher fließt dieser Schritt noch in die Messung ein. Diese Technik eignet sich auch, um einen Loadbalancer zu testen, weil sich schnell herausstellt, nach welchem Algorithmus er die Last auf die Server verteilt.

Es mag überraschen, dass ein einfacher Client-PC genügt, um die Leistungsgrenzen eines gut ausgestatteten Mailservers auszuloten. Doch eine Mail erzeugen, mit Buchstabensalat füllen und absenden kostet kaum Rechenzeit und braucht auch keine Festplattenzugriffe. Nur die Netzwerkkarte muss ausreichend dimensioniert sein. Ganz anders beim Parsen der eingehenden Nachrichten auf dem Server - der muss sich mit allen erdenklichen Formaten und Kodierungen auseinander setzen.

Auch der Einfluss der Mail-Senke ist gering, sie muss nur für alle zu vergleichenden Mailrelays identisch bleiben. Ein gutes Relay arbeitet auch dann flott, wenn die Zielserver lahmen und das Relay die Mails in Warteschlangen (Queues) zwischenpuffert. Ein Vergleich bei gleich bleibendem Mailserver und einmal schnellen und einmal langsamen Mail-Senken erlaubt Rückschlüsse auf die Queue-Geschwindigkeit. Sie hängt zum Beispiel vom Filesystem oder den verwendeten NFS-Mounts ab.

Die Schreibvorgänge bei Mailrelays richten sich nach der Verfügbarkeit und Geschwindigkeit der Zielserver. Ihr Schreibverhalten unterscheidet sich aber deutlich von Mailservern mit lokalen Mailboxen: Während ein Relay viele Schreib- und Löschzugriffe hat, häufen sich bei Servern mit lokalen Mailboxen die Schreiboperationen, um ankommende E-Mails an eine (eventuell schon recht große) Mbox-Datei anzufügen.