nicht angemeldet
Moin!
Abend,
nochmal vielen Dank fuer die ausfuehrliche Erklaerung! Aber so genau wollte ich es auch nicht wissen (bezogen auf den rechnerischen Teil) ;)
Beim Caching ist folgendes Muster typisch:
Der tatsächliche Aufruf ruft nicht mehr stur direkt die aufwendige Berechnungsaktion auf, sondern prüft zunächst mal, ob dafür überhaupt ein Anlass besteht. Dazu muss in irgendeiner Weise der Zustand "Cache ist veraltet, muss neu" ermittelt werden.
Da happerts schon mit meinem Verstaendnis :D
Der Cache ist ja Client-abhaengig, oder? (Wenn das falsch ist, sagen!)
Dass heisst, der Pruefungs-Teil muss pruefen, ob die Datenbank seit dem letzten Caching veraendert wurde. Wie prueft man sowas?
Wenn der Cacheeintrag Datum und Uhrzeit der letzten Änderung enthält, kann man in der Datenbank nachfragen, was dort das aktuellste Datum ist. Wenn das identisch mit dem Cache ist, hat sich nichts geändert.
Aber du erkennst das Problem: Caching geht nicht ohne das Originalsystem. Deshalb kann das Ermitteln der Aktualität des Caches fast genauso aufwendig sein, wie die Originalanfrage. Es hängt entschieden davon ab, um welche Art von Anfragen es geht.
Es gibt natürlich eine Alternative: Der Cache kann sich auf einfach eine Zeit lang pauschal als aktuell erklären, und nach Ablauf einer gewissen Zeit wird er mit frischen Daten befüllt.
Andererseits eröffnen sich auch komplett neue Fehlermöglichkeiten: Wenn eine Website mit einem Cache performanter wird und alles prima läuft, kommt es dennoch irgendwann einmal zu der Situation, dass der Cache aktualisiert werden muss. Wenn das zu einem Zeitpunkt mit hoher Last passiert, stellen viele gleichzeitige Requests fest, dass der Cache nicht mehr aktuell ist. Wenn das Caching ungünstig programmiert ist, werden alle diese parallelen Requests jetzt die aufwendige Originaloperation, z.B. den DB-Query ausführen wollen - und die Datenbank bricht spontan unter dieser Last zusammen.
Ebenfalls problematisch ist, wenn der Cache-Eintrag parallel von mehreren Requests aus aktualisiert werden soll, die DB also den Ansturm bewältigt, aber nun das frische Ergebnis zwischenzuspeichern ist. Klare Sache: Locking verhindert, dass zwei Requests sich gegenseitig das Ergebnis zerstören. Das wiederum verhindert aber, dass diese parallelen Requests performant parallel abgearbeitet werden können, denn sie müssen ALLE nacheinander das identische Ergebnis in den Cache speichern. Und solange der Cache nicht final gespeichert wurde, müssen alle neuen Requests den Cache ja aktualisieren.
Gegen diese Problemklassen gibt es natürlich Gegenstrategien, die man einsetzen kann, aber du merkst sicherlich, dass Caching nicht so simpel ist, wie es auf den ersten Blick aussieht.
- Sven Rautenberg