Dev-Blog

Entwicklungsblog von ZEIT ONLINE

Glänzend und schnell: Webseiten mit Varnish

Von 19. Februar 2015 um 19:22 Uhr

Wer das heutige Netz kennt, weiß, dass sich die Aufmerksamkeit dank Social Media in Sekundenbruchteilen auf einen Punkt konzentrieren kann. Für diese Konzentration braucht es nicht mal einen Shitstorm. Ereignisse wie das Bekenntnis des ehemaligen Bundesligaprofis Thomas Hitzelsberger zu seiner Homosexualität oder das tragische Attentat auf das Satiremagazin Charlie Hebdo vor einigen Wochen führten spontan zu weit mehr als doppelt so vielen Anfragen als üblich. Eine Situation, in der das gängige Konzept der horizontalen und vertikalen Skalierung - also bessere und mehr Rechner - nicht mehr funktioniert.

Ein solches System funktioniert gut, solange dessen Lastanforderung linear wächst. Man plant es so, dass es zunächst das Doppelte der Normallast aushält. Wenn sich die Lastanforderungen erhöhen, stellt man nach und nach neue Rechner dazu oder baut ältere Maschinen aus, um sie zu ersetzen.

Die Benutzer von ZEIT ONLINE erwarten, dass die Seite gerade bei ungewöhnlichen Nachrichtenlagen verfügbar ist. Dieses Ziel erreichen wir heute nur, weil wir Varnish einsetzen. Varnish ist ein HTTP-Accelerator, der Anfragen via HTTP durch eine in der IT sehr gängige Technik beschleunigt: Caching.

Seit der Version 2.0 ist Varnish bei ZEIT ONLINE im Einsatz. Derzeit ist Version 3 im Betrieb. Im letzten Jahr erschien Version 4. Als ZEIT ONLINE begann, Varnish einzusetzen, war es ein recht junges Projekt von FreeBSD Comitter Poul-Henning Kamp. Entwickelt für die norwegische Zeitung Verdens Gang, um die Auslieferungsgeschwindigkeit des Online-Angebots zu verbessern. Das ist der zweite große Vorteil von Varnish: Das System hält nicht nur mehr Last aus, sondern wird auch schneller.

Das Projekt selbst steht unter der BSD-Lizenz. Es handelt sich also um freie Software. Alle gängigen Linuxdistributionen bieten mittlerweile eine leicht installierbare Version von Varnish über ihre Paketserver.

Varnish ist von außen betrachtet zunächst einmal ein reverse proxy. Das bedeutet, dass er HTTP-Requests entgegennimmt und weiterverteilt. Eine Fähigkeit, die sich Varnish mit etlichen anderen HTTP-Servern teilt, wie zum Beispiel dem weitläufig bekannten Apache.

Genutzt werden reverse proxys gern, um verschiedene Dienste unter einer Domain zu subsummieren. Bei ZEIT ONLINE wird diese Fähigkeit unter anderem für das Freitextblog genutzt. Mit ein bisschen Konfiguration können wir das Blog unter www.zeit.de/freitext verfügbar machen, obwohl es eigentlich auf einem ganz anderen Server mit der Domain blog.zeit.de gehostet wird. Solche Konfigurationen sind Alltag für Systemadministratoren. Sie beschleunigen jedoch nichts.

Screenshot 2015-02-11 21.26.34

Codebeispiel aus der Konfiguration von ZEIT ONLINE. Das Freitext-Blog unter der URL www.zeit.de/freitext.

Genau an diesem Punkt wendet Varnish jedoch einen einfachen Trick an: Es merkt sich für jeden HTTP-Request die Antwort des Backends, also die Antwort des Servers, an den es den Request schickte, und speichert diese mit einem eindeutigen Schlüssel (genannt hash key) in einer Datenstruktur im Hauptspeicher (RAM). Bei einem weiteren Request auf eine so gespeicherte URL wird dann erneut der gleiche Schlüssel erzeugt, aus der Datenstruktur aufgerufen und direkt beantwortet. Die Anfrage wird also nicht mehr an ein Backend weitergeleitet, sondern direkt aus dem RAM bedient. Dies ist ein bemerkenswerter Performancegewinn, da wir davon ausgehen können, dass normalerweise für jeden Request erst eine Antwort berechnet werden muss. Bei ZEIT ONLINE macht dies zwar ein vom eigentlichen CMS getrennter Anwendungsserver, was schnell einige hundert Millisekunden beansprucht. Varnish schafft es in einem Bruchteil der Zeit.

