Von: Jürgen Fey
Wer heute den idealen Server für seine Abteilung sucht oder eine kostenoptimierte Web-Server-Lösung (sprich: nicht zu groß aber um Gottes Willen auch nicht zu klein) bei seinem Serviceprovider aufstellen will, tappt bei der Auswahl des "richtigen" Geräts nicht selten im dunkeln. Allzu häufig kann der Serverhersteller lediglich nichtssagende, aber wohlklingende TPC-A, -B, -C oder -D-Werte offerieren, deren praktischer Wert sich dank der sehr abstrakten Ergebnisse für viele entzieht. Natürlich schafft man mit der "Darf es etwas mehr sein"-Philosophie so manches Problem aus der Welt, doch der kostenorientierte Käufer würde es oft gerne genauer wissen.
Um etwas Licht in die finsteren Tiefen der Serverleistungsdaten zu bringen, hat gateway eine eigene Benchmark-Suite entwickelt. Sie erlaubt eine differenzierte Aussage über die Leistungsfähigkeit eines Rechners in verschiedenen Anwendungsbereichen. Und sie ist natürlich auch Grundlage für die unabhängigen Servertests, die Sie jetzt regelmäßig in gateway lesen werden. Das grundlegende Ziel hierbei ist es, die Leistungsfähigkeit bekannter Server-Basis-Services wie beispielsweise POP, SMTP, HTTP, NFS, FTP oder auch von "Streaming-Medien" festzustellen.
Und da ein Service in der Regel nicht alleine kommt, haben wir für unterschiedliche Bedürfnisse auch entsprechende Antworten parat. Hierzu definieren wir Anwendungsprofile, um die stark divergierenden Anforderungen unter einen Hut zu bekommen. Die gesamte Benchmark-Sammlung wird nach der Fertigstellung zum Download bereitstehen, damit Sie Ihrer eigenen Systemumgebung intensiv auf den Zahn fühlen können.
Die Testsuite besteht aus drei funktional miteinander verkoppelten Systemen (Bild 1). Im Mittelpunkt steht der zu überwachende Testserver, der auf die von außen erzeugten Service-Requests wartet und diese nach bestem Wissen und Gewissen ausführt. Ein zentraler Master/Client-Prozeß koordiniert alle Aktionen von außen. Hierzu stellt er den "Arbeitspunkt" des Servers, sprich eine konstante Last, ein. Danach löst der Master alle gewünschten Service-Requests aus und überwacht die Aktionen.
Zum Erzeugen der Requests warten die auf externen Systemen in Java simulierten Clients auf ihre Chance. In statistisch erzeugten Zeiträumen treten die Clients in Aktion und belasten somit den Server mit einer vorgegebenen Last. Ein Zufallszahlengenerator sorgt für zeitlich verteilt aktivierte Requests, während sich die Multithreaded-Umgebung von Java gut für das "Ausschwärmen" der Clients eignet.
In der Mitte wacht ein Linux-System (Suse 5.3 Linux) transparent über den Status des Netzwerks. Dieses System übernimmt auch den NFS-Benchmark (NFS=Network File System). Hierzu mountet es mehrere Verzeichnisse des zu testenden Servers in lokale Pfade und sorgt danach parallel zu allen anderen Requests durch gezielte "Sticheleien", sprich Dateiaktionen, für zusätzlichen Traffic. Zur Koordination der NFS-Aktionen ist der Linux-Rechner mit dem Master-Client verbunden, so daß die Steuerung von einer zentralen Stelle aus erfolgt.
Zentrale Steuerung
Der Überblick in die derzeitige Struktur der Benchmark-Suite beginnt bei den Testclients. Ziel dieser Clients ist es, eine statistisch definierte Last auf dem Testserver zu erzeugen und dabei den aktuellen Status der atomaren Operationen in einer Log-Datei festzuhalten. Jeder Client meldet Fehler zudem direkt an den Master. Diese Information kann man zur Live-Anzeige nutzen. Die Clients simulieren das jeweils zugeordnete Protokoll, etwa das "Post Office Protocol" (POP). So lesen die Clients beispielsweise die E-Mail auf dem Server und schreiben oder löschen Nachrichten (siehe Kasten "Ein POP-Client"). Mitunter bringen, ganz wie im "richtigen Leben", falsche Kommandos oder ungültige Paßwörter etwas Sand in das Getriebe.
Damit man die Performance des Servers genauer definieren kann, legt jeder Client seine Anforderungen mitsamt der Angaben über die benötigte Zeit nach der vollständigen Abarbeitung in einer Log-Datei ab. Geht etwas schief, so findet sich eine entsprechende Fehlermeldung (mit einem definierten Timeout-Wert) in den Log-Daten. Damit alle Systeme das gleiche "Zeitgefühl" haben, synchronisieren kleine Routinen die Systemzeiteinträge mit der Realzeituhr des Servers.
Die Clientsimulation basiert auf Tabellen, in denen die Anforderungen zeilenweise eingetragen sind. Hierzu liest der Client die Tabelle beim Start in eine Hash-Tabelle ein und führt den Auftrag dann teilweise auch in Form einer "State Machine" durch. Je nach Antwort geht der Client also die nach den jeweiligen RFCs definierten Wege (solche "Requests for Comment" enthalten die genauen Definitionen der Internet-Protokolle). Die Protokolltabellen berücksichtigen dabei lediglich die wichtigsten Funktionen eines Service. Krasse Sonderfälle bleiben also ausgespart.
Lastmixturen
Natürlich darf man die Services nicht isoliert betrachten. Üblicherweise dient ein Server dazu, unterschiedliche Dienste zeitgleich anzubieten. Die gesamte simulierte Last besteht also wiederum aus einer Mixtur der einzelnen Anforderungen. Die Mixtur kombiniert definierte Services wie etwa POP oder HTTP (Get, Post, CGI), um eine möglichst praxisnahe Umgebung zu erzeugen. Der Definition der zu erzeugenden Lastmixtur kommt dabei natürlich eine besondere Bedeutung zu. Die gateway-Benchmarks haben zum Ziel, die Systemleistung eines typischen Serversystems in kleinen bis mittleren Unternehmen sowie in den einzelnen Abteilungen eines Großbetriebes zu untersuchen.
Weil der typische Mix heute längst nicht mehr ausschließlich die "klassischen" Datei- und Print-Services betrifft, haben wir unterschiedliche Einsatzmixes definiert, damit der Benchmark gesonderte Ergebnisse für heute typische Einsatzbereiche ausgeben kann. Bewußt herausgenommen ist hierbei der Test des Probanden als reiner Datenbankserver für eine bestimmte Datenbank, etwa Oracle oder Informix. Bei solchen Anwendungen hängen die Ergebnisse in der Praxis ohnehin stark von Tuning-Maßnahmen durch Spezialisten ab. Auch die auf diesen Datenbanken aufbauenden vertikalen Applikationen (Stored Procedures, Transaktionen et cetera) beeinflussen die Performance ganz massiv.
Middle Tier
Dennoch kommt die Benchmark-Suite an Datenbankanwendungen nicht vorbei. Hierzu ist auf einem fest im Testnetzwerk integrierten Referenzserver eine Datenbank installiert. Der Testserver dient dabei als "Middle-Tier"-Server, der einfache Anforderungen externer Clients bearbeitet, diese in SQL-Statements umformt, die aus der Datenbank zurückgelieferten Daten filtert oder umformt und sie anschließend zum Client zurückgibt. Um diesen Bereich zu testen, sind derzeit zwei unterschiedliche Varianten in Diskussion.
Zum einen können die Datenbankanfragen über den HTTP-Server ablaufen und bilden somit eine typische Intranet-Anwendung. Die Datenbankanfrage wird in diesem Fall an eine CGI-Routine übergeben, die den Zugriff auf die Datenbank abwickelt. Um eine möglichst große Systempalette durch den Benchmark universell ansteuern zu können, kommt an dieser Stelle die in diesem Umfeld längst bekannte Programmiersprache Perl mit bestens geeigneten Bibliotheken (DBD/DBI und ODBC) zum Einsatz. Spezielle Lösungen, die nur auf dem Server des Anbieters ablaufen, bleiben unberücksichtigt.
Die zweite Variante wäre ein neuer Serverservice, der als Systemdämon auf Aufträge wartet. Ausgeführt in Java, könnte ein solcher Multithreaded-Prozeß die Anforderungen entgegennehmen und per JDBC an die Datenbank weitergeben. An diese Lösung angelehnt ist die Realisierung als Servlet.
Bei einem Servertest bewegt man sich in einem Minenfeld – mit der einzigen Gewißheit, daß mit Sicherheit irgend eine Mine im Wege ist. Besonders die im Serverumfeld unendlich erscheinenden Optimierungsoptionen erschweren eine Leistungseinstufung. Die Benchmark-Suite der gateway-Redaktion betrachtet diesen Punkt sehr pragmatisch. Ein Vergleich zur Autoindustrie mag helfen.
Auch ein Auto bietet als technisches Objekt fast beliebige Optimierungsmöglichkeiten. Der Hersteller muß für den jeweiligen Einsatzzweck die optimale Einstellung finden. Die meisten Kunden wiederum vertrauen dieser Standardauslieferung. Einige wenige beginnen, das System "Auto" nach ihren Wünschen zu tunen. Die meisten Anwender betreiben ihre Server zumindest hinsichtlich der Standardservices oft in der vom Hersteller ausgelieferten Konfiguration in der Hoffnung, dieser habe die entsprechende Vorarbeit bereits geleistet.
Nicht selten verrichtet eine Serversoftware ihre Arbeit parallel zu einer Datenbank. Wir testen die Systeme aus diesem Grund mit einer definierten und konstanten Grundlast, die ständig auf dem Server aufrecht erhalten wird. Diese Grundlast simuliert eine Datenbanklast. Die Grundlast kann aber ebenso einen gerade durchgeführten Backup-Lauf (externe WWW-User nehmen auf Wochenenden und Nachtzeiten keine Rücksicht!) oder einen für Streaming-Medien typischen Codec-Run simulieren.
Eine niedrige Grundlast simuliert demgegenüber das übliche Tagesgeschäft, bei dem immer mal wieder ein Request "aus der Reihe tanzt" und dem Server zusätzliche Arbeit verursacht. Die Benchmarks eignen sich aber auch dazu, die Änderungen im Leistungsverhalten spezifischer Services auf einem Server abzuklopfen, damit man schneller die optimale Einstellung findet.
Die fünf Weisen
Tabelle 1 gibt über die derzeit fünf Request-Mixturen Auskunft. Die Tests laufen nach der Installation der Testtools beziehungsweise der Scripts automatisch ab. Jeder Mix beruht auf unterschiedlichen Einzeltests, die zum Teil in mehreren unterschiedlichen Mix-Gruppen zum Einsatz kommen.
Der Einsatzbereich von Servern im Unternehmen überstreicht ein breites Spektrum. Neben den klassischen Einsatzgebieten wie File- und Printserver kommen, wie erwähnt, die Systeme üblicherweise als Intranet- oder Kommunikationsserver zum Einsatz. Neue Applikationen nutzen teilweise bereits zusätzliche Medien wie Audio- oder Video-Streamer. In die gleiche Kategorie fallen VoIP-Server (VoIP=Voice over IP).
Folgende typische Serverumgebungen haben wir identifiziert:
Workgroup-Server, Mail- und News-Server, Intranet-Server, Media-Server und "Classic" Server.
Java-Clients
Clientseitig wählten wir Java aus, weil sich diese Sprache aus mehreren Gründen gut für die Benchmarks eignet. Zum einen müssen die Clients natürlich die Netzwerkprotokolle "sprechen" können, die es zu überprüfen gilt. Hier haben die Java-Väter ihrem Sprößling genug Funktionen mitgegeben. Der fehlende direkte Zugang zu den untersten Netzwerkschichten stört nicht, da dieser Bereich von zusätzlichem Code auf dem Linux-Kontrollserver abgedeckt ist. Zudem könnte man unter Linux und, mit Einschränkungen, auch unter Windows, per "Java Native Interface" (JNI) auch den direkten Zugang zu einer Netzwerkkarte erhalten.
Der zweite ausschlaggebende Vorteil von Java liegt in der Einfachheit, mit der sich leichtgewichtige Prozesse (Threads) aufbauen lassen. Diese sind ideal dazu geeignet, gleich eine ganze Heerschar parallel "zuschlagender" simulierter Clients zu erzeugen. Damit hebelt man auch den prinzipiellen Nachteil aller Java-I/O-Operationen aus, die ausnahmslos blocken, wenn diese auf externe Daten warten müssen.
Dynamische Last durch Clients
Zudem nutzen die Benchmarks zum Teil auch die Thread-Gruppen, die insbesondere die Verwaltung der zusammenhängenden Threads stark vereinfacht. Hier holt Perl zur Zeit allerdings auf. Die aktuelle Version 5.005 unterstützt zwar bereits ein Thread-Modell, doch unterliegt die Implementation noch Veränderungen. Im übrigen kann Perl an dieser Stelle sogar leichte Vorteile verbuchen, weil eine Unmenge interessanter Bibliotheken für die Simulation von Netzwerk-Clients zur Verfügung steht.
Und natürlich empfiehlt es sich schließlich auch, eine trotz aller "Bemühungen" einzelner Hersteller universelle, zukunftsträchtige und plattformunabhängige Sprache im Vergleich zu Nischenlösungen zu wählen. Die Benchmarks benötigen über einen Linux-Rechner hinaus also lediglich eine beliebige Java-Plattform. Reicht die Performance eines Clientsimulators nicht aus, so lassen sich die simulierten Clients auch auf mehrere Systeme aufteilen und die Last damit erhöhen.
Grundlage der einzelnen Tests bilden die simulierten Clients, die jeweils einen Service-Request nach dem entsprechenden RFC beziehungsweise einem vernünftigen Subset davon erzeugen und die benötigte Antwortzeit beziehungsweise den Fehlerstatus aufzeichnen. Gleich mehrere dieser Clients arbeiten innerhalb einer Thread-Gruppe parallel, um mehrere Anwender zu simulieren. Da nicht jeder Anwender die gleiche Anforderung an den Server hat, kombinieren wir mehrere dieser Client-Thread-Gruppen mit unterschiedlichen Service-Requests zu einem Servicemix.
Testdaten
Bei allen Benchmarks wird der jeweils aktuelle Servicemix (beispielsweise: m POP3-User plus n NNTP-User zur gleichen Zeit) gleitend verändert und dabei die Systembelastung mit einem sich jeweils statistisch verändernden Zuwachs bis auf 100 Prozent geschraubt. Gerät der Server in seinen Grenzbereich, ist eine deutliche Verschlechterung der System-Performance festzustellen. Dies "merken" die Clients – an einer spürbar vergrößerten Latenzzeit oder an einer Zunahme der Fehlermeldungen. In der Praxis muß man versuchen, den Server immer unterhalb dieser Sättigungsgrenze zu "fahren".
Um vergleichbare Ergebnisse zu produzieren, erzeugen Perl-Scripts vor dem eigentlichen Start der Benchmarks eine Reihe unterschiedlicher Testdateien. Um Dateiservices wie NFS oder FTP überprüfen zu können, legt ein Script mehrere tausend Dateien unterschiedlicher Größe an; diese belegen insgesamt 4 GByte. Hierzu gehören einige Dateien mit einer Größe bis zu 15 MByte. Die Mehrzahl bilden jedoch Dateigrößen, die von 10 Byte über ein paar KByte bis zu einigen hundert KByte reichen.
Nach dem Anlegen aller Dateien löscht das Script zufällig ausgewählte Dateien, fügt neue hinzu, löscht wieder, um zum Schluß doch den kompletten Dateisatz auf der Festplatte anzubieten. Da der Dateigenerator hierbei die Dateigrößen wild durcheinander würfelt, bleibt kein Stein mehr auf dem anderen. Dieser Schritt simuliert den Serverbetrieb nach einer gewissen Laufzeit.
Alle Komplettdurchläufe zum Erzeugen der Dateien werden bereits per Perl-Modul "Benchmark" zeitlich mitgeschnitten, so daß man bereits erste Hinweise darauf bekommt, ob das Dateisystem anfällig für Fragmentierung ist oder intern genügend Optimierungen anbietet. Vor dem Lauf zur Dateigenerierung ändern wir keinerlei Parameter des Dateisystemes. Der kundige Sysadmin kann sicherlich etwa unter Unix durch eine gezielte Anpassung beispielsweise der Dateiblockgröße (oft ist ein Bereich von 512 Byte oder 2 KByte auf bis zu 64 KByte möglich) je nach spezifischer Anwendung die Performance des Dateisystems optimieren. Auch der Datei-Cache wird nicht angetastet.
Für den Web-Server werden ebenfalls gesonderte HTML-Dateien erzeugt. Die Dateigröße bewegt sich zwischen etwa 100 Byte und 15 KByte. Der Code enthält Referenzen auf externe Grafiken, deren Größe sich zwischen 150 Byte für normale Icons über 4 KByte für ein Firmenlogo bis hin zu 100 KByte für ausgewachsene Illustrationen bewegt. Links zu den Datei-Testdaten dienen später dazu, den FTP-Transfer über den Web-Server zu untersuchen.
Anhand einiger eingestreuter CGI-Scripts wird diese noch immer weidlich genutzte Schnittstelle näher untersucht. Zum gegenwärtigen Zeitpunkt ist noch nicht festgelegt, ob beziehungsweise wann auch ein Servlet-Test hinzukommen soll. Servlets sind potentiell die Nachfolgetechnologie zu CGI. Sie sind nicht herstellerabhängig wie etwa "Active Server Pages" (ASP) oder "Java Server Pages" (JSP), die als Performance-Killer schlechthin gelten. Während der Benchmark-Läufe kommen zu diesen Dateien noch die Daten hinzu, die beim Erzeugen der E-Mail und News für die beziehungsweise als Teil der entsprechenden Tests anfallen.
Fieberthermometer
Eine wichtige Kenngröße während des Benchmark-Ablaufs ist die aktuelle Serverlast. Wieder bietet sich der Vergleich zu einem Auto an, speziell mit dem Motor: Das Motormanagement muß sich mit einer Vielzahl unterschiedlicher Parameter auseinandersetzen, die zusammen den Betriebspunkt und damit die Leistung, aber auch die (Energie-)Effizienz bestimmen. Die dynamische Motorlast ergibt sich aus einzelnen Parametern wie Drehzahl und -moment, aber auch der Umgebungstemperatur. Auch ein Server hat unterschiedliche Betriebspunkte, die sich aus einer Kombination von Parametern wie
mittlere CPU-Last, Spitzenlast, freier Hauptspeicher, freier Cache-Speicher, Swap-Speicher, Pufferspeicher oder Netzauslastung
ergeben. Da die Benchmarks möglichst universell sein sollen, mußten wir bestimmte Kernparameter herausgreifen, die einfach festzustellen sein sollten. Hierbei sind zwei Parametergruppen zu unterscheiden. Vor Beginn der Benchmarks und jeweils zu Beginn einer neuen "Etappe" erzeugt ein Lastgenerator eine definierte Systemlast, die durch die mittlere Last gekennzeichnet ist.
Hierzu bekommt der Lastgenerator über das Netz die gewünschte Last mitgeteilt. In einer Steuerungsschleife, also ohne eine korrektiv wirkende Rückkopplung, nähert sich der Generator diesem Wert schrittweise an. Ist die Last erreicht, meldet dieser den erfolgreich ausgeführten Auftrag zurück; das Spiel kann beginnen. Die Last selbst ergibt sich in unserem Fall aus der Kombination aus einem rechenintensiven Prozeß, einem I/O-intensiven Task sowie einer speicherintensiven Aufgabe. Die Last ist also definiert aus
CPU-Zyklen, I/O-Zyklen (blocking) und Speicherbedarf.
Da sich der Lastmix variieren läßt, ist schnell festzustellen, ob es eine gute Idee wäre, die notwendige Datenbank tatsächlich auch noch auf dem gleichen System ablaufen zu lassen.
Um den aktuellen Lastfaktor zu erhalten, nutzen wir, wann immer möglich, Betriebsysstemkommandos wie uptime, ps oder top. Fehlt ein solches Tool (dies sollte bei einer Serversoftware allerdings niemals vorkommen), so muß eine entsprechende "Probe" programmiert und eingebunden werden. Als Schnittstelle zwischen Probe und dem Benchmark-Umfeld nutzen wir hierzu die Standard-I/O des Betriebssystemes. Ein Perl-Script holt sich hierzu den aktuellen Wert und bietet diesen als Server über einen definierten lokalen Port zum Abruf an.
Derzeit noch offen ist der Support von Netzwerk-Clustern und Multiprozessorsystemen. Im einfachsten Fall verteilt das Betriebssystem neue Prozesse auf die einzelnen Prozessoren oder Systeme. Diesen Fall decken die Benchmarks natürlich direkt ab. Schwieriger gestaltet sich das Unterfangen, sobald man selbst explizit allokieren muß. Leider ist ab diesem Punkt kein universelles Vorgehen möglich, so daß erst die Erfahrung zeigen muß, wie man am besten reagiert. Zur Messung der Leistungsgrenzen des Servers ist der Wert der mittleren Last ebenso wichtig. Übersteigt diese einen bestimmten Grenzwert, so gilt die maximale Servicelast als erreicht. Bei einem Multiprozessorsystem bildet die Probe einen Mittelwert. Liegt eine CPU außerhalb eines tolerierten Bereiches, so bestraft sich das System üblicherweise selbst, da oft unterschiedliche Prozesse aufeinander warten (blocking). In der Praxis muß man dann erforschen, wie die Last besser zu verteilen ist, und anschließend den Benchmark wiederholen.
Lokale Tests
Hinsichtlich der tatsächlichen Serverlast könnten weitere Werte wie der noch verfügbare physikalische Speicher, die Häufigkeit der Dateiauslagerungen et cetera (vmstat) und Wartezeiten bei geblockter I/O oder diverse Latenzzeiten sowie die konkrete CPU-Idle-, User- und Systemzeiten eine Rolle spielen. Auch der Prozentsatz der Timeouts bei den NFS-Transfers, die dann auftreten, wenn der Server, bedingt durch eine Überlastung, eine Anforderung nicht in der zur Verfügung stehenden Zeit erfüllen kann, ist von Interesse (nfsstat).
Die gateway-Benchmark-Suite untersucht den Probanden hauptsächlich über die Testclients, die über das Netzwerk eine Last erzeugen. Doch daneben sind auch einige Tests eingeplant, die lokal direkt auf dem Server ablaufen. Diese Tests lassen sich in die beiden folgenden Gruppen aufteilen:
Dateisystem-Benchmarks (Perl) sowie die System-Benchmarks (Perl, Java).
Die Dateisystem-Benchmarks nutzen auch die nach dem obigen Verfahren erzeugten Testdateien, die ja hauptsächlich für den Zugriff durch die Testclients zur Verfügung stehen. Darüber hinaus haben wir typische Datei-Benchmarks eingeplant, die direkt auf dem Server ablaufen und ebenfalls einen Einfluß auf das Testergebnis haben.
Die Rechenleistungs-Benchmarks nutzen das Perl-System sowie die Java-Umgebung auf dem Server, um die für typische Serverapplikationen verfügbare Rechenleistung einstufen zu können. Hierzu wählten wir folgende Standardpakete aus, die eine genau definierte Aufgabe auf dem Server zu bewältigen haben:
NFS-Server (Java), Crypt (Java, Perl), Bildverarbeitung (Perl) sowie ein Mathematikpaket (Perl).
Alle Tools zusammengenommen ergeben einen Einblick über die Systemleistung "über alles".
Natürlich muß an dieser Stelle der Einwand kommen, daß sich mit neuen Versionen von Perl (Perl 5.005 ist derzeit aktuell, eingesetzt wird oft aber Perl 5.004) oder Java auch die gemessene Performance linear verändern muß. Die Antwort ist ein unbekümmertes "ja". Wir lassen uns aus zwei Gründen auf dieses Abenteuer ein:
Zum einen ist es in Zukunft immer wichtiger zu wissen, wie Umgebungen wie Java oder Perl "performen". Wer heute einen Server kauft, wird mit hoher Wahrscheinlichkeit einige Aufgabenstellungen auf dem Server durch Java oder Scripting-Umgebungen wie Perl lösen wollen. Beide Umgebungen gehören zu den Brot-und-Butter-Problemlösern eines Sysadmin, aber auch eines Anwendungsprogrammierers.
Referenz läßt bitten
Der wichtigere Grund für unsere Gelassenheit liegt darin, daß wir alle Ergebnisse eines Probanden direkt mit dem bei einem Referenzserver ermittelten Werten vergleichen können. Ändert sich ein JDK, so lassen wir den Benchmark erneut auf die Referenzplattform "los". Danach gilt die aktualisierte Skala: Alle bisherigen Werte lassen sich durch den Korrekturfaktor skalieren. Auf diese Weise ist ein erneuter Vergleich möglich. Der Referenzserver verbleibt zu diesem Zweck in der Redaktion und steht damit für zukünftige Aufgaben zur Verfügung. Alle Probanden müssen sich an diesem Server messen.
In der nächsten Ausgabe stellen wir den Benchmark-Code näher vor und gehen auf erste Erfahrungen ein. (ch)