Tach,

ich hab da ein paar Frage zur HTML Seiten Generierung. Mhh mir ist keine bessere Beschreibung für das Problem eingefallen.

Und zwar geht es darum welche Strategie besser ist, einen HTML Code an den Client (Webbrowser) zu übersenden, also von der Performance her.
Das Problem kam auf, da ich für ein Projekt ein Template Manager erstellen soll, der den generierten HTML Code an den Client übergibt.

Es gibt folgende zwei Strategien bis jetzt zur Auswahl:

1.) Der HTML Code wird Stückchen für Stückchen an den Client per echo bzw. print übergeben, sobald ein Teil des HTML Codes fertig generiert ist (sequentiell gesehen). Das Problem ist dabei aber, dass der Aufwand sehr groß wird, was das Programmieren betrifft, wenn man in den Templates selbst solche placeholders hat an denen später etwas einsetzt wird. Wenn das Template einmal mit echo ausgegeben wurde, kann man ja im Nachhinein nichts mehr dazwischen friemeln.
Der Vorteil wäre aber, dass der Browser schon früher mit der Interpretation des Codes anfangen kann.
Nachteil, größerer Aufwand und ich weis nicht ob damit jeder Browser zurrecht kommt bzw. erst mit der Interpretation anfängt, wenn er den kompletten Code bekommen hat. Dann wäre ja das zerstückeln Sinnlos.

2.) Der komplette HTML Code wird auf einem Rutsch über ein echo/print an den Client gesendet. Das hat um einiges geringeren Aufwand vom Programmieren her als die erste Strategie. Der Nachteil ist aber, dass der Browser erst zu arbeiten anfangen kann, wenn dieser echo/print ausgeführt wurde. Und falls man gerade einen genügend langsamen und genügend überlasteten Webserver hat, sitzt der Benutzer eine ganze weile vor einer leeren Seite.

Zudem bin ich mir auch nicht sicher wie schnell ein Webbrowser eine HTML Seite interpretieren und darstellen kann, wenn es viele z.B. DIV's gibt die alle ausgerichtet werden müssen. Nicht dass der Browser dann irgendwann für eine größere Seite mit vielen DIV's schon mehr als eine Sekunde benötigt diese Seite zu interpretieren und darzustellen, falls er sie auf einen Rutsch bekommt.

Natürlich dreht es sich hier nur um minimale Zeitunterschiede, aber diese werden halt umso größer wenn die Verbindung gerade sehr langsam ist.

Vielleicht hat ja jemand von euch schon damit Erfahrung gemacht oder kennt sich mit dieser Materie aus und kann mir einen Tipp geben, welches die bessere Strategie im Verhältnis Aufwand/Nutzen ist.

Dankö.

Mein Japan Tagebuch | Japan Gallerie

Ich wuerde den Client mal vernachlaessigen und die Serverseite betrachten. Wenn du erst alles zwischenspeicherst, muss entsprechend viel Speicher in einem Buffer bereitstehen und das erste Byte wird erst gesendet, sobald die komplette Ausfuehrung fast beendet ist.
Bei der direkten Ausgabe mit echo/print/etc. hat PHP bzw. Apache zumindest die _Moeglichkeit_ das sauber zu handlen: sobald ein kleiner Buffer voll ist, an den Network Stack weitergeben. Ich weiss allerdings nicht, wie die konkreten Implementierungen aussehen, gut möglich, dass PHP sowieso alles buffert.

Angenommen die Serverseite ist nun sauber, hat der Client wiederrum die Möglichkeit zunächst Teile zu verarbeiten, zumindest schonmal den Syntaxbaum aufbauen oder sogar schon Teile rendern.

Ob das nun in der Praxis signifikante Unterschiede macht gilt es zu benchmarken, rechnet man mit 50-100K pro Seite und 10-20 gleichzeitigen Requests, dann sind das vernachlaessigbare 2M Output-Buffer. Im Vergleich zu Apache selbst eher gering. Dafuer hat man die Freiheit zu jeder Zeit den Header modifizieren zu koennen, was oft durchaus sehr angenehm ist.

Danke für die schnelle Antwort. Ja stimmt, der Buffer ist ja auch noch ein wichtiger Aspekt. An so etwas hatte ich gar nicht gedacht.
Ja, dann macht es auf jedenfalls mehr Sinn alles direkt auszugeben um die Datenströme besser regeln zu können.

Dann bin ich mal gespannt was ich da auf die Beine stellen kann.

Mein Japan Tagebuch | Japan Gallerie

Den output komprimieren?

aus them thwboard:
PHP-Quellcode:<?php
function compress_page($output)
{
    global $HTTP_SERVER_VARS, $config;

    if( isset($HTTP_SERVER_VARS['HTTP_ACCEPT_ENCODING']) && strstr($HTTP_SERVER_VARS['HTTP_ACCEPT_ENCODING'], 'gzip')
        && function_exists('gzcompress') && $config['compression'] )
    {
        $output .= '<!-- gzcompress()ed -->';
        
        // http://www.p hp.net/manual/en/function.gzcompress.p hp -- comments
        header('Content-Encoding: gzip');
        $size = strlen($output);
        $crc = crc32($output);
        $output = gzcompress($output, 1);

        print "\x1f\x8b\x08\x00\x00\x00\x00\x00";
        print substr($output, 0, strlen($output) - 4);
        print pack('V', $crc); 
        print pack('V', $size);
    }
    else
    {
        print $output;
    }
}
?>


Setzen, 6 -- am Thema vorbei, Megge.

mwcollect - mein Projekt | oxlog - mein blog | happyhardcore.com Stream - gute Musik

lol, ok :)

Mh ich fand den Beitrag hilfreich. Das hatte ich bis jetzt auch noch nicht gewusst, das soetwas möglich ist.

Mein Japan Tagebuch | Japan Gallerie

Komprimieren ist nur dann sinnvoll, wenn du alle Ausgaben pufferst, und dann kannst du auch einfach den PHP-Puffer-Filter nutzen.

\o tanz den naziprau! o/

And more than ever, I hope to never fall,
Where enough is not the same it was before

unerheblich ob du das erst bufferst und dann schreibst, oder zeilenweise echost, weil tcp das alles abfängt, http://de.wikipedia.org/wiki/Nagle-Algorithmus

Du musst Deine Bandbreite verbreitern, damit du breiter wirst von der Bandbreite her und ein breiteres Publikum ansprechen kannst.

TCP fängt das nicht immer ab, wenn man den Buffer flusht kommt das in den meisten Fällen beim Client an, Garantie hat man dafür natürlich keine.

Ich verwende das ganze selbst bei einem System, dass die Visits von > 10k Domains trackt, und anhand verschiedener Kriterien jeweils anderen Content ausliefert.

Dabei muss einiges geloggt werden, und weil das seine Zeit dauert, liefere ich den generierten Content so schnell wie möglich per Flush aus, und logge danach.

Der User bekommt dadurch den Inhalt zu sehen, und merkt nichts davon, dass das Skript am Server im Grunde noch ein paar ms weiterläuft.

Sollte der Flush einmal nicht klappen, weil auf tieferen Schichten noch irgendwo gebuffert wird, ist das auch kein Beinbruch.
Also ganz praktisch, solange es optional ist.

Rambo Engineer @ Drippy's 2fort - finest TFC 1.5 || Bild Upload || The world's most advanced open source database

Erstmal haben TCP-Pakete gewöhnlich eine Größe von 1.5kib - liegen also gewöhnlich schon gut unter der Größe einer Website (und es wird nur bis zur Paketgröße in TCP gebuffert).

Zum Thema:
Dein Code besteht nicht nur aus dem Aspekt Performance, sondern heutzutage schon fast zu einem größeren Teil aus dem Aspekt Wartbarkeit. Es geht hier um minimale Performanceunterschiede, aber gigantische Unterschiede beim Thema Wartbarkeit, Lesbarkeit und Übersichtlichkeit des Codes. Damit sollte die Entscheidung eigentlich klar sein.
Also: So lange es sich nicht um einen Sonderfall handelt (wie von K-Putt beschrieben, oder sonstige Scripts, die nicht nur der Ausgabe dienen (wie 99% aller php-scripts) sondern auch größere Berechnungen anstellen), lieber sauberes Templatesystem verwenden und am Schluss ausgeben.

Zur komprimierung:
Da muss nix rumgecodet werden - einfach ein Quellcode:php_flag zlib.output_compression On in die .htaccess und die Sache ist gegessen.

"tsuji-giri" (japanisch) - ein neues Schwert an einem Passanten ausprobieren