PHP Templates Cache Grundlagen

Hi leute,
ich wollte mal meine Template Klasse mit Cache erweitern, jedoch weis ich nicht genau wie das ganze funktioniert. Also Smarty erstellt ja irgendwelche Datein in einem Ordner welche nur von einem bestimmten User aufgerufen werden. Wie auch immer.. könnte mir hier einer das Grundprinzip von Caching von HTML Datein erklären?
MFG

Also was Smarty macht, ist die in Smarty-Syntax verfassten Dateien in PHP-Dateien umzuwandeln und speichert sie in einen Ordner so dass sie nicht bei jedem Aufruf geparsed werden müssen - meinst du das?

Ansonsten ein guter Startpunkt für Recherchen: http://en.wikipedia.org/wiki/Memcached (dafür gibt es auch ein PHP-Modul)

ja Memcache kenne ich, es ging mir eben darum. zb bei die Stämme hat man sowas wie style123124.css also ich denke die gehen dabei so vor dass die alle html/css datein in irgend ein ordner mit einer id abspeichern und dann für jeden user eine eigenständige html/css datei. oder für eine anzahl von user genau weis ich es aber eventuell weis ja jemand was gemeint ist

MFG

pro user zu cachen macht imho nur sinn wenn daten userspezifisch sind und sind bei css wohl am unwahrscheinlichesten , es sei denn man hat themes, aber auch da, was soll man an einer css cachen wolen

wenn du jedoch solche konstrukte meinst

"css/index.css?1254213607"

dann sieht das eher nach einem  TS-refresh aus,  welches du bei allen Ressourcen anwenden kannst, auch bild.jpg?1232434, damit erzwingst du in der regel einen update des browsercaches ohne dass user strg+f5 oder du spezielle header losschicken musst

So funktioniert HTML Caching in Rails

http://guides.rubyonrails.org/caching_with_rails.html

Ist zwar kein PHP, jedoch die Konzepte die dahinter stecken sind verdammt geil und man kann auch für PHP einiges mitnehmen.

@redrick

ja genau das meinte ich, aber wie funktioniert sowas? ein einfaches timestamp an das ende der datei setzen würde bestimmt nicht funktionieren

@ buhrmi

da brauche ich doch irgendwelche klassen? kann man irgendwo den quellcode der klassen anschauen?

Original von BlackScorp

@redrick

ja genau das meinte ich, aber wie funktioniert sowas? ein einfaches timestamp an das ende der datei setzen würde bestimmt nicht funktionieren

imho ist es auch kein cache-mechanismus im herkömmlichen sinne,  sondern nur ein workaround um ein eventuell aktives browsercaching des nutzers umzugehen/auszuhebeln.

Beispiel:

Ein User hat seinen Browser angewiesen, Ressourcen(bilder, css, js) nur alle paar Tage zu refreschen (bzw geschieht dies per default). Das befolgt der Browser i.d. R.  jedoch auch nur wenn es sich um gleichnamige Ressourcen handelt. Sobald ein veränderter TS dahinter steht, sieht der Browser rot und lädt trotzdem frisch rein in seinen Cache (ist ja auch  streng genommen eine vollkommen neue URL, die er nicht im Cache hat)

Ich persönlich finde sowas bei JS und Flash Anbindungen nützlich,  insbesondere da muss keiner STRG+F5 drücken um kurzfristig geänderte JS/SWF "includes" auch wirklich vom Server ausgeliefert  zu bekommen.

Richtig. Allerdings ist da ein jeweils aktueller Timestamp meiner Meinung nach übertrieben. Bei jeder Änderung von statischen Files (css, js) wird bei uns in der jeweiligen Konfigurationsdatei eine Konstante angepasst, die automatisch an diese statischen Files angehängt wird. In der Regel ist das ein UNIX-Timestamp vom Zeitpunkt der Aktualisierung der Dateien. Somit holt sich der Browser die Daten nur dann, wenn sie auch wirklich geändert wird. Spart eine Menge Traffic ;)

Die Edit-Funktion scheint gerade außer Betrieb zu sein, deshalb kann ich den Fehler im vorletzten Satz gerade leider nicht ändern.

Original von force4

Richtig. Allerdings ist da ein jeweils aktueller Timestamp meiner Meinung nach übertrieben.

 Es ist sicher der Zeitpunkt der letzten Änderung der Datei gemeint gewesen und nicht dir aktuelle Uhrzeit.

Original von buhrmi

So funktioniert HTML Caching in Rails

http://guides.rubyonrails.org/caching_with_rails.html

