HStev

Servus,

ich stell mir grad die Frage wie man bei einen Template System den Caching Algorithmus effizient umsetzen kann. Da ich mir nicht vorstellen kann das eine ständige Überprüfung auf Änderung oder ermittelns eines HASH-Wertes performanter als eine Neu-Generierung ist.
Vielleicht denk ich dafür auch einfach nur viel zu kompliziert deshalb wollte ich diese Diskussion mal anstoßen.

__________________
Gewisse Dinge behält man besser für sich, z.B. das man gewisse Dinge für sich behält.

Mister Ad

cortex

habe mir über dieses problem auch schon das ein oder andere mal gedanken gemacht... es wird ja oft als das killer-feature (vor allem bei frameworks) dargestellt. ich denke, es kommt auf den jeweiligen aufwand an, i.e. auf den umfang der angeforderten ressource:
prüfen, ob sich angeforderte ressource im cache befindet / ggfs. auslesen vs. seite komplett "neu" aufbauen incl. php-parsing und sql-queries.

darüber hinaus habe ich bis dato noch keine caching strategie gesehen, die durch intelligenz (kein statisches expire) und schonung der ressourcen (hdd-zugriffe, ram-verbrauch) glänzte. vielleicht lässt sich das auch nicht miteinander vereinbaren...

anderslautende meinungen / erfahrungen würden mich ebenfalls interessieren.

cx

robo47

Ich halte es für die meisten Systeme für die falsche Strategie, on-demand zu überprüfen ob der Cache noch gültig ist, sowas macht meiner Meinung nach eben nur Sinn bei Zeit-basierten Caches, weil wie du schon sagst, eine Überprüfung meistens auch einiges an Zeit braucht.

Sinnvoller ist es eben den Cache zu löschen, wenn er veraltet ist und zwar dort wo die Daten verändert werden.
Man muss sich nur ein System für die Tags überlegen, wie man seine Inhalte im Cache verwaltet, ihnen z.b. Modul-abhängige / Eintrags-abhänige Tags verpassen und sobald jemand Inhalte verändert, neuen Eintrag erstellt, Eintrag verändert, etc werden einfach alle Einträge im Cache mit den passenden Tags gelöscht, so verschiebt man die komplette Cache-Logik an einen Ort wo etwas mehr Rechenzeit nicht unbedingt so stark auffällt (abhängig vom System, aber im Normalfall hat nutzt man ja einen Cache in Systemen wo es deutlich mehr Lese als Schreib-Zugriffe gibt und Daten eben durchaus längere Zeit nicht verändert werden.)

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

Flor1an

Also ich denke schon das Caching, auch wenn der Cache auf "expire" geprüft wird, einen Geschwindigkeitsvorteil bringen kann.

Bei einer Startseite werden mehrere Querys abgefeuert die aus einer recht großen Datenmenge lesen, dazu kommen noch JOINs auf mehrere andere Tabellen. Und das gleich mehrfach. Dazu kommen noch Kalender, Useronline, Werbung/Bannerrotation und so weiter.
Das sind locker > 10 Querys die ne relativ große Datenmenge selektieren. Wenn da 200 User gleichzeitig surfen zwingt das die Datenbank in die Knie. Der Webserver läuft ohne große Probleme, nur die Datenbank schafft einfach nicht so viel.

Und da bringt Caching doch einiges, denn dann hast du vlt. 200x eine Datei einlesen, aber es fallen 10 Querys pro Aufruf ab, dass sind rund 2000 Querys alle paar Sekunden. Und der Cache muss ja nicht mal sehr lange existieren, es reicht ja wenn er alle 1-2 Minuten neu erstellt wird ... dann hat man jede Minute einmal 10 Querys die den Cache generieren ... im Gegensatz zu ich sag mal 2000-4000 Querys pro Minute die sonst abgefeuert würden.

Aber sicher ist es praktischer wenn ein Cache gar nicht erst überprüft werden muss. Allerdings stell ich mir das mit dem Taggen durchaus recht schwierig vor. Vor allem wenn bestimmte Seiten aus sehr vielen Daten (von verschiedenen Quellen) existieren kommen da schnell mal einige Tags zusammen, wenn man da mal nicht was übersieht.

Ich hätte noch eine andere Idee. Man verwendet einen Cache der eben direkt angezeigt wird ohne überprüft zu werden, allerdings wird bei der Generierung des Caches die expiretime z.b. in eine Datenbank geschrieben, alle paar Minuten läuft dann ein Cronjob der alle Caches löscht die eben abgelaufen sind. Dann hat man vielleicht eine Ungenauigkeit von der Zeit die der Cronjob läuft aber ich denke das ist bei einem Cache kein Problem ob er jetzt 5 Minuten länger oder kürzer existiert.

nikosch

Wieso eigentlich expired prüfen? Beim Namen generieren einfach ein Modulo auf den aktuellen Timestamp mit in den Namen nehmen. Das erste Script, das auf das neue leere Cachefile trifft schreibt es dann.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

HStev

Hast ein Beispiel dazu? Ist etwas schwer verständlich wie du das meinen könntes.
Warum ein Modulo auf den Timestamp? Vor allem mit welchen Wert?

__________________
Gewisse Dinge behält man besser für sich, z.B. das man gewisse Dinge für sich behält.

nikosch

1/ Timestamp ist ein INT.
2/ Modulo Timestamp auf Sekunden entsprechend 14 Tagen
3/ Dann ändert sich alle 14 Tage das Ergebnis
4/ Dieses Eergbnis + weitere relevante (statische) Daten benutzen und bspw. über md5 nen Hash daraus erstellen
5/ Dieser Hash ist der Filename
6/ Filename verfällt automatisch, weil irgendwann ein neuer Dateiname gültig ist
7/ CRON muß aufräumen.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

HStev

hast du da nicht n denkfehler? Der Wert ändert sich doch continurierlich...

__________________
Gewisse Dinge behält man besser für sich, z.B. das man gewisse Dinge für sich behält.

nikosch

Deshalb doch Modulo.
time () % 3600 sollte jede Stunde nen neuen Wert erzeugen, oder? Oder Ganzzahldivision? Jetzt bin ich grad verwirrt.

[edit]
Stimmt: Ganzzahldivision!

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Robsen

Bei non-expire-caching empfinde ich es als sinnvoller, den Cache dann neu zu schreiben, wenn sich die entsprechende (zu cachende) Seite verändert.

Hier gibt es nun 2 Möglichkeiten:

Bei Verändern der entsprechenden Seite...
1) wird der Cache für diese Seite gelöscht... das Cachefile wird beim ersten darauf folgenden Zugriff generiert.
2) wird direkt auch das Cachefile neu geschrieben.

Ich empfinde Methode 1 als bequemer, aber das ist Ansichtssache.

Grüße