Kategorien
Caching: stale-if-error und stale-while-revalidate
Ihr wisst ja, dass ich mich gerade ein wenig mit Caching beschäftige. Vielleicht werde ich auch bald den besten Caching-Layer bauen, den es gibt. Vielleicht aber auch nicht. Wobei … falls er nicht perfekt wurde, sag ich einfach mein Arbeitgeber hat mir nicht erlaubt ihn zu veröffentlichen.
Irgendwann vor ein paar Jahren habe ich dieses Thema schon mal angeschnitten, aber das soll mich nicht hindern, heute noch mal etwas über zwei Cache-Verhalten zu erzählen. Das wird auch für den morgigen Artikel wichtig, da ich auf diese eingehen werde. Fangen wir also an.
- stale-if-error – Genau wie stale-while-revalidate ist dieses Vorgehen hauptsächlich im HTTP-Umfeld zuhause. HTTP-Accelerator wie Squid oder Varnish unterstützen diese Technik. Aber was macht sie? Ganz einfach. Gehen wir davon aus, dass auf dem Webserver ab und an mal ein Fehler passiert und eine 500er Seite ausliefert. Das kann gerne mal ganz spontan passieren, weil die Datenbank zum Beispiel kurz weg ist. In einem solchen Fall sagen wir dem Cache, dass er im Fehlerfall eine alte Webseite ausliefern darf, auch wenn diese nicht mehr gültig ist. Ist auf jeden Fall für den Nutzer angenehmer als eine „uups, da ist wohl ein Fehler passiert“-Seite.
- stale-while-revalidate – Der Name sagt schon das meiste. Aber erklären wir es trotzdem noch ein Mal. Nehmen wir an, die Webseite dauert ein wenig länger zum rendern. Vielleicht 10 Sekunden (ist alles schon vorgekommen). Dem User können wir solche Zeiten auf keinen Fall präsentieren. Was machen wir? Wir sagen dem Cache, dass er bitte so lange die alte Seite ausliefern soll, solange der Server die neue Seite noch berechnet. So bekommt der Nutzer nichts von der Geschwindigkeit mit, bekommt aber trotzdem zeitnahe die neusten Infos.
Diese beiden Verhalten richtig im HTTP-Cache eingesetzt bewirkt wohl eines der wichtigsten Performance-Boost, die man erreichen kann. Zumindest gefühlt.
Und das stale-while-revalidate hat noch einen anderen ganz ganz wichtigen aspekt und vorteil: wenn 10000 user deine homepage gleichzeitig aufrufen, so laesst der http-cache nur den ersten request durch zum php und von den restlichen bekommen die ersten die alte version und mit glueck einige schon die neu validierte. Cache-Stampedes sind php-seitig nicht trivial zu behandeln!
Ich weis ja, dass Squid sehr häufig dafür genutzt wird.
Ich bin aber trotzdem der Meinung, dass es „nur“ ein schlichter Proxy ist, den man dafür umbiegen kann, aber nicht sollte.
hi,
ich denke aber, man sollte stale-while-revalidate nur in Verbindung mit aJaX verwenden – natürlich sollte das Ganze im Hintergrund ablaufen, d.h. solange die Differenz zwischen den beiden Versionen nicht genau den gerade angezeigten Bereich (Scroll-Position) betrifft, sollte sich die Bilschirmanzeige nicht ändern. Das könnte man ca. so erreichen (nicht getestet – auf eigene Gefahr):
Position += ((Höhen der hinzugekommenen Elemente + jetztige Höhen der geänderten Elemente) – (Höhen der weggefallenen Elemente + ehemalige Höhen der geänderten Elemente))
Natürlich meine ich mit Höhen nur die Höhen von Elementen oberhalb der aktuellen Scroll-Position – die anderen betreffen uns nicht direkt und für die gerade angezeigten Elemente müssen wir uns sowieso etwas einfallen lassen. Der Anwender soll ja nicht glauben, das wäre ein Fehler, dass plötzlich während dem Lesen eines Absatzes dieser Absatz spurlos verschwindet. Auch bei Foren und Newsmeldungsseiten (die ja meistens nur 10 Einträge gleichzeitig anzeigen) sollte man aufpassen, dass nicht, wenn ein neuer Eintrag hinzukommt und ein Anwender genau den 10 Beitrag liest, genau dieser nunmehr 11. Beitrag kommentarlos auf die nächste Seite oder gar ins Archiv verschoben wird.
lg.