Da im Netz nichts für die Ewigkeit ist, kann die Geschichte hier nicht enden. Sekündlich werden Inhalte erneuert oder veröffentlicht, eine gecachte URL muss also aktualisiert werden können. Hier macht sich Varnish das HTTP-Protokoll zunutze, welches vorsieht, dass eine Response (also das Gegenstück zu einem Request) beispielsweise mit einem Expires-Header angibt, wie lange sie gültig ist. Erlischt diese Gültigkeit, wird sie von Varnish als invalid markiert. Man spricht von einer Invalidierung. Kommt nun ein neuer Request, wird Varnish diesen nicht mehr aus dem Hauptspeicher bedienen, sondern genau das Backend fragen, von dem ursprünglich die passende Response kam. Anschließend wird der Hauptspeicher mit der neuen Response aktualisiert.

Neben der zeitgesteuerten Variante ist es außerdem möglich eine Resource (also zum Beispiel einen Artikel) direkt aus dem Cache zu entfernen. Hier hat sich der Terminus PURGE-Request etabliert, obwohl der HTTP-Standard diese Methode eigentlich nicht vorsieht. Ein PURGE-Request ist ein normaler GET Request mit einem Pragma: no-cache und einem Cache-Control: no-cache Header. Also das, was ein Browser sendet, wenn man einen Shift-Reload macht. Will man nicht, dass jeder Benutzer so den Cache invalidieren kann - da dies schnell die Perfomance des Servers beeinträchtigen könnte - schränkt man diese Requests mit einer IP-Range ein und steuert diese Requests dann zum Beispiel über das CMS.

vcl

Der Varnish Request Flow zeigt die einzelnen Phasen von Request bis Response. Mit der VCL kann man in jede Phase eingreifen.

Für solche Konfigurationen hat Varnish eine eigene Domain Specific Language (DSL), genannt Varnish Configuration Language (VCL). Hier handelt es sich um eine dem C-Dialekt nahe Sprache, die daher für alle, die imperative Programmierung gewohnt sind, leicht lesbar ist. Gegenüber tabellarischen oder XML basierten Konfigurationskonstrukten ist dieser Ansatz auch deutlich intuitiver.

Die VCL bietet zunächst die Möglichkeit, Backends zu definieren. Gibt es für einen Zweck mehrere Backends, zum Beispiel solche, die Bilder ausliefern, können diese mit einem Director in einen Lastverbund genommen werden. Für oben erwähnte IP-Range gibt es die acl Direktive, die access control list.

Die Stärke der VCL liegt jedoch darin, dass man mit ihr innerhalb des oben abgebildeten Zyklus in jede einzelne Phase eingreifen kann, um ein spezielles Backend auszuwählen oder Request und Response zu manipulieren.

Screenshot 2015-02-11 21.38.19

Für das mobile Backend muss ein separater Hash erzeugt werden, damit für Nutzer der Mobilseite und der Desktopseite jeweils unterschiedliche Varianten eines Artikels ausgeliefert werden.

In der Phase vcl_recv steht der reine Request zur Verfügung. Die mobile Weiche von ZEIT ONLINE wird beispielsweise größtenteils in dieser Phase realisiert. Anhand des User-Agent-Header wird ausgewertet, ob der Benutzer die klassische Desktopseite oder eine Mobilansicht bekommt. Natürlich muss für beide Ansichten hier jeweils ein Objekt im Cache existieren und daher benötigen beide Seiten einen eigenen Hash, obwohl sie sich die gleiche URL teilen. Per default erstellt Varnish einen Hash aus URL und Host-Header. In der Phase vcl_hash können wir die Erzeugung dieses Werts manipulieren. In vcl_fetch sind bereits die Antwortheader des Backends da. Hier könnte man nun noch eingreifen und zum Beispiel eine Ablage im Cache (vcl_hit) verhindern - oder einen sogenannten Restart des Requests auslösen, falls die Antwort des Backends nicht die erwartete ist.

