[Byrel]

[EDIT by Ben]
Diskussion startete hier und kann gerne hier fortgeführt werden.


@Ben

Ich habe keine Benchmarks durchgeführt, aber rein theoretisch ist ein Singleton langsamer, als wenn du Objekte durchreichst.

Bei einem Singleton rufst du jedesmal eine Funktion auf und das ist wesentlich langsamer als wenn du einfach auf eine Variable zugreifst.

Teste das z.B. mal mit PHP_VERSION und phpversion () aus. Du wirst sehen, dass PHP_VERSION schneller ist.

Ich verwende bei kleineren Sachen (und ich habe hauptsächlich kleine Sachen mit vlt. 200 Besucher pro Tag) aber trotzdem Singletons. Allerdings sollte man sich beim Thema Performance zuerst um andere Sachen kümmern (Apache, Dateisystem, Datenbank, Caching mit 404 ...)

MfG Byrel

[MrNiceGuy]

Caching mittels HTTP-Code 404? *scnr*

[Byrel]

Jop

[WarrenFaith]

Erklär mir das mal bitte Byrel. Wie cacht du mittels 404?
404 ist meines Wissens nach das:

10.4.5 404 Not Found

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

Quelle: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

[robo47]

er meinte glaube ich 304 und hat sich vertippt

[Byrel]

@robo47
Ne, ich habe mich nicht vertippt!

Noch nie was vom 404 Trick gehört?

Wenn du eine URL a la www.domain.com/news/1234.html hast, dann wird bei den meisten via .htaccess die id (also 1234) herausgefiltert und auf ein PHP Script weitergeleitet. Deshalb muss bei jedem Request das PHP Script geparst und eine Datenbankabfrage gemacht werden. Man könnte natürlich einen Cache implementieren und damit die Datenbankabfrage oft verhindern, aber das PHP Script muss immer noch geparst werden.

Beim 404-Trick legt man einfach eine .htaccess Datei an, mit dem Inhalt:

PHP-Code:

ErrorDocument 404 /news/generate.php 


Ruft jetzt ein User /news/1234.html auf, so existiert diese Datei nicht . Deshalb wird ein 404 ausgelöst und auf /news/generate.php weitergeleitet. Dieses Script parst jetzt $_SERVER["REQUEST_URI"], holt sich daraus die ID, generiert den Content und speichert ihn unter /news/1234.html ab.

Jetzt liefert der Server nur noch statische HTML Seiten aus und es wird kein eigener PHP Prozess für eine .php Datei gestartet, die nichts anderes tut als den Inhalt aus einer Cache-Datei auszulesen und via echo auszugeben.

Cool oder?

MfG Byrel

[Basti]

Unsinnig, sich den error log vollzuballern. Schau dir mal den Flag -f für RewriteConditions an!

Basti

[Byrel]

Ok, das ist auch eine gute Lösung, aber dann muss man halt mit dem extremen Overhead von mod_rewrite leben und das verkraftet keine große Webseite (und für die ist das ja auch hauptsächlich gedacht). Außerdem ist es meiner Meinung sowieso egal ob da ein 404 oder ein 200 drinnen steht, da ich den log ja eh mit bestimmten Programmen auswerten werde und da kann ich die ja ignorieren.

[Basti]

Zitat von Byrel

Ok, das ist auch eine gute Lösung, aber dann muss man halt mit dem extremen Overhead von mod_rewrite leben und das verkraftet keine große Webseite (und für die ist das ja auch hauptsächlich gedacht).

Gut, da kann ich vielleicht nicht mitreden. Ich hab schon Jahre keine Site mehr ohne mod_rewrite aufgezogen und starte auch grundsätzlich eine Session, ohne vom Benutzer Cookies zu fordern.

Außerdem ist es meiner Meinung sowieso egal ob da ein 404 oder ein 200 drinnen steht, da ich den log ja eh mit bestimmten Programmen auswerten werde und da kann ich die ja ignorieren.

Die Frage ist halt, ob du die Programme (z.B. Webalizer) umschrieben magst und wie du in den Logs echte 404er von gewollten 404ern unterscheidest - musst also die "echten" nochmal in der Anwendung mitloggen. Aber damit sind Webalizer und co. ja wohl gestorben, oder?


