Mailinglisten-Archive |
Hallo Lutz, > Wenn Du den konkreten Zeitpunkt kennst, wo eine Seite sich ändert, > könntest Du ja direkt die eine Seite neu speichern. Das wäre > zielgenauer und zeitnaher. Das habe ich auch schon in etwa vor, z.B. wenn ich einen neuen Artikel für die Website frei schalte. Ob ich dann die Startseite, auf der neue Artikel verlinkt sind, sofort ändere oder jede Stunde schaue, ob sich was geändert hat, und die dann bei Bedarf neu erstelle, werde ich wohl noch auswürfeln oder austesten. > Je weniger dynamisch eine Seite in Bereichen ist, die sich inhaltlich > nicht bei jedem Seitenaufruf ändern, desto besser ist es natürlich. Vor > allem Datenbankzugriffe sollte man zur Laufzeit vermeiden, wenn es > irgend geht. Das versuche ich für die dynamischen Seiten auch über Smarty Caching zu lösen. Aber für die rein statischen Seiten, die nur Gäste und Suchmaschinen zu gesucht bekommen, würden sich IMHO schon rein statische HTML Seiten anbieten. > Auf der anderen Seite steht die Pflegbarkeit der Seiten. Wenn man viele > Seiten hat, auf denen z.B. überall dieselbe Nachrichtenübersicht > eingeblendet wird, ist es in mehrfacher Hinsicht ein unnötiger Aufwand, > alle Seiten neu zu generieren, wenn sich an dieser Übersicht etwas > ändert. Hier ist es also sinnvoll, mit ein wenig Dynamik zu arbeiten, > d.h. per include-Befehl einen statischen HTML-Schnipsel zur Laufzeit > dynamisch einzubinden. Es könnte bei Bedarf eben auch ein dynamische > Code-Schnipsel sein. Wie ich das für die Erstellung der statischen Seiten lösen möchte, habe ich eben schon an Armand kurz beschrieben. > Angewandt auf Deinen Ansatz bedeutet das, daß sowohl Gäste als auch > angemeldete Benutzer dieselben generierten Seiten benutzen können und > somit die Links in der Regel für beide Anwendungsfälle gleich sein > können. Für die Erstellung der dynamischen Seiten, hatte ich mir folgende Vorgehensweise überlegt. Die URI der dynamischen Seiten soll sich nur im Detail von denen der statischen Seiten unterscheiden. Statisch: http://www.domain.de/st/magazin/news/art_123.html Dynamisch: http://www.domain.de/dy/magazin/news/art_123.html Die statischen Seiten liegen wirklich alle in dem Verzeichnis "/st". Die dynamischen Seiten werden über mod_rewrite angesprochen. Wenn ein angemeldeter Benutzer eine Seite aufruft, schaut sich das Skript zuerst die REQUEST_URI an. das "/dy" wird durch "/st" ausgetauscht und das Skript holt sich die statische HTML Seite. In dieser HTML Seite sind die dynamischen Bereiche für den Benutzerstatus durch unsichtbare Kommentare markiert. Beispiel: <html> <head> <title>Artikel 123</title> </head> <body> <!-- start-dynamic:user_status --> <form> Benutzer: <input type="text" name="user"> Passwort: <input type="pass" name="pass"> <input type="submit"> </form> <!-- end-dynamic:user_status --> <br> Hier steht dann die Navi und der Artikeltext<br> </body> </html> Das Skript extrahiert alle dynamischen Bereiche und generiert sie neu. In diesem Beispiel wird geschaut, welcher Benutzer angemeldet ist und ob er eine private Nachricht hat. Die neu generierten Fragmente werden dann ausgetauscht, indem das statische Fragment durch das dynamische Fragment ersetzt wird. Ich muss dann also nur die dynamischen Bereicher erneuern und die Daten für den Artikel und die Navi müssen gar nicht mehr aus der Datenbank gelesen werden. Ich frage mich halt nur, ob das in der Praxis wirklich so Sinn macht. In der Theorie klingt das für mich zumindest toll ;-) > Ich würde das prinzipiell als ein sinnloses Unterfangen bezeichnen. Danke für deine ausführliche Meinung zum Sperren von IP Adressen und Grabbertools. Ich mache dies nun schon seit einigen Jahren so und weiss, dass es keine 100% perfekte Lösung für das Problem gibt. Mir reicht aber eine 70 - 80% Lösung. Ich sperre entweder feste IPs oder IP Bereiche, z.B. indem ich die letzte Zahl ignoriere, d.h. ich verwende die Form 123.123.123.xxx. Das reicht für die meisten der Störer vollkommen aus. Bei den Grabbertools teste ich wirklich nur den User-Agent und dies löst die Probleme eben bei 70 bis 80% alle Nutzer von Grabbertools. Wir hatten einige Zeit das Problem, dass wir von diesen Tools beinahe an die Grenze unseres Frei Traffics gestossen sind. Wenn dann noch ein unvorsichtiger User, der dieses tolle Tool in der neuen Computer Bild entdeckt hat, sein Grabbertool auf unsere Seite ansetzt, werden mal eben in kürzester Zeit 10.000de von Seiten abgerufen. Dies hat dann damals auch öfter mal den Server abgeschossen. Mittlerweile haben wir aber bessere Hardware und mehr Traffic, so dass dies Problem nicht mehr so dramatisch ist. Dennoch gehen fast täglich ein oder zwei Grabbertools in meine primitive Falle. Das reicht mir vollkommen. :-) Viele Grüsse, Ralf
php::bar PHP Wiki - Listenarchive