flussdiagramm_varnish

Bei ZEIT ONLINE kann das Backend den Request an ein anderes Backend delegieren. Möglich wird dies durch die Restart Anweisung in Varnish.

Die VCL ist ein Schlüsselfeature, da Varnish mit ihrer Hilfe bedienbar wird. In der ZEIT-ONLINE-Technik hat ein Großteil der Entwickler in Backend und Frontend bereits die zentrale VCL unserer Auslieferungsserver bearbeitet und weiterentwickelt. Varnish selbst läuft so zuverlässig und Ressourcen sparend, dass sich die Software mittlerweile zu einem Eckpfeiler in der RESTful basierten Architektur von ZEIT ONLINE entwickelt hat. Eine Bedeutung, die mit dem bevorstehenden Update auf Version 4 sicher weiter ausgebaut wird.

Dies war der erste Teil einer kleinen Serie, in der wir darstellen, warum wir Varnish einsetzen und schätzen. Im nächsten Teil werden wir auf Hilfsprogramme eingehen, die mit Varnish ausgeliefert werden - allen voran das Programm Varnishtest. Ron Drongowski ist Teamleiter Backend bei ZEIT ONLINE.

Kategorien: Entwicklung

Block, Element, Modifier

Von 20. Januar 2015 um 10:26 Uhr

Das Schwierige an CSS ist, dass es so einfach ist. Obschon leicht erlernt, ist es jedoch schwer zu strukturieren und wirkt oft undurchschaubar. Findet man keinen sauberen Weg, seinen Code zu organisieren, wächst die Codemenge oft exponentiell zur Projektlänge an.

In Just Try and Do a Good Job schreibt Chris Coyier, dass er weder Namenskonventionen noch andere spezielle Methodiken nutzt, um sein CSS zu schreiben. Vielmehr versucht er mithilfe seiner Erfahrung und weniger Richtlinien, immer gute Arbeit (a good job) zu machen. Er schränkt dabei ein, dass er hauptsächlich alleine arbeitet und so seinen Stil leicht einhalten kann. Für Teams reicht die Arbeitsanweisung »Do a good job« selten aus. Zumal oft unterschiedliche Vorstellungen davon herrschen, was genau das denn bedeutet, trotz Coding Richtlinien.

Das Entwicklungsteam von ZEIT ONLINE hat hier viele, oft schmerzliche Erfahrungen gesammelt. Zu Zeiten des Relaunch 2009 hatten wir für uns einen CSS-Schreibstil entwickelt, der unseren damaligen Arbeitsumständen sehr entgegen kam und am damaligen state of the art orientiert war. Leider wissen wir heute, dass wir damit CSS gebaut haben, das zwar gut funktioniert, aber sehr schwierig zu warten ist. Die Weiterentwicklung der Seite führt zu immer mehr Code. Da nie ganz klar ist, welcher Code wo noch in Gebrauch ist, ist es gefährlich, eigentlich überflüssigen Code zu entfernen. Der sogenannte code bloat kann die Website-Performance aber schnell verschlechtern. Wir haben natürlich immer wieder an dem Problem gearbeitet, aber die gewünschten Performance-Werte letztlich nie erreichen können – oder auch nur unsere Entwickler besonders entlasten.

