• Vorträge

    Viele Vorträge, die auf Konferenzen gehalten werden, landen irgendwo im Internet. Wir haben sie für euch zusammengesucht.

    • Statische Seiten in einer dynamischen Welt

    von am 30. Juli 2010

    Klingt ganz schön tiefsinnig, würde ich mal sagen. Fast schon philosophisch, aber leider nur fast, denn eigentlich klingt es hauptsächlich nerdig. Aber da stehe ich zu. Wieder mal den Faden verloren … ach ja, da isser. Wir leben alle in einer dynamischen PHP-Welt. Inhalte werden auf Anfrage generiert und ausgeliefert. Die zeit des langweiligen statischen HTML ist in unserer Zeit fast vergessen. Und darüber sollte man sich vielleicht mal Gedanken machen.

    Natürlich ist es toll, wenn ein Webserver jedes mal das aktuellste Resultat zurückliefert, dass man sich wünschen kann. Wenn man aber jedes mal den Server dabei arbeiten lässt, obwohl sich doch eigentlich nichts geändert hat, klingt das eher unnötig. In vielen Fällen ist es nämlich eine gute Idee seine berechneten HTML-Seiten als statische Dateien hinzulegen und diese auszuliefern.

    Nehmen wir zum Beispiel diese Beitragseite. Jedes mal, wenn einer von euch diese ansurft wird der WordPress-Koloss angeworfen und berechnet jeglichen Schnick-Schnack, um dann doch wieder die gleiche Seite wie vorher auszuliefern. Eigentlich könnte WordPress doch beim Erstellen dieses Artikels eine HTML-Datei erstellen. Diese wird dann in unglaublicher Geschwindigkeit vom Webserver ausgeliefert. Jedes mal wenn ich den Artikel anfasse generiere ich dabei eine neue Version des Artikels. Viele Enterprise-CMS arbeiten übrigens so.

    Natürlich kann man auch viel mit ausgefuchsten Caching-Mechanismen erreichen. Ein Webcache könnte für so einen Blog auch wunder tun. Das Ausliefern von statischen Webseiten sollte aber trotzdem in Betracht gezogen werden, da es doch in vielen Anwendungsgebieten etwas bringen kann.

    Nils Langner

    Auch wenn Ihr es mir nicht glauben werdet, aber ich habe nichts gegen PHP. Ich rege mich einfach nur gerne auf. Ok so schlimm ist es auch nicht. Eigentlich wollte ich schon immer einen Blog haben und da ...

    Zum Profil von Nils Langner

    18 Kommentare »


    • Bastian
      am 30. Juli 2010 um 07:24 Uhr

      mmh, also für mich fällt das Thema auch in die Abteilung Seitencache. Oder Reverse Proxy. Beide tun was dein Anliegen ist :)


    • Michael
      am 30. Juli 2010 um 07:40 Uhr

      macht das Supercacheplugin von WP nicht sowas in der Art?


    • Daniel
      am 30. Juli 2010 um 07:48 Uhr

      Ein Seitencache wird doch häufig eingesetzt. Die Idee ist jetzt also nicht so neu. Und ob nun die “eigene” Software eine statische Seite zwischenspeichert oder ein Proxy ist ja nun auch egal.


    • Roman
      am 30. Juli 2010 um 08:11 Uhr

      @Daniel

      Ich bin mir nicht ganz sicher. Denn wer der Proxy die Seite zwischenspeichert muss das System ja trotzdem noch berechnen, ob sich was an der Seite geändert hat.

      Das ist übrigens auch der größte Aufwand – der sich kaum verhindern lässt, will man immer die aktuellste Seite ausgeben.


    • Daniel
      am 30. Juli 2010 um 08:29 Uhr

      @Roman: Nein, die Seite wird vom Proxy zwischengespeichert und bei einer Änderung aus dem Cache gelöscht.


    • aeckhoff
      am 30. Juli 2010 um 08:34 Uhr

      Ich denke es hat auch viel damit zu tun aus wie vielen Quellen eine Seite zusammengebaut wird. Hängt dies ausschliesslich an 1-2 Stellen im Backend (oder Frontend), so kann man die Generierung der Seite mit einer Änderung an diesen 1-2 Stellen koppeln (z.B. Textänderung des Blogeintrags und neue Kommentare). Wird eine Seite aber dynamisch aus diversen Quellen gespeist, dann kann man kaum nachhalten, welcher Inhalt nun dazu führen soll, dass die Seite neu generiert werden soll (Artikeltext, Kommentare, aggregierte News, aggregierte “ähnliche Inhalte Links”, wechselnde Banner, Anzeige der Navigation, etc…). In diesem Fall wäre eine HTML Generierung (und Ablegen der statischen Seite) vermutlich schwierig machbar und eher an Caching zu denken.


    • ilja
      am 30. Juli 2010 um 09:24 Uhr

      Interessant zu diesem Thema ist auch “ESI” (edge side includes) – eine technologie, die einem Surrogate Server (aka. Reverse Proxie) erlaubt eine (Html-)Seite aus mehreren Komponenten zusammenzustellen (ähnlich wie im Browser die Seite mit Bildern, etc. ausgestattet wird). Hierbei sind dann alle Komponenten Sub-Requests. Jede Komponente (Rahmen, Snippets, …) kann dann beliebig lange Cache-Zeiten haben (auch 0 für volldynamische Reqeusts).

      Allerdings bin ich der Meinung, dass wenn es mindestens einen dynamischen Request gibt (bei dem der PHP-Koloss :) angeworfen werden muss, es sich gar nicht lohnt. Dann kann auch gleich PHP die Seite zusammenstellen).

      Der große Unterschied zwischen (generierten) Statischen Seiten und dynamisch-generierten (gecachten) Seiten ist folgender: Im ersten Fall wird die Seite nur generiert, wenn sich etwas ändert (zB. durch eine Redaktion) – im zweiten Fall ist die Generierung on-Demand, d.h. der erste Requests triggert die Generierung, und es muss bei jedem Request überprüft werden ob sich etwas geändert haben könnte (stale) und wenn die Cache-Zeit abgelaufen ist wir moeglicherweise exakt die gleiche Seite erneut generiert. Und man hat das Problem der “Stampedes” – also N Requests triggern die Generierung simultan – bzw. der erste Request triggert die Generierung und die folgenden bekommen noch ein altes Ergebnis – solnage das neue erstellt wird.


    • butzi
      am 30. Juli 2010 um 11:15 Uhr

      Der von ilja angesprochene Weg ist, denke ich, der der Zukunft. Viele große Webseiten nutzen bereits solche Server-Side-Includes (SSI) und bauen die Seite halbdynamisch zusammen. Extreme (dynamisch/statisch) sind ja nie gut, daher immer auf die Mischung achten. :-)

      Die Auslieferung einem Proxy zu überlassen oder ein eigenes Cachehandling in PHP zu erstellen bewirkt nicht ansatzweise eine gleiche Performance. Egal wie gut man in PHP optimiert, man hat einen riesen Overhead.

      Der Proxy ist meist in C oder C++ geschrieben und nutzt die vom Kernel des Betriebssystems zur Verfügung gestellten Schnittstellen. PHP tut dies schonmal nicht so gut (Filezugriff, RAM-Allocation, …). Einige Proxies halten die Daten komplett im RAM, bei PHP undenkbar, da ein Prozess stirbt sobald er mal fertig ist… Es gibt noch mehr Beispiele und Gründe, warum ein Proxy/Cacheserver Sinn macht. Ist in Form eines Kommentar aber vielleicht übertrieben :-)


    • RCKY
      am 30. Juli 2010 um 12:26 Uhr

      Ach wie schön wäre doch ein permanentes Model in einer VM wie bei Java, das nicht an den Request gebunden ist… :D


    • Sebasitan
      am 30. Juli 2010 um 13:34 Uhr

      Das Problem mit statischen Seiten ist halt nur, dass aus diesen keine Statistiken mehr errechnet werden können. Somit müssen andere Wege gefunden werden, um z. B. Seitenzugriffe zu zählen. Will man also solche Daten erfassen, muss immer zumindest ein Teil dynamisch die Statistik aktualisieren.

      Unabhängig davon kann natürlich die “aufwendige” Generierung des HTML-Codes gecacht werden. Gerne auch in PHP. Bei vielen Zugriffen bringt das defintiv mehr Vorteile als Nachteile. Insbesondere wenn viele Zugriffe parallel stattfinden, kann schon ein kurzer Cache von einer Minute oder weniger, ware Wunder wirken…


    • Flyingmana
      am 30. Juli 2010 um 14:34 Uhr

      Also als reverseproxy gibt es ja Varnish, was wahre Wunder wirken kann selbst bei nem WordPressblog.

      Aber an sich stimmt es schon, Dinge die “relativ” statisch sind sollten auch so dem Webserver zur Verfügung gestellt werden. Denn der sollte in dem Punkt dann immer noch performanter als ein Reverseproxy arbeiten. Ganz davon abgesehen, dass man eine Stelle weniger hat, wo Fehler entstehen können.

      Als Umsetzung von diesem Prinzip gefällt mir der Web Content Viewer web-content-viewer.org
      Allerdings ist der bisher noch alles andere als userfreundlich.

      Aber gerade bei Blogs sollte man mal nachsehen, wieso es nötig ist Dinge dynamisch zu haben.

      Und @Rcky, das ist auch mit PHP möglich, aber wieso willst du nen ganzen Blog mit hunderten Artikeln im Speicher halten, wenn es statisch resourcen schonender ist?^^


    • RCKY
      am 31. Juli 2010 um 13:46 Uhr

      @Flyingmana: sorry für die vielleicht dumme Frage aber wie macht man das denn?


    • CQQL
      am 31. Juli 2010 um 21:54 Uhr

      APC/Memcache/Xcache/etc


    • Juan M.
      am 1. August 2010 um 05:22 Uhr

      Also auf statische seiten zu bauen hat nur dann Sinn, wenn auch sicher gestellt werden kann das sich Daten nicht geändert haben (z.B. eben Artikel).
      Das im Artikel erwähnte verfahren erinnert mich eher an klassischen Frontend-Cache/Seiten-Cache, was hauptsächlich den gesamten Apache und Datenbank entlastet, aber nicht die Festplatte/Speicher.

      Cache macht aus meiner Sicht nur dann sinn, wenn auch wirklich eine Resource einen Flaschenhals darstellt. Bei der heutigen Hardware kann man aktuell PHP eher nicht auslasten (es sei denn man hat sehr ‘unsauber’ programmiert).
      Ich habe derzeit den Flaschenhals bei “SQL-Queries per Second”. Da es an diesen Flaschenhals zwar PHP entlasten könnte (mit Hilfe von Backend-Cache), allerdings der SQL-Server nicht ausgelastet ist, sollte man hier nach “Perfomance-Tuning” suchen.

      Meiner Meinung nach verleitet PHP dazu alles zu können und alles zu tun … viele vergessen aber das hier die eigentliche Ursache dabei nicht behoben wird.

      Cache macht auch zum Beispiel an den Stellen Sinn, wo unnötiger Browser-Server Trafic verhindert werden kann (Bilder, CSS, JS), hoch lebe HTTP 304 ;-)


    • Patrick
      am 7. August 2010 um 22:56 Uhr

      Ich bin atm selbst am überlegen ein (teil)statisches System aufzubauen. Zwar noch nicht aktuell, aber mich reizt der Gedanke daran schon. Denke mal, dass man auch per PHP (trotz aller Nachteile in der Performance) noch einiges an Speed rausholen kann, auch ohne Proxylösungen. Aber, allein schon durch geschickte Programmierung kann man ja schon immens Rechenzeit sparen. WordPress und andre echt CMSe sind ja nicht wirklich bekannt für ihre Sparsamkeit oder solide Programmierung…

      @Sebastian
      Wozu gibts Zählpixel?


    • Arthur
      am 8. März 2011 um 13:21 Uhr

      Ich bin auch auf der Suche nach einem einfachen webbasierten Online-Tool (PHP, Perl), welches aus simplen Text und Templates statische HTML Webseiten generiert.

      Da muss noch nicht mal WYSIWYG drin sein. Eine einfache Wikisyntax würde mir reichen. Wenn man die Templates mal tauschen könnte, dann wäre es nett.

      Dynamische Seiten sind mir einfach zu gefährlich und benötigen unnötig viel Performance. Ein kleiner Fehler auf dem Webserver und schon ist er gehakt.


    • Patrick
      am 8. März 2011 um 22:28 Uhr

      Nur, Arthur, ist auch DAS keine Garantie dafür, dass der Server weniger Unsicher gegenüber Angriffen ist. Da gibts noch andere Methoden, die unabhängig von PHP/MySQL laufen. Und wenn man gut ist, schafft mans auch als PHP-Programmierer die gängigsten Angriffe unwirksam zu machen.

      Eines ist aber sicher. NICHTS ist sicher.


    • Arthur
      am 9. März 2011 um 10:45 Uhr

      @Patrick

      Ich betreue einige Server und Websites seit einigen Jahren. Wir haben noch 2 Webserver mit Ubuntu 6.06 und uraltem Apache. Da sind nur statische html Webseiten drauf. Logwatch und Fail2ban zeigen mir jeden Tag unzählige “Angriffsversuche”. Die Jungs versuchen immer irgendwelche dynamischen Komponenten zu finden. Aber es klappt nicht.

      Dann haben wir noch einen Ubuntu 10.04 WebServer mit WordPress, den ich mit hohem Aufwand ständig aktuell halten muss. Bisher ist da zwar auch noch nichts passiert, aber trotzdem schaut man immer dort mit einem ganz anderen Gefühl in die Logfiles.

      Dann habe ich noch mit unserem Verein eine andere Seite bei einem Hoster. Hier wurde das PHP-Wiki vor kurzem “gehakt”, weil der Admin dort die PHP-Sicherheitsvorgaben nicht ganz so streng einstellen darf. Und das nur weil sonst einige Kundenseiten auf dem Server nicht mehr funktionieren.

      Für diese Vereinsseite suche ich nur ein ganz simples Tool um die Seite bequem zu aktualisieren, aber keine Angst mehr vor Verunstaltungen (Website-Spam) zu haben.

    RSS Feed für Kommentare zu diesem Artikel. TrackBack URL

    Hinterlasse einen Kommentar

    Werbung
    PHP Magazin
    Ausgabe 02/2010

    Dieses Mal mit Artikeln zu den Themen OpenSocial und Apache Shindig, Graphentheorie, Smarty3

    t3n
    Ausgabe 19

    Social Media (R)evolution. Weitere Themen sind noSQL, Crowdsourcing ...

    PHP Journal
    Ausgabe 2/2010

    PHP & Windows optimal nutzen, die besten PHP-CMS im Überblick, Google-API mit Zend Framework nutzen.

    Wir wurden schon öfters gefragt, ob man uns nicht irgendwie unterstützen kann. Die Antwort war immer einfach: Klar! Am einfachsten ist es eure nächsten Einkäufe bei Amazon über unsere Link abzuwickeln. Damit würdet ihr uns schon sehr helfen. Über Co-Autoren freuen wir uns aber noch mehr.