Sven Rautenberg: Seiten Cachen - Macht das Sinn?

Beitrag lesen

Moin!

Das Problem dabei ist: Wenn du am statischen Teil, der für mehrere oder alle Seiten gilt, was änderst, bist zu gezwungen, alle statischen Seiten neu zu generieren.

Ja, aber das ließe recht einfach lösen indem man die Seiten beim Ausliefern cachen lässt. Da müssen sie sowieso zusammengebaut werden und dann kann der Krams auch einfach wieder in den Cache geschrieben werden. Wenn sich dann wirklich was am statischen Teil ändert löscht man einfach die entsprechenden Dateien aus dem Cache und wartet bis die betreffende Seite erneut abgerufen wird. Es ist ja unnötig den Cache beim Ändern direkt wieder komplett zu befüllen sondern das kann ja gemacht werden, wenn die betreffende Seite zum ersten mal angefragt wird.

Wie gesagt: Nachmessen, ob und wieviel das bringt, wäre schlau.

Abgesehen davon: Ein Cache, den man nur manuell durch Löschen seiner Inhalte zur Aktualisierung bewegen kann, klingt in meinen Ohren nicht so Klasse.

Und bevor du einwenden willst, dass du ja nur die Seiten generieren mußt, die sich geändert haben: Vergiß es! Es ist vermutlich aufwendiger (mindestens hinsichtlich der zu erstellenden Auswahllogik, vermutlich aber auch hinsichtlich der dafür zu ermittelnden Informationen), herauszufiltern, ob eine Seite neu generiert werden muß, anstatt einfach pauschal alle Seiten zu generieren.

Nein, denn es ist bei mir sehr streng definiert auf welche Seiten eine Änderung Auswirkungen hat. Generell gibt es zwei Fälle:
a.) Es wird eine seite geändert, betrifft eine Seite
b.) Es wird das design geändert, betrifft alle Seiten.

Dann sind Änderungen in der Navigation also Designänderungen? Oder verlinkst du nicht?

Ich habe mal ein CMS geschrieben, welches einen zentralen Seitenpool und individuelle Seiten für viele Filialen eines Unternehmens verwalten sollte. Wenn keine individuelle Seite existiert, wird die allgemeine Seite verwendet. Die Generierung der gesamten Website (ca. 300 Filialen, je Filiale etwa 15 Seiten) dauerte mehr als 15 Minuten

Wozu war es nötig alle Seiten auf einmal zu generieren? Hätte es nicht ausgereicht die Seiten nur dann zu generieren, wenn sie zum ersten mal abgerufen werden sollen?

Weil eine Seite aus diversen Elementen besteht, die alle geändert sein könnten: Seiteninhalt der individuellen Seite, oder der allgemeinen Seite, oder der Navigation, oder des Templates, oder der Filialdaten (Adresse etc.).

Hätte ich bei jedem einzelnen Element erst feststellen wollen, ob und wann es geändert wurde, ob dieses Datum neuer ist als das der bereits bestehenden Seite, und ob deshalb eine Neugenerierung erfolgen muß, hätte ich zwar viel Zeit beim Generieren eingespart, aber deutlich mehr Zeit beim Ermitteln der Daten verbraucht.

Abgesehen davon hatte das System diverse Nebenbedingungen, die ich erfüllen mußte: IIS, ASP, kein Rewriting, alte existierende URLs auf ".html" usw.

Nein, das bestreite ich, solange du keine Meßergebnisse bringst. Warum ist es weniger effektiver, einfach eine simple PHP-Datei mit wenig PHP zu parsen und an den Browser zu schicken? Dein System muß eine PHP-Datei parsen, dann eine Cache-Datei öffnen, eine Zeile 1 interpretieren, den nachfolgenden Inhalt ausgeben, oder den nachfolgenden Inhalt evaluieren, und dann das ganze an den Browser schicken. Sieht irgendwie deutlich aufwendiger aus.

Schon ein bisschen unfairer Vergleich zwischen "einfach parsen" und das andere System total auseinandergenommen, oder?

Nein, nicht wirklich. Ich habe verglichen, was an relevantem Unterschied passiert. So oder so muß eine PHP-Datei geöffnet und geparst werden. Entweder mit dem statischen und dynamischen Content, oder mit deinem Cachecode. Aber schätzungsweise ist es aufwendiger, erst den Code für das Feststellen des Cache-Falles auszuführen, dann den Cache einzulesen, die Inhalte aufzuspalten, den Dynamic-Teil durch eval() zu jagen und dann die Ausgabe an den Browser zu schicken, als einfach statisches HTML und PHP-Blöcke mit dem Minimum an Code zur Herstellung der Dynamik auszuführen - ohne innere eval()-Schicht und Cache-Parsing.

Einfach parsen ist auch: PHP Datei öffnen, statisches HTML an den Browser senden, PHP block parsen, include-Datei (und womöglich noch die Datenquelle) öffnen, lesen, parsen, ergebniss an den Browser schicken, weiteres HTML lesen, rausschicken, PHP-Block parsen, include-Datei öffnen usw.

Stimmt alles, aber deine Cache-Version wird ja wohl auch kaum um Includes herumkommen. Das dürfte also kaum einen Unterschied machen.

Und die PHP-Anweisungen sind deutlich aufwendiger.

Sofern die Dynamik erfordert, Kontakt zu einer Datenbank aufzunehmen, läßt sich das kaum wegrationalisieren. Damit ist allerdings auch ein zeitaufwendiger Faktor nicht zu eliminieren, nämlich der Connect zur DB.

Also bitte nachmessen, was schneller ist. Wenn du nicht messen kannst, kannst du nicht optimieren. Nur weil du GLAUBST, dass etwas schneller ist, muß das nicht wirklich so sein.

Behaupte ich auch nicht. Aber um zu messen muss man bauen und vorm bauen frag ich doch lieber nach ob nicht irgendwer schon im Voraus einen dicken Konzeptionsfehler findet.
Aber ich werde das dann wohl einfach mal ausprobieren. Irgendwelche Tipps wie ich am dümmsten messe, eine einfache Laufzeitberachtung wird es ja wohl kaum tun...

Das ist eben der Punkt: Wenn du messen willst, mußt du festlegen, was du messen willst. Also mußt du wissen, was du optimieren willst. Also mußt du wissen, wo der Schuh drückt.

Und: Wo drückt der Schuh?

Wie erwähnt: Datenbanken haben Caches, es ist also beim zweiten und dritten Zugriff auf die gleichen Daten schneller ein Ergebnis geholt.

Funktioniert aber auch nur, wenn die Datenbank auf dem selben Rechner rödelt...

Nein. Datenbanken haben immer Caches, und der Ort ihrer Werkels hat auf dessen Inhalt keinen Einfluß. Im Gegenteil: Ein eigenständiger DB-Server kann sich sogar mehr RAM für Caches genehmigen.

Keine Frage. Ausliefern von nicht aktuellen Seiten ist definitiv inakzeptabel. Aber das wird auch nicht weiter passieren, da sich immer nur einzelne Seiten ändern lassen.

Bis auf so Dinge wie Änderung von Navigation etc., die seitenübergreifend wirken. Da muß doch nur eine einzige Seite neu dazu kommen oder gelöscht werden, und schon kann auf der gesamten Site ein Link ungültig werden. Und sowas ist in aller Regel auch in den Bearbeitungsmöglichkeiten der Redakteure.

- Sven Rautenberg

--
"Love your nation - respect the others."