Aus diesem Grund haben wir uns für die Einführung der sehr rigiden Namenskonvention BEM entschieden. BEM steht für Block, Element, Modifier, was schon die drei Entitäten beschreibt, in die wir unseren CSS-Code in Zukunft unterteilen. Blöcke sind unabhängige Einheiten in einer Website, die für sich allein stehen können und einen Teil der Nutzeroberfläche repräsentieren. Dies kann beispielsweise ein Logo, ein Suchformular oder ein Menü sein. Blöcke können weitere Blöcke enthalten, was sie von den Elementen unterscheidet. Diese sind für sich allein gestellt nutzlos, funktionieren nur in ihrem Block. Zu guter Letzt gibt es noch Modifikatoren. Das sind zusätzliche Klassen, die an Blöcke oder Elemente geschrieben werden, um unterschiedliche Status abzubilden. Alle Blöcke, Elemente und die Modifikatoren werden durch Klassen repräsentiert, die per Benennung grob ihre Aufgabe und genau ihre Beziehung zueinander ausdrücken. Im Stylesheet wird ausschließlich mit diesen Klassen gearbeitet, alle anderen Selektoren sind quasi verboten.

The one "rule"ish thing I really believe in: keep your selector specificities fairly low and flat across your whole project. — Chris Coyier

Die Namenskonvention mit den doppelten Unterstrichen oder Minuszeichen – die man durchaus nach seinen Vorstellungen ändern kann – und das zweifelsohne hohe Aufkommen an Klassen-Attributen im HTML wirken zunächst etwas ungewöhnlich. Die einzelnen Blöcke werden dadurch voneinander völlig unabhängig. Sie können leicht und sicher editiert werden. Die Spezifität aller Elemente ist auf zwei Stufen festgezurrt, die Kaskade damit außer Kraft gesetzt. Aber gerade das hilft; vor allem in den ganz großen Projekten, in denen nicht mehr jeder jeden Codeblock kennt. Was also zunächst nach zusätzlicher Arbeit aussieht, kommt der Realität der Entwicklung und vor allem der Weiterentwicklung einer Nachrichtenseite sehr entgegen. Ziel ist es letztendlich, Code zu schreiben, der gut und sicher zu modifizieren ist. Diese Anforderung ist durch die vollständige Modularisierung und die flache Hierarchie der Klassen in BEM erfüllt.

Den Aufwand, den der Einsatz einer solchen Namenskonvention mit sich bringt, fangen wir durch Tools wie Sass (siehe auch BEM-Notation) oder grunt zumindest zum Teil wieder ab. In der Automatisierung liegt dann auch die Möglichkeit, den Code laufend zu prüfen und zu messen. Und nur wer misst, kann seine Performance erhöhen.

Nico Brünjes ist Teamleiter Frontend bei ZEIT ONLINE.

Kategorien: Entwicklung

Lieber authentisch als perfekt

Von 20. November 2014 um 11:04 Uhr

Das Licht ist gedämpft, ein DJ spielt Lounge-Musik. Menschen, vorwiegend Männer in Hipsterkluft, stehen murmelnd in Gruppen beisammen und halten sich an ihren Getränken fest. Eine aufsteigende Tribüne nimmt den großen Saal im Berliner Admiralspalast fast komplett ein, vorne auf der Leinwand grüßt ein Abbild des Organisators als Comicfigur. Alles erinnert ein wenig an Kino.
Doch die Getränke sind nicht alkohol- sondern koffeinhaltig, es ist 10 Uhr morgens und die Besucher sind nicht nur zum Vergnügen da. Es geht um die Optimierung von Code. Es ist der erste Tag der Beyond Tellerrand, einer Konferenz für Webdesigner und -entwickler.

btfconf-ct

Infostand der c't auf der Beyond Tellerrand

Allerdings ist der erste Vortrag des Tages doch vergnüglich. Alles was man braucht, um die Sache spannend zu machen, sind einige Laser, beziehungsweise einige Laser mehr. Mit diesen realisiert der Brite Seb Lee-Delisle eindrucksvolle Spiel- und Klangexperimente. Das genügt vollkommen, um das Publikum nicht direkt nach dem Kaffee zur Club Mate greifen zu lassen.