Basti

[Byrel]

Gut, da kann ich vielleicht nicht mitreden. Ich hab schon Jahre keine Site mehr ohne mod_rewrite aufgezogen

Solange deine Seite keine Performance Probleme hat, ist es völlig egal. Auch wenn sie welche hat, gibt es sicher noch viele andere zu verbessern.

und starte auch grundsätzlich eine Session, ohne vom Benutzer Cookies zu fordern.

Das versteh ich jetzt nicht ganz. Was hat das mit dem Thema zu tun?

MfG Byrel

[Basti]

...geht ja nicht, die SID weiterzugeben, wenn der Benutzer keine Cookies akzeptiert und einfach nur eine statische Seite ausgespuckt wird.

Basti

[MrNiceGuy]

Also die Methode mittels 404 ein "Caching" zu betreiben finde ich persönlich zwar für ein hübsches Workaround, jedoch ist es keine tolle Lösung. Man muss ja jedes Mal die Datei löschen, wenn sich etwas geändert haben sollte und das fragmentiert auf Dauer einen Webserver wohl sehr stark, gerade bei häufig aufgerufenen Seiten, wo sich viel ändert. Ich denke ein "Caching" mittels 304 ist zum einen deutlich dichter an der Funktionalität und meiner Meinung nach auch viel praktischer. Sicher muss jedes Mal das Script geparsed werden, jedoch ist die Trennung zwischen gecachten und nicht gecachten Seiten viel einfacher.

Geschmackssache, aber alleine schon die Tatsache, dass Log-Auswerter mit der 404er-Variante Probleme machen werden, schließt für mich diese Möglichkeit aus.

PS: Ich dachte halt auch zuerst, du meinst 304er, deswegen auch das *scnr*

[Byrel]

Man muss ja jedes Mal die Datei löschen, wenn sich etwas geändert haben sollte und das fragmentiert auf Dauer einen Webserver wohl sehr stark, gerade bei häufig aufgerufenen Seiten, wo sich viel ändert.

Ansonsten schreibst du halt dein Cachefile in den Ordner /cache/ und löscht es oder du verwendest Sessions die das Dateisystem nutzen. Bei einem Linux Dateisystem wie ReiserFS hält sich die Fragmentierung aber _sehr_ in Grenzen. Ich z.B. schreibe pro DB Eintrag 2 Dateien. Eine Textdatei und eine GZip Datei.

Ich denke ein "Caching" mittels 304 ist zum einen deutlich dichter an der Funktionalität und meiner Meinung nach auch viel praktischer.

Bei dynamischen Seiten kann es zusätzlich, neben z.B. APC verwendet werden. Allerdings ist das browserabhängig und kann auch bei jedem Browser abgestellt bzw. nicht unterstützt werden. Also vertrauen würde ich nicht darauf.

Geschmackssache, aber alleine schon die Tatsache, dass Log-Auswerter mit der 404er-Variante Probleme machen werden, schließt für mich diese Möglichkeit aus.

Trotzdem ist es die weitaus performanteste Lösung. Wenn es ein echter 404 ist, dann schreibst du halt von deinem /news/generate.php ein eigenes Logfile ...

MfG Byrel

[MrNiceGuy]

Ansonsten schreibst du halt dein Cachefile in den Ordner /cache/ und löscht es oder du verwendest Sessions die das Dateisystem nutzen.

Das verstehe ich gerade nicht, wie meinst du das? Gib mal bitte ein Beispiel...

Bei einem Linux Dateisystem wie ReiserFS hält sich die Fragmentierung aber _sehr_ in Grenzen.

Ich kenne die genaue Arbeitsweise von reiserfs leider nicht, aber mir ist nicht bekannt, dass irgendein FS während der Laufzeit automatisch dafür sorgt, dass Dateien defragmentiert werden. Wenn es reiserfs - wie ich jedenfalls vermute - ebenso wie alle anderen FS' dies NICHT tut, so ist die Wahrscheinlichkeit bei einer stark frequentierten Seite mit vielen Seitenänderungen nicht unerheblich, da stetig Dateien gelöscht und wieder neue erstellt werden und diese in der Größe variieren. Das hat dann weniger was mit Linux und reiserfs zu tun, sondern vielmehr damit, dass halt irgendwann die Lücken so oder so aufgefüllt werden müssen oder die Dateien zunehmend verstreut auf der Platte liegen, was den Server im Allgemeinen stark verlangsamen dürfte, Linux hin oder her.

Ich z.B. schreibe pro DB Eintrag 2 Dateien. Eine Textdatei und eine GZip Datei.

Der Sinn entzieht sich mir hier auch ein wenig, kannst dud a bitte auch ein Beispiel zu geben?

[WarrenFaith]

Ich z.B. schreibe pro DB Eintrag 2 Dateien. Eine Textdatei und eine GZip Datei.

?! und dann von performant reden?

[Byrel]

Zitat von MrNiceGuy

Der Sinn entzieht sich mir hier auch ein wenig, kannst dud a bitte auch ein Beispiel zu geben?

Wenn der Client gzip Komprimierung unterstützt sende ich ihm anstelle einer HTML Datei eine GZIP Datei. Die kann er dann selbst dekomprimieren. Das spart um ein paar 100% Bandbreite und eben auch Traffic!

Zitat von Warrenfaith

?! und dann von performant reden?

1. Was hat das Abspeichern von Dateien mit Performance zu tun?
2. Ja. Wie willst du sonst GZip Komprimierung erzielen? Willst bei jedem Request neu komprimieren? Dann ist dein Server sofort tot. Weißt du eigentlich wie viel Rechenleistung das braucht? Bei Yahoo wird GZip komprimierung z.B. komplett ausgeschalten wenn die CPU zu mehr als 90% ausgelastet ist. Persistenter Speicher ist keine Mangelware, CPU Leistung schon!

Ich kenne die genaue Arbeitsweise von reiserfs leider nicht, aber mir ist nicht bekannt, dass irgendein FS während der Laufzeit automatisch dafür sorgt, dass Dateien defragmentiert werden.

Nein die werden nicht zur Laufzeit defragmentiert sondern es werden auch halbvolle Blöcke beschrieben und so mit die Fragmentierung verhindert. Glaub ich zumindest zu wissen.

Wenn es reiserfs - wie ich jedenfalls vermute - ebenso wie alle anderen FS' dies NICHT tut, so ist die Wahrscheinlichkeit bei einer stark frequentierten Seite mit vielen Seitenänderungen nicht unerheblich, da stetig Dateien gelöscht und wieder neue erstellt werden und diese in der Größe variieren.

1. Wie stark eine Seite frequentiert ist, spielt keine Rolle
2. Wenn du einen ganz normalen Dateicache implementierst, löscht du genauso immer wieder die Dateien. Wenn du Änderungen in der DB durchführst, wird ein DB File auch immer größer und kleiner! Nur der "IF-MODIFIED-SINCE-Trick" ist kein Caching. Das wird teilweise vom IE gar nicht unterstützt! Viele Leute haben das auch bewusst deaktiviert!
Außerdem ... Du musst immer einen Query machen der überprüft ob was geändert wurde. Das kannst du dir bei kleinen Sachen aber bei größeren überhaupt nicht leisten! So eine Anwendung wird auch niemals skalieren! Weiters muss für jeden Nutzer min. einmal die gesamte Seite generiert werden. Wenn ich jetzt aber Cache muss ich für alle Nutzer nur einmal generieren! Das Cache-File speichere ich dann auf nem lighthttpd ab und fertig.

Zitat von MrNiceGuy

Das hat dann weniger was mit Linux und reiserfs zu tun, sondern vielmehr damit, dass halt irgendwann die Lücken so oder so aufgefüllt werden müssen oder die Dateien zunehmend verstreut auf der Platte liegen, was den Server im Allgemeinen stark verlangsamen dürfte, Linux hin oder her.

Was heißt dürfte? Du triffst Annahmen. Kannst du es mir beweisen?

MfG Byrel

[WarrenFaith]

Was heißt dürfte? Du triffst Annahmen. Kannst du es mir beweisen?

Rein logisch gesehen: Platte zu 90% voll, schreibst eine 5% Volumendatei dazu und kannst sicher sein, dass die komplett über die Festplatte verteilt ist. Wenn du die jetzt abrufen musst, muss die Platte an tausenden Stellen suchen und kann nicht wie bei einer CD einfach hintereinander lesen.
Kannst ja mal eine fragmentierte CD schreiben und dann davon versuchen einen Film anzuschauen. Dein CDROM wird sich bedanken und dich neben Lärm auch noch mit ner Diashow beglücken.
Ok ein Laufwerklesekopf ist schneller als der Laser beim CDROM, aber das Prinzip ist das gleiche.

Nur der "IF-MODIFIED-SINCE-Trick" ist kein Caching. Das wird teilweise vom IE gar nicht unterstützt! Viele Leute haben das auch bewusst deaktiviert!

Schätze den IE User bzw den Otto Normal User nicht zu technisch ein. Der weiß doch nicht mal was Cache ist... Allerdings ist ja die Frage, was dein Besucherklientel ist. Bild.de-Besucher haben sicherlich nicht viel an den Standardeinstellungen ihres Browsers geändert.

[MrNiceGuy]

Zitat von Byrel

Wenn der Client gzip Komprimierung unterstützt sende ich ihm anstelle einer HTML Datei eine GZIP Datei. Die kann er dann selbst dekomprimieren. Das spart um ein paar 100% Bandbreite und eben auch Traffic!

Die Komprimierung kostet bei der Erstellung viel Rechenzeit und bei einer sich stark verändernden Seite wird sich das wohl eher negativ auswirken, als einen einzigen Query zu starten, grade wenn die Seite selber viel HTML-Code enthält.
Außerdem kann man keine 100% Bandbreite einsparen, denn dann wäre die Seite garnicht mehr besucht. Aber: Wieso schickt dein Browser die Dateien denn bitte so weg? Ich kenne es nur so, dass wenn ich auf eine GZip-Datei linke, dass diese als Download vom Server angeboten wird, nicht jedoch als normale Seite. Der Webserver übernimmt bei mir automatisch die Komprimierung in GZip, sollte dies unterstützt sein. Wie hast du das geregelt?

Zitat von Byrel

1. Was hat das Abspeichern von Dateien mit Performance zu tun?

Wie oben gesagt: Die Berechnungszeit von GZip als Datei dauert im Vergleich zu einem Query ewigkeiten. 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... 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!?

Zitat von Byrel

2. Ja. Wie willst du sonst GZip Komprimierung erzielen? Willst bei jedem Request neu komprimieren? Dann ist dein Server sofort tot. Weißt du eigentlich wie viel Rechenleistung das braucht? Bei Yahoo wird GZip komprimierung z.B. komplett ausgeschalten wenn die CPU zu mehr als 90% ausgelastet ist. Persistenter Speicher ist keine Mangelware, CPU Leistung schon!

GZip direkt im Webserver läuft schneller ab, als das schreiben von GZip-Dateien, aber abgesehen davon lohnt sich eh nur eine minimale GZip-Komprimierung, da sonst das Verhältniss zwischen Rechenzeit und Einsparungen beim Traffic im Allgemeinen viel zu gering ist. Bleibt eh zu spekulieren, ob bei heutigen Kosten für Traffic es überhuapt lohnt GZip zu nutzen, da es a) auch nicht alle an haben und b) Traffic halt auf normalen Servern schon komplett inklusive ist.

Zitat von Byrel

Nein die werden nicht zur Laufzeit defragmentiert sondern es werden auch halbvolle Blöcke beschrieben und so mit die Fragmentierung verhindert. Glaub ich zumindest zu wissen.

Selbst das ist schon eine Fragmentierung und sorgt dafür, dass später deine Dateien wild verteilt liegen.

Zitat von Byrel

1. Wie stark eine Seite frequentiert ist, spielt keine Rolle

Ich rede ja zusätzlich auch von häufigen Änderungen der Seite

Zitat von Byrel

2. Wenn du einen ganz normalen Dateicache implementierst, löscht du genauso immer wieder die Dateien.

Mit dem 304er-"Caching" nicht, da wird der Cache des Browsers genutzt. Die Standardeinstellungen schaffen diese Möglichkeit wie Warren schon sagte und das Groß der Leute im Inet haben dies entsprechend an. Wenn sie es ausschalten, wird die Methode auch automatisch nicht genutzt, da der Browser entsprechend die Anfrage an den Server automatisch ändert (warum sollte der Browser z.B. sagen "Wenn die Seite nicht älter ist als ..., dann schicke sie nicht neu", wenn er selber weiß, dass er keinen Cachen verwendet? )
Bei den Meisten anderen Caching-Methoden stimme ich dir zu und das stand von meiner Seite aus auch nie zur Debatte

Zitat von Byrel

Wenn du Änderungen in der DB durchführst, wird ein DB File auch immer größer und kleiner!

Größer: Ja, Kleiner: Nur wenn man regelmäßig die Tabelle optimiert, ansonsten bleibt der Speicher nämlich erhalten und wird bei späteren INSERTS neu genutzt, was dazu führen kann, dass die Datei weniger fragmentiert ist, als sie es normalerweise wäre. Allerdings kann ich nicht genau sagen, ob ein OPTIMIZE TABLE auch gleichzeitig die Datei defragmentiert, ich befürchte mal nein, aber genau sagen kann ich das auch nicht...
Jedoch: Da du ja auch von einer statischen Seite sprichst, hast du dir gerade ein Eigentor geschossen: Neben der Fragmentierung der DB hast du zusätzlich noch die Fragmentierung durch die Cache-Dateien, was dann zweierlei dein System beansprucht.

Zitat von Byrel

Nur der "IF-MODIFIED-SINCE-Trick" ist kein Caching.

Da lässt sich sicher drüber streiten, aber im Groben ist es sehr wohl ein Caching, nur dass nicht der Speicherplatz auf dem Server genutzt wird, sondern auf dem Rechner des Clients. Ähnlich funktioniert z.B. auch ein Proxy-Server, ist das etwa auch kein Caching?

Zitat von Byrel

Das wird teilweise vom IE gar nicht unterstützt!

Echt? Beispiele? Ich hatte noch keine Version vom IE, die es von Hause aus nicht unterstützte...

Zitat von Byrel

Viele Leute haben das auch bewusst deaktiviert!

Viele mag sein, aber bei Weitem nicht alle. Man sollte nicht die Einfältigkeit der Leute unterschätzen, mal abgesehen davon wüsste ich persönlich nicht, warum ich das Caching von Dateien abschalten sollte, da es aus meiner Sicht egal ist, ob ich die Dateien immer wieder neu aus dem Inet lade oder eben nur dann, wenn sich was geändert hat. Ich glaube auch nicht, dass du mir einen triftigen Grund nennen kannst, warum man das abschalten sollte, die Daten kommen so oder so auf meinen Rechner, ob sie nun abgespeichert werden oder nicht ist da vollkommen hupe.

Zitat von Byrel

Außerdem ... Du musst immer einen Query machen der überprüft ob was geändert wurde. Das kannst du dir bei kleinen Sachen aber bei größeren überhaupt nicht leisten!

Aber du meinst, dass bei sich stetig ändernden Seiten (und damit meine ich nicht nur eine Änderung pro Stunde), der doppelte Festplattenzugriff nicht negativ auswirkt, mal abgesehen von der Weiche, die der Server ja anscheinend benötigt, um GZip-Dateien von den normalen zu trennen?!
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.

Zitat von Byrel

So eine Anwendung wird auch niemals skalieren! Weiters muss für jeden Nutzer min. einmal die gesamte Seite generiert werden. Wenn ich jetzt aber Cache muss ich für alle Nutzer nur einmal generieren! Das Cache-File speichere ich dann auf nem lighthttpd ab und fertig.

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.

Zitat von Byrel

Was heißt dürfte? Du triffst Annahmen. Kannst du es mir beweisen?

MfG Byrel

Siehe den Comment von Warren...

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.