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 Network-TV-Shows Großbritanniens übertragen. Tatsächlich war diese Website die beliebteste Website für Channel 4 in Großbritannien, zum Teil, weil die Show es sich zur Aufgabe gemacht hat, die Leute auf die Website zu leiten und von ihr live auf Sendung zu berichten. Wir können den Traffic bezeugen, der entsteht, wenn ein beliebter TV-Arzt zur besten Sendezeit auf eine Webseite mit einer Galerie bestimmter Körperteile zeigt und vorschlägt, dass Sie vielleicht online gehen sollten, um sich zu vergleichen. Der Bandbreitengraph muss seine Skalenachse in einer Sekunde verkleinern. 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.

Deshalb integrieren wir bei Made Media Caching-Überlegungen in die Anwendungsarchitektur, anstatt das Caching erst 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 ist es, was wir mit zuerst cachen, dann Fragen stellen.

Pflichtlektüre

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