Konzept: Speichern von geparsten Beiträgen

Hallo,

Hallo!
Bei Gérome's Lösung handelt es sich um eine individiuelle Lösung speziell auf seinen Server angepasst deswegen hat er sich wohl keine Gedanken darum gemacht was passiert, wenn zlib nicht vorhanden ist.

Da diese Optimierungsschritte eigentlich erst bei grösseren Foren Sinn machen kann man zlib auch als 'vorhanden' ansehen da diese Foren meist auf Servern laufen wo man es ohne Probleme aktivieren/installieren/kompilieren/sonstwielieren kann

Hallo,

sorry, dass ich ich hier nicht zu Wort geäußert habe. Hier gingen in den vergangdenen Tagen einige Dinge drunter und drüber.

Man kann sich die Komprimierung auch sparen - jedoch fält sie hinsichtlich der Laufzeit nicht ins Gewicht. Wider Erwarten, möchte ich hinzufügen - aber ich habe es mehrfach getestet. Die Datenbank freut's, sie wird dadurch kleiner, da sich HTML meist recht gut komprimieren lässt. Man kann das 'Spiel' natürlich beliebig weit treiben und einen Konfig-Schalter für die Komprimierung einbauen.

Grüße,
Gérome

Sollte das komprimieren wirklich ins Gewicht fallen könnte man den Konfig-Schalter ja mit dem Serverload koppeln

Lass mich überlegen... Im Moment erscheint mir das kaum sinnvoll. Der Text wird ja nur einmal komprimiert. Und zwar nach dem Erstellen bzw. nach dem Editieren. Wenn das phpBB einen Beitrag in den Suchindex fummelt ... sorry ... einpflegt ... entsteht dabei eine Last, die die Last des Komprimierens um Größenordnungen übertrifft.

Bleibt also das Dekomprimieren und um das kommt man nicht umhin, wenn der Beitrag erstmal komprimiert in der DB steht.

Aber ich will jetzt auch nicht als bedingungsloser Verfechter der Komprimierung dastehen. *g* Kann ja jeder machen, wie er mag. ;-)


Grüße,
Gérome

irgendwie die richtige Parsetree Technik wurde anscheinend bei allen Foren noch nicht gefunden!

revolutionär wäre ja mal wenn die Forensoft die fertig geparsten Beiträge normal abspeichert und nur beim editieren wieder rückwärts von HTML in Boardtagsprache umwandelt!!!

wäre eigentlich mal ein sinnvolles, machbares aber nicht einfaches Projekt! - wer ist dabei?

Rapidforum.

Inklusive all jener dabei entstehender Probleme. Kurz um: Vergiss es.

Hallo,
@Luki: Ein weiteres Problem wäre, wenn man etwas an den BBCodes, Template für Zitate o.ä. ändert.
Beim phpBB3 müsste man nur den Cache leeren, bei dir müsste man dann alle Beiträge zurück in BBCodes übersetzen, und neu parsen.
Und bei 1 Mio. Beiträge kann das dauern....

Dann löscht man halt einfach den Cache und baut noch zusätzlich ein, dass falls ein Benutzer sich einen Beitrag anguckt, der noch nicht im Cache vorhanden ist, eben geparsed wird und dann im Cache gespeichert wird.

..so erledigt sich das Problem von allein

Aber kosten die Abfrage (ist der Beitrag schon im Cache) nicht auch Zeit? Ist ja jedesmal ne Datenbankabfrage..
Und bei 1.000.000 Beiträgen ein array mit den Beiträgen zu erstellen die nicht im Cache sind ist unmöglich

Aber.. Warum eigentlich nicht nur die Beiträge im Cache lassen deren letzte Aktivität > 30 Tage (?) zurück liegt?

Hallo,
hmm so extrem Rechenintensiv ist es auch nicht:
<?php
$erg = mysql_query("SELECT postid, beitrag FROM cache WHERE threadid = '$threadid'");
//postid und beitrag in einem Array speichern


//postdb Abfragen. Wenn postid im Cache Array vorhanden, beitrag ausgeben. Sonst parsen.
?>

Ist im Grunde nur 1 DB-Abfrage pro Thread mehr.

Man könnte es auch Threadweise machen.
In der ThreadDb steht, ob dieser Thread im Cache sich befindet.

Wenn ja:
SELECT * FROM cache WHERE threadid = '$threadid'

Wenn nein:
SELECT * FROM postdb WHERE threadid = '$threadid'

Man müsste aber sicher stellen, dass im Cache sich dann alle Beiträge des Threads befinden.

Eigentlich braucht man im Idealfall sogar nur eine Abfrage, wenn man ein JOIN verwendet.

Anschließend guckt man, ob die Variable "postparsed" gesetzt ist, wenn nicht, dann fügt man den geparsten Post per INSERT in die Cache-Tabelle ein, nachdem er geparst wurde.

So einfach geht das, gell? Das war jedenfalls auch mein Plan.