[Ben]

Hi,
1. bisschen freundlicheren Umgangston bitte!
2. Ich finde, dass man den Beitrag gut lesen kann. Aber ich bin ja bekanntlich ein DAU, demnach wäre es mir Recht, wenn du dir das hier ..

Zitat von Byrel

Ich mach mir jetzt mal nicht die Mühe das zu kommentieren, weil du es anscheinend eh nicht verstanden hast: wann man sowas einsetzt, wieso man sowas und wie man sowas einsetzt.

.. nochmal überlegen könntest und mir auf die Sprünge hilfst.

Grüße, Ben.

[Byrel]

Was zum Vorteil hat, dass jeder Benutzer eine eigene Seite vorfindet, auf der persönliche Daten stehen. Das haben wir bisher außen vor gelassen, aber das ist immens wichtig: Bei deiner Art des Caching ist die personalisierung der Seite nur dann möglich, wenn jeder User seine eigene Seite gespeichert bekommt. Was da jetzt wohl schneller im Zugriff ist?! Ich muss ganz ehrlich sagen, dass ich eigentlich keine dynamische Seite kenne, auf der nicht jedesmal irgendwas "privates" steht und sei es nur die Anzahl der Mails in meinem Postfach.

Bei sowas verwendet man sowas nicht. Sondern da nimm ich nen APC.

Ich habe schon Seiten programmiert, die mit mehreren Tausend Zugriffen / Minute stabil gelaufen sind und das obwohl sie einen Query machen mussten. Gewusst wie sage ich da nur.

Wenn du entsprechende Ressourcen hast.

Ich stehe der Technik nach wie vor kritisch gegenüber und würde sie auch entsprechend nicht benutzen. Es gibt bessere Methoden, Seiten zu cachen, die dann zwar auf dem sleben Prinzip beruhen (nämlich die Seite zu erzeugen und zu speichern), jedoch nicht den Umweg über 404 gehen müssen, was meiner Meinung nach eine unsaubere Lösung ist.

Es ist mir ehrlich gesagt egal, ob du sie verwendest oder nicht. Es ist die schnellste Methode die ich kenne - Punkt.

Wie oben gesagt: Die Berechnungszeit von GZip als Datei dauert im Vergleich zu einem Query ewigkeiten.

Kommt auf die Datenmenge, dein DB-Design, die Komplexität deiner Queries etc. an. Aber auch wenn wir _annehmen_, dass 1 Query schneller ist. Ich generiere die Datei auch nur einmal! Du schickst N Queries ab.

Wenn man nun davon ausgeht, dass während des Schreibens der Datei 200 User versuchen auf diese zuzugreifen, müssen sie erstmal warten, bis die Datei generiert wurde ODER - wenn es nicht richtig programmiert wurde - generieren 200 User die selbe Seite mit 2 Dateien, einmal normal und einmal GZip...

Wenn dein Querie nicht richtig programmiert wurde und anstelle eines Textes 10x 4GB große Binärdateien selektiert, dann ... LoL

Es stockt also so oder so und wenn sich viel ander Seite ändert (z.B. ein Forum mit 100.000 Usern wird stetig im Wandel sein), musst du bei jeder Änderung die Datei neu schreiben oder löschen, damit die neue generiert wird. Was da wohl performanter ist!?

Was willst du von mir?

Hab ich gesagt dass es bei einem Forum verwendet werden soll? Ich hab doch, so weit ich mir erinnern kann irgendwo oben geschrieben, dass bei dynamischen Seiten z.B. APC verwendet werden soll.

Beispiel:

PHP-Code:

if (! ($xyz = apc_fetch ("xyz"))) {
    $xyz= calc_xyz ();
    apc_store ("xyz", $xyz, 3600);
}

if (! ($abc = apc_fetch ("abc"))) {
    $abc= calc_abc ();
    apc_store ("abc", $abc, 3600);
}

$data = array ($xyz, $abc);

$site_template = file_get_contents ("sitetpl.html");
echo str_replace (array ("%%xyz%%", "%%abc%%"),$data, $site_template); 


Das ist nur eine ART des Cachings und kein Wundermittel, das bei allen Seiten und Problemen hilft (Hab ich auch nicht gesagt)!

Bei einer Suchfunktion wirst du sowas z.B. nicht verwenden. Da is ein SQL Cache besser ...

MfG Byrel

[MrNiceGuy]

@Byrel: Auch wenn wir unterschiedlicher Ansicht sind, ist es wohl eher hinterwäldlerisch, sich auf das Niveau der persönlichen Beleidigung herabzusteigen. Ich stelle lediglich in Frage, dass die Performance bei dieser Methode derer anderer Methoden nicht unbedingt überlegen ist und dass die Art und Weise dieser Methode schlichtweg unpraktikabel ist, da sie einen Workaround nutzt, der für andere Dinge gedacht ist.

Zitat von Byrel

Bei sowas verwendet man sowas nicht. Sondern da nimm ich nen APC.

Ja, schön und gut, dann sparst du aber bei einer Community bei 1-2% aller Seiten an Traffic oder schraubst den Komfort der Seite zurück, damit nicht zu viele personalisierte Informationen auf der Seite zu finden sind. Sonst funktioniert das mit deinem Caching ja wieder nicht.
Der Knackpunkt ist schlichtweg, dass gerade die dynamischen Inhalte jene sind, die oft aufgerufen werden, gerade weil sie dynamisch sind und sich oft ändern. Eine Seite, die sich nicht so oft ändert, wird auch nicht so oft aufgerufen, was den Effekt der Geschwindigkeitersparnis im Verhältnis zum Aufwand drastisch minimiert.

Zitat von Byrel

Es ist mir ehrlich gesagt egal, ob du sie verwendest oder nicht. Es ist die schnellste Methode die ich kenne - Punkt.

Das mag ja durchaus sein, aber ist eine Diskussion über den Nutzen dieser Methode deswegen gleich verboten? Ich meine man kann doch dennoch anderer Ansicht sein und trotzdem mal drüber sprechen!?

Zitat von Byrel

Kommt auf die Datenmenge, dein DB-Design, die Komplexität deiner Queries etc. an. Aber auch wenn wir _annehmen_, dass 1 Query schneller ist. Ich generiere die Datei auch nur einmal! Du schickst N Queries ab.

Nicht ganz richtig: Ich schicke genau EINEN Query ab, der nur ein einziges Feld abruft, in dem ein Datum steht. Dieses wird mit dem geschickten verglichen und das wars. Der Query dauert im Normalfall 0,00... sec. Man sollte die Vorteile von Indizes schon kennen

PS: Ich warte immernoch auf ein Beispiel, wie das mit den GZip-Dateien funktioniert...

[Byrel]

Nicht ganz richtig: Ich schicke genau EINEN Query ab, der nur ein einziges Feld abruft, in dem ein Datum steht. Dieses wird mit dem geschickten verglichen und das wars. Der Query dauert im Normalfall 0,00... sec. Man sollte die Vorteile von Indizes schon kennen

Ich rede davon, wenn deine Seite generiert wird. Sie wird für jeden Besucher generiert. Wenn der Browser Seiten nicht zwischenspeichern soll (weil vom User angefordert) wird sogar bei jedem Seitenaufruf generiert. Aber egal. Ich verwende ja auch 304, weil ich da überhaupt nix übertragen muss.
Btw. Bandbreite und GZip-Komprimierung zählen durchaus. Yahoo kürzt sogar Header Informationen. Bei denen zählt jedes Byte. Weil die sonst z.B. 105 Milliarden Byte/Monat zu viel übertragen würden.

PS: Ich warte immernoch auf ein Beispiel, wie das mit den GZip-Dateien funktioniert...

copy ($cacheFile, "compress.zlib://$cacheFile" . ".gz");

Das mag ja durchaus sein, aber ist eine Diskussion über den Nutzen dieser Methode deswegen gleich verboten? Ich meine man kann doch dennoch anderer Ansicht sein und trotzdem mal drüber sprechen!?

Klar. Wenn man gute Beispiele / Situationen hat - kein Problem. Nur wenn du dir Sachen aussuchst bei denen sowas überhaupt keinen Sinn macht, dann sehe ich auch keinen Sinn darin darüber zu diskutieren.

Ja, schön und gut, dann sparst du aber bei einer Community bei 1-2% aller Seiten an Traffic oder schraubst den Komfort der Seite zurück, damit nicht zu viele personalisierte Informationen auf der Seite zu finden sind. Sonst funktioniert das mit deinem Caching ja wieder nicht.
Der Knackpunkt ist schlichtweg, dass gerade die dynamischen Inhalte jene sind, die oft aufgerufen werden, gerade weil sie dynamisch sind und sich oft ändern. Eine Seite, die sich nicht so oft ändert, wird auch nicht so oft aufgerufen, was den Effekt der Geschwindigkeitersparnis im Verhältnis zum Aufwand drastisch minimiert.

Meinst du was ernst? Seiten die sich oft ändern, werden öfter aufgerufen? Hahaha. Dann ändere ich meine Seite einfach jede Sekunde und hab ne Million Besucher ...

Btw: Irgendwie kommen wir hier vom Thema ab.

MfG Byrel

[Ben]

Hi,

Zitat von Byrel

Seiten die sich oft ändern, werden öfter aufgerufen? Hahaha. Dann ändere ich meine Seite einfach jede Sekunde und hab ne Million Besucher

doofes Beispiel.

Webprojekte, die sowieso "gut" besucht sind, beinhalten immer Seiten, deren Inhalt ständig neu generiert wird und Seiten, deren Inhalt fix bleibt. Als Beispiel die Übersichtsseite einer Nachrichtenkategorie. Da werden häufiger Leute draufklicken, als z.B. auf die FAQ der Forensoftware. Warum auch .. da ändert sich doch eh nichts.

Den Umkehrschluss kann man nicht ziehen, das behauptet aber auch niemand.

[Byrel]

Ja, schön und gut, dann sparst du aber bei einer Community bei 1-2% aller Seiten an Traffic oder schraubst den Komfort der Seite zurück, damit nicht zu viele personalisierte Informationen auf der Seite zu finden sind. Sonst funktioniert das mit deinem Caching ja wieder nicht.

Das mit dem 404 Caching? Ja eh nicht, APC aber perfekt. Aber ich wiederhole es trotzdem nochmal:

DIESER 404-TRICK IST NICHT FÜR BENUTZERDEFINIERTE SEITEN GEDACHT!

Eine Seite, die sich nicht so oft ändert, wird auch nicht so oft aufgerufen, was den Effekt der Geschwindigkeitersparnis im Verhältnis zum Aufwand drastisch minimiert.

... und inwiefern hängt das jetzt mit dem Thema zusammen? Es hängt immer von der Website ab. Bei einer Seite mit 100 Aufrufen/Tag vlt. nicht, aber mit ner Million schon. Es macht nämlich nen Unterschied ob ich ne Millionmal eine statische Seite ausliefere oder ne Millionmal die das gleiche PHP File abarbeite und ne Million mal einen Query an die DB schicke.

MfG Byrel

[WarrenFaith]

Also ne Impressumseite?! Super... die ist eh immer statisch...

[MrNiceGuy]

Warren und Ben haben genau das verstanden, was ich meine.

Zitat von Byrel

Ich rede davon, wenn deine Seite generiert wird. Sie wird für jeden Besucher generiert. Wenn der Browser Seiten nicht zwischenspeichern soll (weil vom User angefordert) wird sogar bei jedem Seitenaufruf generiert. Aber egal. Ich verwende ja auch 304, weil ich da überhaupt nix übertragen muss.

Durch den 304-Trick nicht, sagst du doch sogar gerade selst ^^

Zitat von Byrel

Btw. Bandbreite und GZip-Komprimierung zählen durchaus. Yahoo kürzt sogar Header Informationen. Bei denen zählt jedes Byte. Weil die sonst z.B. 105 Milliarden Byte/Monat zu viel übertragen würden.

Das entscheidet wohl jeder Anbieter selber / anders, es gibt auch genügend Seiten im Netz, denen 20 Byte / Aufruf mehr oder minder egal sind, da die Rechenzeit zum Kürzen irgendwelcher Header viel mehr beansprucht, als das Sende dieser überflüssigen Daten.

Zitat von Byrel

copy ($cacheFile, "compress.zlib://$cacheFile" . ".gz");

Scherzkeks Ich meinte ein Beispiel, wie du as GZip-File per Webserver verschickst, ohne dass dieser einen Dateidownload macht.

Zitat von Byrel

Klar. Wenn man gute Beispiele / Situationen hat - kein Problem. Nur wenn du dir Sachen aussuchst bei denen sowas überhaupt keinen Sinn macht, dann sehe ich auch keinen Sinn darin darüber zu diskutieren.

Es dient lediglich dr Erkenntnis, dass diese Methode wenig Sinn macht. Weshalb habe ich schon erklärt und Warren hat es noch Mal schön wiedergegeben.

Zitat von Byrel

Meinst du was ernst? Seiten die sich oft ändern, werden öfter aufgerufen? Hahaha. Dann ändere ich meine Seite einfach jede Sekunde und hab ne Million Besucher ...

Nein, Ben hat es richtig verstanden, ie ich es meinte.

Zitat von Byrel

... und inwiefern hängt das jetzt mit dem Thema zusammen? Es hängt immer von der Website ab. Bei einer Seite mit 100 Aufrufen/Tag vlt. nicht, aber mit ner Million schon. Es macht nämlich nen Unterschied ob ich ne Millionmal eine statische Seite ausliefere oder ne Millionmal die das gleiche PHP File abarbeite und ne Million mal einen Query an die DB schicke.

Ich (und Ben) sagten ja schon, dass statische Seiten wohl weniger aufgerufen werden, weshalb die Frage bleibt, wieviele dieser Million überhaupt auf die statische Seite schauen und ob der Aufwand für dieses Caching sich dann überhaupt rentiert.

[robo47]

Zitat von MrNiceGuy

Scherzkeks Ich meinte ein Beispiel, wie du as GZip-File per Webserver verschickst, ohne dass dieser einen Dateidownload macht.

content-type auf text/html oder was man ansonsten sendet stehen lassen
und
header("Content-Encoding: gzip");
allerdings musst du auch Überprüfen ob der Client Komprimiert kann, aber das ist alles im Beispielcode drin:
http://nl2.php.net/manual/de/functio...ress.php#34556

[MrNiceGuy]

@robo:
Diese Art ist mir bekannt, jedoch denke ich, dass Byrel das ohne PHP gelöst hat, sonst verbraucht er die gesparten Resourcen durch den Parser gleich wieder!?

[robo47]

man kann auch den apache vieleicht dazu anweisen über den mime-typ und die endung das ganze passend rauszusenden, sprich alle anfragen mit dem passenden header zu versehen und anstatt einer x.html die x.gz zu nehmen, denke ich, nur so ne idee.

[MrNiceGuy]

Das funktioniert bestimmt, aber wie ist in dem Falle die Weiche realisiert zwischen jenen, die GZip unterstützen und denen, die es nicht nutzen können?

[robo47]

der apache ist mächtiger als man oftmals denkt

http://httpd.apache.org/docs/1.3/con...gotiation.html

Apache 1.2 supports 'server driven' content negotiation, as defined in the HTTP/1.1 specification. It fully supports the Accept, Accept-Language, Accept-Charset and Accept-Encoding request headers.

damit kommt man z.b. auch an accept-Encoding und kann dem user auf basis dieser header verschiedenes zurückliefern.

[MrNiceGuy]

Zitat von robo47

der apache ist mächtiger als man oftmals denkt

http://httpd.apache.org/docs/1.3/con...gotiation.html

damit kommt man z.b. auch an accept-Encoding und kann dem user auf basis dieser header verschiedenes zurückliefern.

Cool, das habe ich irgendwie immer ignoriert, danke für den Link, werde mir das mal etwas näher anschauen

[robo47]

aber immer vorsicht walten lassen, man kann da auch unschönes machen, ich erlebe auf vielen seiten z.b. oft dass damit über den sprach-header des browsersentschieden wird was der user für ne sprache bekommt und dann wurde vergessen eine möglichkeit zu geben die sprache selbst zu ändern, oder man braucht 2 stunden um diese möglichkeit zu finden, dann ist das ätzend

[Byrel]

Mit benuterdefinierte Seiten meine ich Seiten die bei jedem User anders aussehen also das z.B. der Benutzername angezeigt wird.
Benutzerdefinierte Seiten != Dynamische Seiten

Beispiel: stern.de
Die Startseite verändert sich wenn ein neuer Artikel kommt. Allerdings bleibt ein Artikel immer gleich. Hier z.B. http://stern.de/politik/panorama/:pi...no/579328.html

@MrNiceGuy
Doch. Beim 304 Caching erzeugst du für jeden Benutzer mindestens 1 mal die Seite!

MfG Byrel

[MrNiceGuy]

Zitat von Byrel

Mit benuterdefinierte Seiten meine ich Seiten die bei jedem User anders aussehen also das z.B. der Benutzername angezeigt wird.
Benutzerdefinierte Seiten != Dynamische Seiten

Mir ist schon klar, was du mit benutzerspezifischen Seiten meinst.

Zitat von Byrel

Beispiel: stern.de
Die Startseite verändert sich wenn ein neuer Artikel kommt. Allerdings bleibt ein Artikel immer gleich. Hier z.B. http://stern.de/politik/panorama/:pi...no/579328.html

Das ist soweit richtig, aber ich bezweifle, dass der Stern kein vernünftiges CMS nutzen wird, um die Seiten zu optimieren, denn auch wenn der Artikel sich nicht ändert, ändern sich die Kästen ringsherum. Es kommen Kommentare von Usern dazu, es stehen Wetternachrichten da, manchmal Börsenkurse... Diese Dinge ändern sich stetig. Sicher werden sie eine Art des Cachings verwenden, aber meinst du, dass sie deine Methode verwenden?
Das Problem an der 404er Art des Caching ist und bleibt nunmal, dass dynamische UND benutzerspezifische Seiten Probleme machen.
Das Einsatzgebiet dieser Methode ist leider sehr eingeschränkt.

Zitat von Byrel

@MrNiceGuy
Doch. Beim 304 Caching erzeugst du für jeden Benutzer mindestens 1 mal die Seite!

Ja, das ist richtig, offenbar habe ich diesen Teil nur fehlinterpretiert?!

Zitat von Byrel

Wenn der Browser Seiten nicht zwischenspeichern soll (weil vom User angefordert) wird sogar bei jedem Seitenaufruf generiert.

Klang so, als meintest du, dass die gesamte Seite jedesmal komplett erstellt wird, selbst wenn der 304-Trick genutzt würde.

[WarrenFaith]

Mit benuterdefinierte Seiten meine ich Seiten die bei jedem User anders aussehen also das z.B. der Benutzername angezeigt wird.
Benutzerdefinierte Seiten != Dynamische Seiten

Denk jetzt bitte nochmal genau darüber nach, was du uns hier sagen willst.
User A sieht ne andere Seite als User B... stimmt die seiten sind _nicht_ dynamisch. *kopfkratz*

Dein Beispiel hinkt, denn auch wenn sich ein Artikel nicht ändert, so ist nur die Artikelansicht identisch, die Startseite allerdings ändert sich. Und sei es nur die Stelle an der ein Artikel angezeigt wird bzw wurde, wenn ein neuer dazukommt.

Allerdings fällt mir auf, dass auch der Artikel sich ändert. Dort gibts nämlich eine dynamische Teaserseite, oder denkst du, wenn ich den Artikel in nem halben Jahr wieder auskrame, dass dort immernoch vom Adventskalender gesprochen wird?

Byrel deine Technik ist einfach komisch und ich hege großen Zweifel daran, dass es so wie du machst wirklich performanter sein soll als ein Query abzuschicken. Ich würde mich über abgespeckten Quellcode als Beispiel sehr freuen.