IX. Cache First! (Fragen später stellen)

"Für mich sieht es gut aus. Haben Sie versucht, Ihren Cache zu leeren?" – Ihr Webdesigner, vor fünf Minuten.

Im Jahr 2009 wurde Made Media aufgrund eines vertraglichen Versehens die Verantwortung für das Hosting einer begleitenden Website für eine der beliebtesten Fernsehsendungen des britischen Senders übertragen. Tatsächlich war die besagte Website die beliebteste Website für Channel 4 im Vereinigten Königreich, was zum Teil daran lag, dass die Sendung die Besucher auf die Website verwies und live auf ihr Feedback gab. Wir können bezeugen, wie viel Verkehr erzeugt wird, wenn ein beliebter TV-Arzt zur besten Sendezeit auf eine Webseite mit einer Galerie bestimmter Körperteile verweist und vorschlägt, dass man online gehen sollte, um sich selbst zu vergleichen. Die Bandbreitenkurve muss innerhalb einer Sekunde ihre Skalenachse verzehnfachen. Das Rechenzentrum ruft Sie an, um herauszufinden, was los ist.

Es war ein knallharter Server. Es hatte wahrscheinlich fast so viel Rechenleistung wie Ihr heutiges Telefon.

Zu dieser Zeit waren wir gerade erst dabei, unsere Zehen in Amazon Web Services zu tauchen. Was wir jedoch hatten, war ein Rack mit Webservern in einem Rechenzentrum in Manchester. Einen davon könnten wir dieser Website widmen. Es war ein knallharter Server. Es hatte wahrscheinlich fast so viel Rechenleistung wie Ihr heutiges Telefon. Es gab keinen Belastungstest. Einen Backup-Plan gab es nicht.

Ich weiß nicht, was wir uns vorgestellt haben, vielleicht Wasser über den Server zu schütten, wenn er Feuer fängt.

Was wir taten, war, einige Artikel darüber zu lesen, wie man einem Denial-of-Service-Angriff standhält. Und Nummer eins auf der Liste war die Verwendung eines Reverse-Proxy-Caches. Die Open-Source-Version, die von allen empfohlen wurde, hieß Varnish. Wir haben es installiert, ein paar Optimierungen an der Webserver-Konfiguration vorgenommen und die Daumen gedrückt. Eigentlich fuhren wir zu zweit die M6 hinauf nach Manchester. Ich weiß nicht, was wir uns vorgestellt haben, vielleicht Wasser über den Server zu schütten, wenn er Feuer fängt.

Die Website funktionierte auf diesem einen Server aufgrund der Magie des Cachings gut. In der heutigen Zeit des Cloud Computing und der horizontalen Skalierung von Anwendungen kann Caching übersehen werden, aber es ist immer noch wichtig, um Websites betriebsbereit zu halten.

Die Wahrheit ist, dass sich die meisten Webseiten nicht allzu sehr ändern. Und wenn sie es tun, ändern sie sich oft innerhalb vorhersehbarer Zeiträume. Selbst wenn Sie nur in der Lage sind, die Informationen auf einer Seite für eine Sekunde zwischenzuspeichern, ist das immer noch enorm, wenn Sie mehr als 2.000 Anfragen pro Sekunde stellen, wie z. B. mitten in einem Ed Sheeran-Verkaufsangebot.

Die meisten Web-Assets sind tatsächlich zwischenspeicherbar, egal ob es sich um eine Startseite, eine Schaltfläche zum Angebot, einen Feed zur Verfügbarkeit von Arbeitsplätzen, ein Stück Javascript oder einen Leistungskalender handelt. Und Sie können ziemlich genau steuern, wann ein Cache abläuft, sei es durch die Angabe von "Dieser Inhalt ist 60 Sekunden lang gültig" oder "Dieser Status läuft genau um 10:00 Uhr ab, wenn dieses Ereignis in den Verkauf geht". Tatsächlich ist HTTP-Caching der Kern der Infrastruktur des Internets. Die viel gepriesenen Content Delivery Networks sind eigentlich nur ein Netzwerk von Reverse-Proxy-Caching-Servern wie Varnish. Die Sache ist die, dass die meisten Webentwickler zwar ein vernünftiges Verständnis von HTTP-Caching haben, aber sie investieren nicht oft die Arbeit, um sicherzustellen, dass es wirklich wie beabsichtigt funktioniert, weil es eine Art Bremse ist.

Wir entwerfen Caching-Überlegungen in die Anwendungsarchitektur, anstatt sie am Ende anzuhängen.

Das Schlimmste, was Sie tun können, wenn Sie für eine Anwendung mit hoher Nachfrage verantwortlich sind, ist, Ihre hochgradig zwischenspeicherbaren Inhalte (z. B. Leistungsverfügbarkeit) mit Ihren schwer zwischenzuspeichernden Inhalten (z. B. die persönlichen Daten eines Benutzers) zu verschmelzen. Das Zusammenführen dieser geschäftlichen Belange hat den Nebeneffekt, dass Ihre gesamte Anwendung weitgehend nicht zwischengespeichert werden kann. Es spielt keine Rolle, wie ausgefallen Ihre horizontal skalierende Architektur unter diesen Umständen ist, denn wir haben bereits gezeigt, dass Caching Leistungsvorteile von mindestens einem Faktor von 2000 erzielen kann. Selbst wenn Ihre Cloud in einer Sekunde so schnell skalieren kann (Spoiler - das kann sie nicht), zahlen Sie dafür durch die Nase.

Bei Made Media planen wir daher Caching-Überlegungen in die Anwendungsarchitektur ein, anstatt das Caching am Ende anzuhängen. Das macht die Entwicklung schwieriger, aber wenn der Cache den Code kaputt macht, bedeutet das, dass er überdacht werden muss. Das verstehen wir unter "erst cachen, dann Fragen stellen".

Pflichtlektüre

• Lack einen zwischenspeichernden HTTP-Reverse-Proxy.
• Schnell ein Content Delivery Network (CDN).