Menü

Sandstorm: Webserver-Prototyp schlägt etablierte Konkurrenz um Längen

Lesezeit: 3 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 144 Beiträge
Von

Ilias Marinos, Robert Watson und Mark Nandley haben einen neuen Ansatz für Netzwerk-IP-Stacks und Webserver vorgelegt, der gegenüber herkömmlichen Stacks die CPU geringer belastet – und dabei einen deutlich höheren Durchsatz liefert. Dafür haben sie eine erste Prototyp-Anwendung namens Sandstorm eng mit einem spezialisierten Netzwerk-Stack gekoppelt.

Den Ausgangspunkt für die Entwicklung sehen die Autoren darin, dass heutige Server und Betriebssysteme Generalisten sind, also prinzipiell sehr vielfältige Aufgaben erledigen können. Im Gegensatz dazu stehen jedoch die Anwendungsszenarien: Beispielsweise setzen Service-Anbieter für jeden ihrer diversen Dienste einzelne Server ein. Und bei großen Web-Service-Anbietern kommt es vor, dass tausende von Maschinen eine einzige Aufgabe erledigen. Unterm Strich bremsen aktuelle APIs, Speichermodelle und Implementierungen die inzwischen oft sehr leistungsfähige Hardware. Von daher, so die Autoren, gäbe es Potenzial für Spezialisierungen. Marinos, Watson und Nandley haben sich das Szenario herausgepickt, bei dem ein Webserver immer wieder dieselben statischen Inhalte ausliefert; viele aktuelle Webseiten sind so gestrickt.

Demgegenüber fällt auf, dass aktuelle Netzwerk-Stacks für hohen Durchsatz bei langen Transfers ausgelegt sind, also ihre Stärken bei großen Downloads haben. Für Webseiten mit vielen kleinen Dateien sind sie hingegen nicht optimiert. In Experimenten fanden die Autoren hohe CPU-Lasten bei nur geringen Auslastungen der Internet-Leitungen. In einem konkreten Fall sollte ein herkömmlicher Webserver 8 KByte große Dateien ausliefern. Die CPU-Last betrug dabei zwar 85 Prozent, doch die Auslastung der 10-Gigabit/s-Leitung nur rund 50 Prozent. In ihrer Publikation führen die Autoren diverse andere Messreihen auf. Dem Sandstorm-Prototypen stellen sie dabei FreeBSD- und Linux-Systeme mit dem Webserver nginx gegenüber.

An diesen Messergebnissen wird der konzeptionelle Nachteil aktueller Anwendungen, Netzwerk-Stacks und zugehöriger Speichermodelle sichtbar: Vereinfacht kann man sagen, dass sie jedes einzelne Byte mehrfach im Speicher umherschieben, bevor es letztlich auf die Leitung kommt. Konventionelle Server wie nginx nutzen dafür den Systemcall sendfile(), um statische Inhalte an das OS weiterzugeben, wo sie über mehrere Schritte zur Netzwerkkarte gereicht werden. Das kostet Zeit und Ressourcen. Und je höher die Anzahl der gleichzeitig versorgten Clients, desto ungünstiger wirkt sich das Konzept aus. So kommt es, dass ältere Systeme schon mit einer 10-GBit/s-Leitung überfordert sind. Als typisches Alt-System verwenden sie einen Dual-Socket-Server aus dem Jahr 2006 mit 8 GByte RAM und zwei Xeon X5355 (2,66 GHz).

Der Teig wird lang und länger, das Brot nicht fertig: Herkömmliche Netzwerk-Stacks und Webserver wie im Beispiel FreeBSD und nginx schieben die Daten im Speicher mehrfach umher, bevor sie sie schleßlich an die Netzwerkkarte geben. So tragen sie zur Latenz einer Übertragungsstrecke bei und schaffen es nicht, eine 10-GBit/s-Leitung auszulasten. Zusätzlich führt dieses Konzept dazu, dass die CPU stark ausgelastet wird, ohne effektive Arbeit zu erledigen (rechts).

Selbst moderne Server haben mit dem generalistischen Ansatz laut den Autoren Mühe, mehrere 10-GBit/s-Karten auszulasten. Dabei setzen sie durchaus schon einige Optimierungstechniken ein, etwa TCP Segmentation Offload und Large Receive Offload, um die CPU zu entlasten. Und umgekehrt fällt auf, wie sehr sich eine aufs Wesentliche reduzierte Speicher-Strategie auf aktueller Hardware rentiert. Die Autoren nennen ihren Ansatz Zerocopy: Der Sandstorm-Prototyp mit Zerocopy-Technik lastet eine 10-GBit/s-Leitung mit nur 13 Prozent CPU-Last aus. Und bei sechs Netzwerkkarten befördert Sandstorm 55 GBit/s bei 73 Prozent CPU-Last. So sei der Webserver-Prototyp rund 3,5 mal schneller als FreeBSD mit nginx, schreiben die Autoren. Unter moderner Hardware verstehen sie Systeme mit Data Direct I/O, also der DMA-Technik, mittels der Netzwerkkarten über den PCIe-Bus direkt auf den Last-Level-Cache des Prozessors zugreifen. Im Test haben sie einen Intel-Server mit 128 GByte RAM mit der Quad-Core-CPU Xeon E5-2643 eingesetzt.

Dieses Zusammenspiel perfektioniert Sandstorm, indem es für die auszuliefernden Daten der Applikationen die kürzestmögliche Brücke vom Systemspeicher zur Netzwerkkarte schlägt. Dafür setzt Sandstorm auf das Netmap-Framework, das den Puffer der Netzwerkkarte im Userspace abbildet. So kombiniert Sandstorm Anwendungs- und Netzwerk-Stack-Speicher-Modelle (die Autoren nennen das Cross-Layer-Optimization). Unterm Strich sinken die Anforderungen an TCP-Ressourcen und die Zugriffe werden schneller. Dabei setzt die Software auf konventionellen Betriebssystemen und Frameworks auf. Weitere Schlüsselelemente sind pufferlose Abläufe und der Ansatz, Anwendungen und Netzwerk-Stack in den selben Adressraum zu stecken. Im speziellen Fall der statischen Inhalte ließ sich die Auslieferung zusätzlich beschleunigen, wenn die Daten zu fertigen Paketen vorsegmentiert bereitgehalten werden.

Marinos und seine Kollegen haben Sandstorm jedoch nur als eine Beispielanwendung für ihr neues Implementierungsmodell entwickelt. "Wir haben unter Wiederverwertung einiger Netzwerk-Stack-Komponenten noch weitere Anwendungen entwickelt", erklärte Marinos auf Nachfrage von heise netze. "Mit dem neuen Ansatz wollen wir für ein neues Programmiermodell werben, bei dem der Netzwerkstack eng mit der Applikation gekoppelt ist, um so diverse Arten von Cross-Layer-Optimierungen zu ermöglichen".

Der Sandstorm-Quellcode soll in zwei bis drei Monaten als OpenSource veröffentlicht werden. Zuvor, so Marinos, seien noch kleine Aufräumarbeiten und Verbesserungen erforderlich. Marinos sieht auch im Zusammenspiel mit dem für Ende 2014 angekündigten HTTP 2.0 und SPDY Potenzial für Optimierungen. "Das sind spannende Arbeiten, die die aktuellen Probleme bei konventionellen Netzwerk-Stacks angehen, die sich mit kurzlebigen, Nachrichten-orientierten TCP-flows schwer tun. Wir glauben, dass unser Ansatz orthogonal zu HTTP 2.0 steht, hauptsächlich, weil wir fundamentale Probleme lösen wollen. Das vorausgesetzt, glaube ich, dass SPDY, HTTP 2.0 und auch andere Optimierungstechniken von unserem Ansatz profitieren können". (dz)