Das, was Lee-Delisle vorstellt, ist bunt, schrill und sehr unterhaltsam, um so erstaunlicher das Ende des Vortrages. Dort fallen plötzlich Sätze wie "There is no such thing as natural talent" und "there is always someone better than you". Zum Rest des Vortrags, der unerschöpfliche Kreativität wie die einfachste Sache der Welt wirken ließ, passt das nur bedingt. Es macht nachdenklich, dass jemand, der Kunstprojekte programmiert und sich jenseits der ausgetretenen Programmierpfade bewegt, den Druck der Branche dennoch zu empfinden scheint.

Die Webbranche, in der Lee-Delisle und höchstwahrscheinlich die Mehrzahl der anwesenden Besucher agiert, ist anspruchsvoll. Oft sind Dinge, die man neu dazugelernt hat, zu dem Zeitpunkt, an dem man sie richtig versteht, schon wieder veraltet. So veraltet, dass man sich fast nicht einmal mehr zuzugeben traut, sie je gelernt zu haben. Solche einst gehypten und nun totgesagten Technologien gibt es viele. Ein Beispiel dafür ist Flash, eine Technik, die Webseiten einst im großen Stil zum Blinken und Klingen und damit das Multimediaerlebnis ins vorher überwiegend dröge Internet gebracht hat. Mittlerweile hat es etwas Anrüchiges, Flash als ernsthafte Option für eine Webseite auch nur in Erwägung zu ziehen. Inzwischen gibt es weit bessere und einfachere Möglichkeiten für beeindruckende Webeffekte, ob sie nun notwendig sind oder nicht.

Etwas verschämt gibt es auch in einem Vortrag auf der Beyond Tellerrand Anspielungen auf diese ehemaligen Flash-Entwickler, von denen einige unter den Zuschauern sein dürften. Der Rest hat das Glück gehabt, einmal etwas mit gutem Gewissen ausgesessen zu haben.

Zu entscheiden, wann man sich den Luxus des Aussitzens gönnen kann, ist allerdings nicht leicht. Dies wird in der Konferenzpause deutlich, in der im Vorraum die Getränkebecher aufgefüllt werden können.  Nur wenig offen zur Schau gestelltes Unwissen ist zu hören. Die Frage: "Wie, das kennst du etwa nicht?" scheint hier so gefürchtet zu sein wie Alkoholknappheit auf der Firmenweihnachtsfeier. Zu Recht, denn man will einem Gegenüber, der eine solche Frage genüsslich stellt, keine Genugtuung gönnen.

Zum Glück folgt der nächste Vortrag, gehalten von der US-amerikanischen Webdesignerin Zoe Mickley Gillenwaters. Er trägt den Titel CSS lessons learned the hard way in dem sie ausführlich über Fehler bei ihrer Arbeit mit der Stylingsprache CSS berichtet. Gillenwaters weist darauf hin, wie wichtig diese Fehler für ihr Fortkommen waren, und macht deutlich, wie wichtig es sein kann, Fragen zu stellen. Auch dann, wenn damit vielleicht Wissenslücken eingestanden werden.

Auch Art Director und Grafikdesigner Andrew Clarke versucht, dem Publikum mehr Selbstvertrauen zu raten. Clarke liegt etwas über dem Altersdurchschnitt der Twenty bis Thirtysomethings und zitiert auf seinen Folien George Orwell, aber auch sich selbst. Was beim Hörer hängenbleibt, ist sein Appell, weniger in Trends und Schablonen zu denken - mehr Authentizität statt mehr Perfektionismus. Clarke ist einer der Initiatoren der Geek Mental Help Week, einer durch Beiträge verschiedener Autoren gestützten Webaktion, die sich kürzlich mit psychischen Problemen von Entwicklern und Designern auseinandersetzte.

Es ist ein Bewusstsein für den Leistungsdruck in der Webbranche entstanden - dieser Eindruck entsteht bei der Konferenz. Entwickler und Designer sind des "schneller, höher, weiter" der digitalen Revolution müde geworden.
Den letzten Vortrag mit dem  schlichten Titel Design and Happiness hält Stefan Sagemeister. Am Ende singt der gesamte Saal die Ode an die Freude.

Anika Szuppa ist Frontendentwicklerin bei ZEIT ONLINE.

Kategorien: Entwicklung