Websiteperformance und Effizienz

durch Helma und Cachingservlet

Große Ereignisse in der Vergangenheit haben uns deutlich gezeigt, wie wichtig es ist Systeme nicht nur „schnell genug“ für die derzeitige und noch zu erwartende Load zu planen, sondern sie dementsprechend für Peakloads zu rüsten, um auch für die heftigsten Anstürme gewappnet zu sein.

9/11 zwang uns Bilder in Schwarz-weiß auszuliefern, um Bandbreite zu sparen. Dieses traurige Ereignis ereilte uns ebenso unerwartet wie alle anderen Medien, die dann über längere Strecken nicht mehr – oder nur schwer – erreichbar waren.

Vor dem Neustart unserer wichtigsten Sites (news und sport) wurden diese als statische HTML-Seiten bereitgestellt. Dabei gab es keine Probleme bei der Auslieferung, das Verfahren funktioniert so stabil wie kaum ein anderes. Andere Teile des ORF.at-Networks wurden schon seit jeher dynamisch ausgeliefert.

Taxi Orange war damals ein erster wichtiger Benchmark für unsere Systeme. Aufbauend auf der Software, die wir bereits für die Futurezone entwickelt hatten, haben wir in den Frontend-Servern das Caching direkt in die Applikation eingebunden und Teile, oder sogar ganze Seiten im fertig gerenderten Zustand, zwischengespeichert, um diese direkt aus dem Memory auszuliefern. Das funktionierte ganz gut, war jedoch schwer auf andere Entwicklungen anzuwenden und musste von Generation zu Generation weiterentwickelt und adaptiert werden.

Später setzten wir Squid als Reverse-Proxy ein. Jedoch hat diese Methode ebenfalls Nachteile. Einer davon ist die zusätzliche Schicht an Hardware, die eingezogen wird und die potentiell ausfallen kann. Dazu kommt auch ein zusätzlicher Wartungsaufwand. Ein weiterer großer Nachteil ist die fehlende HTTP-Response-Compression.

Loadbalancer haben ähnliche Probleme, wie zum Beispiel zusätzliche Komponenten, die ausfallen können und gewartet werden müssen.

HTTP-Compression

HTTP-Copmpression ermöglicht eine deutlich bessere Performance bei der Auslieferung einer Seite durch den verringerten Bandbreitenbedarf.

Apache und die meisten anderen Webserver bieten von Haus aus Optionen, um dieses Feature zu verwenden, allen ist jedoch gemein, dass sie dies „on-demand“ erledigen. Das bedeutet, dass bei jedem einzelnen Zugriff die angeforderte Datei komprimiert wird, bevor sie an den Client ausgeliefert wird. Natürlich schlägt sich das auf die CPU nieder und verwandelt auch beim stärksten Server die CPU zum Flaschenhals. Erhöhte CPU-Auslastung führt in Folge zu erhöhtem Energiebedarf und steigender Abwärme, die wiederum mit höherem Energiebedarf abgeführt werden muss. Je beliebter ein Website wird, umso interessanter werden auch die Energiefaktoren.

Stabilität und Performance durch Helma und CachingServlet

Man möge vermuten, es gäbe nichts schnelleres als statische HTML-Seiten, aber dem ist nicht so. Mit Helma und dem bei ORF.at entwickelten CachingServlet haben wir Werkzeuge in der Hand, die Webseiten bei gleichbleibenden Hardwareanforderungen und Internetanbindungen um ein Vielfaches schneller ausliefern können, als es mit rein statischer Auslieferung alleine möglich wäre – und das dazu noch die Stabilität so weit wie möglich sicherstellt.

Das CachingServlet eliminiert die CPU als Flaschenhals bei der HTTP-Compression, indem es vollständige HTTP-Responses in ihrer unkomprimierten und komprimierten Version zwischenspeichert und die vom Client im Request angefragte Version einfach ausliefert. Gegenüber aktiviertem mod_gzip mit 75 bis 80 Prozent CPU-Last wirken die 0,5 bis 1,0 Prozent mit CachingServlet lächerlich. Der Großteil der Ressourcen kann somit auf wichtigere Aufgaben verwendet werden – wenn sie gebraucht werden.

Zur Stabilitätssicherung verhindert das CachingServlet, dass mehrfache parallele Aufrufe an die Helma-Applikation durchdringen können: Sollte es eine bereits eine gecachte, aber zeitlich abgelaufene Version geben, wird nur ein Request durchgelassen und alle Folgerequests mit der noch vorhandenen, aber eigentlich schon invalidierten Version beantwortet. Sollte es noch keine zwischengespeicherte Version geben, wird ebenfalls nur ein Request zur Applikation durchgelassen, alle anderen müssen in einer Warteschlange warten und bekommen dann die gleiche Antwort wie der erste Request.

Das sehr zufriedenstellende Ergebnis

Zur Veranschaulichung haben wir hier aus unserem Monitoring ein paar Graphen, an denen man gut die Auswirkungen unseres CachingServlets erkennen kann.

Grün werden hier die laufenden Threads für news.orf.at dargestellt, blau die für sport.orf.at. (Das „m“ steht übrigens für „millis“. D.h. 1000m = 1 Laufender Thread)

Dem gegenüber die Cache-Hit-Rate für news.orf.at, die in etwa bei 97% liegt. Somit werden 97% der Zugriffe ausgeliefert, ohne die dahinter laufende Middleware oder gar die Datenbank zu beschäftigen. Das führt zu einer durchschnittlichen CPU-Load am Server von ca. 0,4%.

Alles in allem haben wir mit unserem Setup nun genug Spielraum um gelassen in die Zukunft zu blicken. Vor einiger Zeit hatten wir gleich zwei Rekorde unsere Zugriffe/Second betreffend. Beide ausgelöst durch Sportevents:

• Super-G Damen am 08.02.2011 und
• Super-G Herren am 09.02.2011.

In Grün werden hier die Gesamtzugriffe auf alle Serverinstanzen angezeigt. Die vier Einzelserver werden durch die andersfarbigen Kurven dargestellt. In der Tagesansicht waren rund 4000 Zugriffe pro Sekunde gemittelt über 5 Minuten zu erkennen.

In dieser Kurve ist noch einer unserer Lasttests enthalten. Wir haben damals einen Server gequält (die türkise Spitze mitte Juli). Grün werden wiederum die Gesamtzugriffe auf alle Serverinstanzen dargestellt inklusive der letzten Zugriffsrekorde. Man sieht: da gibt es noch Spielraum.

Der einzig limitierende Faktor, der bei unserem Lasttest auftrat, war die Netzwerkanbindung. Über die physikalische Bandbreite kamen wir leider auch nicht mit dem CachingServlet hinaus ;)