Ist zwar kein PHP, jedoch die Konzepte die dahinter stecken sind verdammt geil und man kann auch für PHP einiges mitnehmen.

 Leider ist die Doku nicht nur absolut unverständlich für PHP-Programmierer (auf Grund der etwas gewöhnungsbedürftigen Syntax), es sollte sich auch seit etwa 10 Jahren herumgesprochen haben, dass horizontale Scrollbars nicht besonders menschenfreundlich sind.

class StoreSweeper < ActionController::Caching::Sweeper # This sweeper is going to keep an eye on the Product model observe Product # If our sweeper detects that a Product was created call this def after_create(product) expire_cache_for(product) end # If our sweeper detects that a Product was updated call this def after_update(product) expire_cache_for(product) end # If our sweeper detects that a Product was deleted call this def after_destroy(product) expire_cache_for(product) end private def expire_cache_for(record) # Expire the list page now that we added a new product expire_page(:controller => '#{record}', :action => 'list') # Expire a fragment expire_fragment(:controller => '#{record}', :action => 'recent', :action_suffix => 'all_products') end end 

Ein Traum....

Als Bild:

Original von TheUndeadable

[...], dass horizontale Scrollbars nicht besonders menschenfreundlich sind.

Passiert nicht, wenn man einen anständigen Browser nutzt. Rails wird mir immer sympatischer.

Ich bevorzuge liebe gültiges JavaScript und Browser, die Standards penibel umsetzen und nicht einfach larifari alles akzeptieren was akzeptierbar ist:

Man beachte das überflüssige Komma...

Aber back to topic... Ich habe nicht angefangen herumzuflamen.

CodeHighlighter.addStyle("yaml", {
 keyword : {
  exp  : /\/\*[^*]*\*+([^\/][^*]*\*+)*\//
 },
 value : {
  exp  : /@\w[\w\s]*/
 },
});

Jut, der verantwortliche Javascript-Entwickler gehört geteert und gefedert - du als Verwender des IE aber auch ebenso :) In diesem Falle also kein Pluspunkt für Rails (wieso auch, Javascript hat doch nichts mit Rails zu tun), aber auch kein Glanzpunkt für den IE (ich merke an, dass der Fehler schon immer im IE war und im IE6 (ohne SP) sogar für Abstürze sorgte). Da MS eh nicht für Standards allsamt bekannt war (okay, ändert sich in mancher Entwicklungsabteilung), hätte man ja auch eine Erweiterung der Syntax wie alle anderen machen können.

Zurück zum Thema: Anstatt des letzten Änderungszeitstempels kann man auch die letzte Revision nehmen; bei SVN die ID, bei anderen VCS vllt nur die ersten X Zeichen (wird doch sonst arg lang). Den aktuellen Zeitstempel nimmt man nur bei einer Resource: Ajax-Requests (GET), weil manche Browser (ACK!!!) ab und zu cachen..

Hi also das Ganze schweift ja ganz schön aus.

Also worum es mir geht. die xyz.html Datei befindet sich auf dem Webserver, ein User öffnet die Datei und sieht ne Seite(oder besser gesagt eine php datei holt sich den inhalt der html datei manipuliert es etwas und gibt das im browser aus). Nun wenn viele Besucher gleichzeitig auf der Seite sind "laggt" es doch dann. Weil es halt dann viel zu lange dauert eine Datei von mehreren Clients einzulesen.

Ich dachte Innogames packen zb 1000 spieler als eine gruppe für diese Gruppe werden die datein kopiert und dann nur für die bestimmte gruppe wird die datei angezeigt. wenn man sich ein einer anderen gruppe befindet kriegt er andere datein angezeigt. die datein haben den gleichen inhalt nur heißen die anders.

Erst hatte ich vor mein HTML quellcode in Cookies abzuspeichern aber sofort nach der überlegung, habe ihc es sofort aus dem kopf geschmissen.

Also wie könnte ich denn den schnellen seiten aufbau ermöglichen trotz hoher besucherzahl?

Du solltest vielleicht genauer analysieren, welcher Teil zur Performanceeinbrüchen führt. Datenbank, PHP, Bandbreite?

Wieso sollte es laggen, wenn viele versuchen eine Datei einzulesen? Diese Datei liegt dann wahrscheinlich im Filecache des Betriebssystems. Mehrere Dateien mit gleichen Inhalt wären da sogar kontraproduktiv.

Original von BlackScorp

Hi also das Ganze schweift ja ganz schön aus.

:|

