Frage zum Caching mit PHP

Keine Verändeungen als Header ist für Suchmaschinen nicht von Vorteil.
Spart sicher so am meisten Resourcen ein, frage ist nur was das Ziel ist.
Firmen würden wohl eher mehr kosten in kauf nehmen und den Header weglassen und nur kontrolle ist gecached (ja/nein) print cache oder völlständig neu generieren.
So durchläuft die Suchmaschine die Seite auf jedenfall.
(Richtige Firmenseiten haben auch wohl mehr seiten die folgen, die ansonsten nicht erfasst werden.)
 
@Gumbo: ich will das ja auch irgendwie trennen, aber das fällt schwer dann zu erkennen, ob ein ETag dann noch irgendwie gültig ist, wenn der HTML-Kopf-Bereich sich ändert, wenn man z.B. eingeloggt ist. Serverseitiges Caching ist bisher kein Problem. Das Clientseitige bereitet mir Kopfzerbrechen :)

@R00Ki3: Man könnte natürlich auch anhand der User-Agents die Suchmaschinen nichts Clientseitig cachen lassen. Aber wenn das genrell ein Problem ist, sollte man das vielleicht wirklich weglassen.



Also generell macht ja das Serverseitige Cachen viel Sinn, da man ja dann die Anfragen beschleunigen kann. Da ich aber den Kopf-Bereich einer Seite ändern möchte, je nachdem ob der Benutzer eingeloggt ist oder nicht, kann ich ja nur einen Teil wirklich Cachen.

Wie kann ich dann noch einen guten Client-seitigen Cache aufbauen? So langsam geht's ans eingemachte :)


Gruß Radhad
 
Nur was für alle Benutzer gilt, kann im Cache gespeichert werden. Denn andernfalls kann es zur ungewollten Informationspreisgabe kommen, was unbedingt vermieden werden muss.
So könnten dann auf einer Seite, die benutzerspezifische Informationen enthält, auch nur gewisse Teile, die bei allen Benutzern identisch sind, im Cache gespeichert werden. HTTP-Caching ist dann allerdings ebenfalls nicht möglich.
 
Was ständig genutzt wird, wäre dann wohl CSS-Datei womöglich Javascript und Header oder so...

Radhad hat gesagt.:
Da ich aber den Kopf-Bereich einer Seite ändern möchte, je nachdem ob der Benutzer eingeloggt ist oder nicht, kann ich ja nur einen Teil wirklich Cachen.
Zum Vergrößern anklicken....

Das ist wohl davon abhängig wie das caching system aufgebaut ist.
Wenn der Aufbau nur nach abfrage speziell zur url ist dann wäre es sicherlich so.
Login läuft sicherlich bei dir über Session oder Cookie und dann müßte die Funktion zum caching um den WertLogin / Logout erweitert werden.

Falls aber von Person zu Personson der Header unterschiede erweißt wäre das wohl sinnlos. Außer es handelt sich um Werte die In der SESSION oder COOKIE enthalten sind, die via str_replace oder so auf dem einfachsten weg ausgestauscht werden können.
 
Zuletzt bearbeitet:
Ok, damit hat sich HTTP-Caching dann erledigt. Dann muss ich nur noch dafür Sorge tragen, dass nur öffentliche Inhalte serverseitig von meiner Caching-klasse verarbeitet werden. Dann bleibt nur noch eine Frage offen: wie sollte man serverseitiges Caching am besten verwenden?

Dazu ein kurzes Beispiel:
Es wird ca. alle paar Tage eine News gepostet, welche auf der Startseite zu sehen sein wird (die letzte X News).
Sollte man das Cache-File alle X Sekunden neu erstellen oder einfach erst dann, wenn es ne neue News gibt (davon ausgehend dass sonst nichts dynamisches dabei ist wie Kommentare z.B. die mit angezeigt werden)?

R00Ki3 hat gesagt.:
Was ständig genutzt wird, wäre dann wohl CSS-Datei womöglich Javascript und Header oder so...



Das ist wohl davon abhängig wie das caching system aufgebaut ist.
Wenn der Aufbau nur nach abfrage speziell zur url ist dann wäre es sicherlich so.
Login läuft sicherlich bei dir über Session oder Cookie und dann müßte die Funktion zum caching um den WertLogin / Logout erweitert werden.

Falls aber von Person zu Personson der Header unterschiede erweißt wäre das wohl sinnlos. Außer es handelt sich um Werte die In der SESSION oder COOKIE enthalten sind, die via str_replace oder so auf dem einfachsten weg ausgestauscht werden können.
Zum Vergrößern anklicken....

Session-basierter Login ist zumindest geplant, ohne Auto-Login, da es zu unsicher ist.

Im Kopf-Bereich soll dann der Benutzername erscheinen und ein paar weitere Links, daher würde ich den statischen Kopf-Bereich cachen und den dynamischen folglich nicht ;) Somit treten auch keine Probleme auf und ich muss net nochmal zusätzlich nen str_replace durchlaufen, da das unter umständen langsamer ist als den Kopf-Bereich zu von PHP rendern zu lassen. Wenn ich es sehr geschickt mache, überlagert auch nur der dynamische Header den statischen, das müsste ich mal ausprobieren, dann bräuchte ich den nur einfach anfügen *g*
 
Mahlzeit,

ich bin gerade selbst dabei, eine Template-Klasse mit Cache-Funktion u schreiben, und habe das ganze vom Prinzip her so gelöst:

Das ausgeworfene HTML, das durch PHP erzeugt wird, verbietet im Header erstmal Browser-und Proxy Cache, da man nicht weiss, wie der User seinen Browser eingestellt hat bzw wie oft der User seinen Cache leert, auch damit Google & Co nix sinnlos speichert.
Mein Cache-System läuft nun so ab, dass ich anhand einer MD5-Summe die aufgerufene Datei incl. Querystring in einem Extra-Verzeichnis im http-doc suche, und bei Auffinden prüfe, wie alt diese Datei ist. Ist sie älter als 5 Sekunden, mache ich ein MD5 des INHALTES der Datei, speichere diese Summe und rendere das HTML mit PHP neu. Hat sich der Inhalt nicht geändert, setze ich das dateidatum neu, indem ich die Datei kurz öffne, auslese dann lösche und neu erstelle.
Beinhaltet eine PHP-Datei einen POST, so wird nicht gecached, da das User-Input ist, der eh aktuell sein muss. Folglich bekommen einige User nur den Cache, andere wiederrum das Original - meine Auslastung geht dabei stark auch gut zurück, da der DB-Traffic entfällt ;)

Ideen dazu ? Immer her damit :)
 
andy72 hat gesagt.:
Mein Cache-System läuft nun so ab, dass ich anhand einer MD5-Summe die aufgerufene Datei incl. Querystring in einem Extra-Verzeichnis im http-doc suche, und bei Auffinden prüfe, wie alt diese Datei ist. Ist sie älter als 5 Sekunden, mache ich ein MD5 des INHALTES der Datei, speichere diese Summe und rendere das HTML mit PHP neu. Hat sich der Inhalt nicht geändert, setze ich das dateidatum neu, indem ich die Datei kurz öffne, auslese dann lösche und neu erstelle.
Beinhaltet eine PHP-Datei einen POST, so wird nicht gecached, da das User-Input ist, der eh aktuell sein muss. Folglich bekommen einige User nur den Cache, andere wiederrum das Original - meine Auslastung geht dabei stark auch gut zurück, da der DB-Traffic entfällt ;)
Zum Vergrößern anklicken....
Also die 1. Prüfung machtm einer Meinung nach nicht viel Sinn. Ich übergebe nen Dateinamen, und dann wird geprüft mit if(file_exists(FILENAME)). Wenn die Datei nicht existiert (was nur einmal sein kann), dann erzeuge die Datei, render das HTML und schreib es rein. Existiert die Datei, prüfe anhand des LastModified Datum's, ob sie noch aktuell ist. Meine Idee ist entweder Global festzulegen, wiel ange eine Datei gecached werden soll (aber einzeln definieren, ob gecached werden soll) oder es direkt per Methode in der PHP-Datei festzulegen ($tpl->CacheFile(true, "Datei.html", 60 /*Sekunden*/);) oder so ähnlich.

Du zerstörst meiner Meinung nach zu oft die Datei, es reicht einfach, wenn sie abgelaufen ist mit file_put_contents() den Inahlt neu reinzuschreiben - das minimiert auch die Last auffem Webserver.
 
hm, Wo ist deiner Meinung nach der Unterschied zw. löschen des inhaltes und Neuerzeugen der Datei-Inode auf dem Server ? Fakt ist doch, dass beides Last auf dem Server erzeugt - egal, ob ich den Inhalt lösche oder die Datei neu erstelle. Klar, ob eine Zeit von 5 Sekunden oder 60 Sekunden ok ist, liegt an der Anwendung und daran, wie oft gecached werden muss/soll. Bei meinen Daten habe ich entschieden, öfter zu cachen, um den Inhalt aktuell zu halten und dem user nicht ständig Cache anzubieten der evtl. veraltet sein kann. Ich bin auch am überlegen, ob ich die Cache-Intervalle anpassen kann, oder statisch einfach festlege ...Sinn macht beides, denke ich
 
Der Sinn vom Caching ist doch, die Inhalte so lange wie möglich zwischenzuspeichern. Was bringt es, statischen Newscontent alle 5 Sekunden neu zu cachen? Macht meiner Meinung nach wenig Sinn. Stimmiger wäre ein partielles Caching (zumindest habe ich das so für mich als die für mich passendere Methode gefiltert, da ich nebenbei noch Benutzer berücksichtigen muss): Die News und / oder das Newsrendering wird gecached für - beispielsweise - 12 oder 24 Stunden. Wenn das Cachefile älter als dieses Setting ist, wird die News neu aus der Datenbank gelesen, gecached und / oder gerendert, gecached.
Bei den Inhalten habe ich die Lebensdauer auf ein paar Tage gesetzt, da diese eigentlich als komplett statisch anzusehen sind.
Ruft nun ein befugter Nutzer eine News oder eine Inhaltsseite auf, bekommt er, wenn Lebensdauer gültig, die gerenderten Contents aus dem Cache in einen dynamischen Rahmen eingebunden, ansonsten wird gelesen, geschrieben, ausgegeben.

Kurzzeitiges Caching widerspricht irgendwie dem Sinn der Sache, es sei denn, es ist schon eine Entlastung für den Server, wenn Dateien, die alle 5 Sekunden aktualisiert würden, gecached würden. Ansonsten macht es wenig Sinn, Dinge zu cachen, die durchschnittlich seltener als 1x pro Intervall gebraucht werden.

Das Löschen und anschließende Neuschreiben ist übrigens nicht sonderlich förderlich für die meisten Datenträger, da immer wieder eine neue Marke gesetzt werden muss beim Erzeugen einer neuen Datei...
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück