nicht angemeldet
moin,
.. Wenn man natürlich eine Seite hat, die ständig unter Last steht und da surfen im Schnitt hundert und zu Stoßzeiten dreihundert Leute drauf rum, dann ist das sicher nicht praktikabel (bzw. man braucht 'ne echte Wumpe als Server-Hardware und einen Webserver, der Multithreads beherrscht).
Jeder Request ein CGI-Prozess? Meine Optimierung ist die Trennung der Attribute vom Content(Body) wie folgt: Mit dem Request wurden zunächst die Attribute eingelesen und dabei festgestellt, ob es den angeforderten URL überhaupt gibt. Erst dann wird der Body in den RAM gelesen und die Seite ausgeliefert. Wenn es ein CGI-Prozess denn sein muss, den Cache des UA ansprechen mit Last-Modified oder Etag. Ich hab schon viele Seiten gesehen, die hahm sich zwar Mühe gegeben, den QUERY_STRING zu kaschieren, jedoch die Cache Frage (Status 304) total außer acht gelassen.
Am Ende ist es jedoch besser, die Datei liegt physikalisch vor und der Webserver liefert die aus, ohne einen CGI-Prozess zu starten. Fürs Management bedeutet das: Schreibrechte ab DOCUMENT_ROOT, dafür gibt es SuExec.
In beiden Fällen wird bei einer Änderung der Inhalte sowieso ein Update von Last-Modified (oder Etag) fällig, egal ob das beim Request dann der Webserver aus dem Dateidatum ermittelt oder ein CGI-Prozess als Seitenattribut aus einer DB.
Bei Seiten mit 1000 Requests am Tag auf Last-Modified zu verzichten, ist tödlich.
Hotti
Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.