Also worum es mir geht. die xyz.html Datei befindet sich auf dem Webserver, ein User öffnet die Datei und sieht ne Seite(oder besser gesagt eine php datei holt sich den inhalt der html datei manipuliert es etwas und gibt das im browser aus). Nun wenn viele Besucher gleichzeitig auf der Seite sind "laggt" es doch dann. Weil es halt dann viel zu lange dauert eine Datei von mehreren Clients einzulesen.

Bis hierhin: Maybe.

Ich dachte Innogames packen zb 1000 spieler als eine gruppe für diese Gruppe werden die datein kopiert

Nein, mit Sicherheit nicht.

und dann nur für die bestimmte gruppe wird die datei angezeigt. wenn man sich ein einer anderen gruppe befindet kriegt er andere datein angezeigt. die datein haben den gleichen inhalt nur heißen die anders.

Nein. Was vllt gemacht werden könnte: Statische Inhalte (dazu zählen CSS und die meisten Javascripts) werden bei einem Contentprovider (CDN) ausgelagert; und diese wiederum werden uU nach Region unterteilt. Solch einen Provider hat man entweder selber (bspw. eigene Domain (Subdomain) mit einem Lighttpd o.ä.) oder nutzt bei entsprechender Größenordnung (für ein paar Tausend Zugriffe rühren die aber nichtmal den Finger bei Anfrage) die Großen Akamai, Amazon und Co.

Erst hatte ich vor mein HTML quellcode in Cookies abzuspeichern aber sofort nach der überlegung, habe ihc es sofort aus dem kopf geschmissen.

Gut zu Ende gedacht.

Also wie könnte ich denn den schnellen seiten aufbau ermöglichen trotz hoher besucherzahl?

Erst analysieren, was wirklich langsam braucht. Ist es also definitiv der Webserver? Der Server? Oder dessen Bandbreite? Oder dessen langsame Platte? Vllt auch nur eine Beschränkung durch viele Requests (Stichwort)? Was sagt YSlow?

Original von BlackScorp

Ich dachte Innogames packen zb 1000 spieler als eine gruppe für diese Gruppe werden die datein kopiert und dann nur für die bestimmte gruppe wird die datei angezeigt. wenn man sich ein einer anderen gruppe befindet kriegt er andere datein angezeigt. die datein haben den gleichen inhalt nur heißen die anders.

Es könnte seine, dass sie den statischen trafic auf verschiedene Server verteilen, dann müste in erster Instanz aber natürlich der Knoten-Teil der URL unterschiedlich sein und nicht der Dokumenten-Teil. Aber gut möglich, dass die so etwas machen.

Erst analysieren, was wirklich langsam braucht. Ist es also definitiv der Webserver? Der Server? Oder dessen Bandbreite? Oder dessen langsame Platte? Vllt auch nur eine Beschränkung durch viele Requests (Stichwort)? Was sagt YSlow?

achso es kann also im grunde nur am server liegen ob eine seite schnell bzw langsam geladen wird und mit code kann man da nciht viel ändern? dachte mir dass es dann ausreicht wenn ich ein langsamen server hole aber irgendwas am code einstelle oder irgendwie das ganze verwalte dass der seitenaufbau schnell geht

Original von BlackScorp

Also wie könnte ich denn den schnellen seiten aufbau ermöglichen trotz hoher besucherzahl?

1. Dynamische Seiten und Seitenfragmente Cachen = Auf Festplatte speichern anstatt sie bei jedem Request neu zu generieren.

2. Langsamen Code fixen

3. Datenbankschema verbessern

4. Dedizierte Datenbank benutzen

5. Bessere Hardware kaufen

6. Realisieren, dass das alles zum jetzigen Zeitpunkt noch total unnötig ist

Original von Todi42

Es könnte seine, dass sie den statischen trafic auf verschiedene Server verteilen, dann müste in erster Instanz aber natürlich der Knoten-Teil der URL unterschiedlich sein und nicht der Dokumenten-Teil. Aber gut möglich, dass die so etwas machen.

Der "Knoten-Teil der URL", also der FQDN, kann auch beim verteilen der Last auf unterschiedliche Server gleich sein. Mir fallen da sogar mehrere Verfahren ein: DNS-Round-Robin, Load-Balancer, ...

Original von buhrmi

6. Realisieren, dass das alles zum jetzigen Zeitpunkt noch total unnötig ist

klingt nach einem der 10 gebote, köstlich und gold wert, schade dass der Kontext der Theadthemen so wenig beachtet wird, sonst würde man nicht so oft ausschweifen

Original von Dunedan

Original von Todi42

Es könnte seine, dass sie den statischen trafic auf verschiedene Server verteilen, dann müste in erster Instanz aber natürlich der Knoten-Teil der URL unterschiedlich sein und nicht der Dokumenten-Teil. Aber gut möglich, dass die so etwas machen.

Der "Knoten-Teil der URL", also der FQDN, kann auch beim verteilen der Last auf unterschiedliche Server gleich sein. Mir fallen da sogar mehrere Verfahren ein: DNS-Round-Robin, Load-Balancer, ...

Man setzt diese Methode ein um viele Dateien schneller laden zu können, da der Browser ja nur maximal 5 (?) HTTP-Requests pro Domain macht.

Alternativ sollte man vermeiden viele kleine Dateien zu nutzen und stattdessen alle CSS/JS-Dateien in eine große gzippte cachen und ausliefern. Bei Icons nimmt man dazu CSS-Sprites etc.

Aber hier gehts ja gar nicht um allgemeine Performance-Tipps...

Man setzt diese Methode ein um viele Dateien schneller laden zu können, da der Browser ja nur maximal 5 (?) HTTP-Requests pro Domain macht.

Afaik 2. Und die Antwort auf die Frage: was ist YSlow?

> da der Browser ja nur maximal 5 (?) HTTP-Requests pro Domain macht.

Waren 2 bzw. 3 (laut HTTP-Protokoll).

Zumindest der IE 8 missachtet diese Einschränkung und ballert den Server zu, soweit wie er es für richtig hält. FF 3.5 meines Wissens nach auch.

Original von Klaus

Man setzt diese Methode ein um viele Dateien schneller laden zu können, da der Browser ja nur maximal 5 (?) HTTP-Requests pro Domain macht.

Alternativ sollte man vermeiden viele kleine Dateien zu nutzen und stattdessen alle CSS/JS-Dateien in eine große gzippte cachen und ausliefern. Bei Icons nimmt man dazu CSS-Sprites etc.

Aber hier gehts ja gar nicht um allgemeine Performance-Tipps...

Könntest du es trotzdem hier bzw. in einem eigenen Beitrag ausführlicher erläutern? Fände es sehr interessant.

Original von mar1us

Könntest du es trotzdem hier bzw. in einem eigenen Beitrag ausführlicher erläutern? Fände es sehr interessant.

http://developer.yahoo.com/performance/rules.html

bzw yslow bzw google pagespeed zum einlesen & überprüfen

Original von mar1us

Original von Klaus

Man setzt diese Methode ein um viele Dateien schneller laden zu können, da der Browser ja nur maximal 5 (?) HTTP-Requests pro Domain macht.

Alternativ sollte man vermeiden viele kleine Dateien zu nutzen und stattdessen alle CSS/JS-Dateien in eine große gzippte cachen und ausliefern. Bei Icons nimmt man dazu CSS-Sprites etc.

Aber hier gehts ja gar nicht um allgemeine Performance-Tipps...

Könntest du es trotzdem hier bzw. in einem eigenen Beitrag ausführlicher erläutern? Fände es sehr interessant.

Ich blick grad nichtmehr ganz durch...

Mit HTTP/1.0 wäre das vielleicht noch ein Problem gewesen aber HTTP/1.1 (das jeder Server/Browser heutzutage gebraucht) wird doch weder für jedes Objekt eine eigene Verbindung aufgebaut noch wird vorm senden weiterer Daten auf eine Empfangsbestätigung  gewartet.

Seit HTTP/1.1 gibt es persistente getunnelte Verbindungen -> es wird also nichtmehr für jedes angeforderte Objekt eine Verbindung aufgebaut.

Die meißten vom Client zum Server gesendeten Packete werden doch wohl Empfangsbestätigungen sein oder nicht? Wieso sollten die Browser die Server mit Requests vollballern? (Kann mir das vielleicht jemand erklären?)

Danke, Jan

Sorry für die vielen Fehler, das editieren funktioniert irgendwie nicht :(

Oh man, sorry für 3-fach Post. Hatte grad ne Latte vorm Kopf und bin selbst drauf gekommen. ;) @mods, die Einträge können gelöscht werden

Original von knalli

Man setzt diese Methode ein um viele Dateien schneller laden zu können, da der Browser ja nur maximal 5 (?) HTTP-Requests pro Domain macht.

Afaik 2. Und die Antwort auf die Frage: was ist YSlow?

Und ein Link weiter wäre zu finden: http://developer.yahoo.com/yslow und dort bspw. Review the YSlow User Guide - muss man hier denn alle Kinder bei der Hand nehmen?

Früh übt sich wer mal ein guter Papa werden will :p