Wer einmal in seinem Cache - Ordern bei 0.11.1 nachsieht wird dort eine Datei mit dem Namen contentcache.php finden.
Die wird über die Class.content.inc.php gebildet und genutzt von der function getallcontent.
Da hat Wishy Teufel mit Belzebub ausgetrieben.
Um die Geschwindigkeit zu erhöhen werden tatsächlich ALLE Inhaltsseiten in diese Datei geschrieben und was noch schlimmer ist komplett in den Speicher geladen.
Völlig unnötiger Kram wenn man für den Besucher eine Seite anzeigen lassen will und schlimmer noch - es wird wertvoller Speicher blockiert.
Man hat wohl noch nie etwas von der Möglichkeit von Adodb und CacheExecute gehört.
Über diesen Programmunsinn kann man wirklich nur schimpfen.
contentcache.php Teufel gegen Belzebub
-
Piratos
Re: contentcache.php Teufel gegen Belzebub
Bei genauerer Hinsicht wid der in contentcache.php gespeicherte Inhalt gleich 2 mal in die CMS gebracht - einmal beim Lesevorgang und die Rückgabe an die Funktionsaufrufer ergibt eine Kopie davon.
Den tatsächlichen Inhalt benötigt dabei keine einzige mir bekannte Funktion in dieser Form.
-------------------------------------------------
Abhilfe schafft folgendes:
class.content.inc.php
Ändern von
function GetAllContent($loadprops=true)
auf
function GetAllContent($loadprops=false)
und einmal den Cache löschen.
Damit ist zwar das Problem noch nicht beseitigt, es wird aber erheblich weniger Speicher in Anspruch genommen, da dann die eigentichen Inhalte nicht mehr mit abgelegt werden.
--------------------------------------------------
Die ursprüngliche Absicht von Wishy war es wohl ähnlich wie bei Pimenu ein quasi statisches Menü zu schaffen um die Geschwindigkeit zu erhöhen.
Die Hirarchy - Daten (aber leider auch die Inhaltsdaten) werden in contentcache.php gespeichert . Bei einer Änderung einer Seite wird sie neu erstellt.
Statt nun ein query zu machen um die Informationen zur Hierarchy bzw. alles was eine Navugation ermöglicht , wird diese Datei eingelesen und den anderen Einheiten , insbesondere Menüs zugeführt.
---------------------------------------
Der Nachteil dieser Methode - alles wird im Speicher 2 mal gehalten bzw. verbraucht 2 mal die Menge und das wird knapp.
-------------------------------------------------------------
Das Problem besteht auch darin, dass Wishy sich einfach an seinen Lieferumfang von Adodb hält. Würde er eine kleine 9KB Datei mitliefern, könnte er CacheExecute ausnutzen, dann würde ihm Adodb das alles mehr oder weniger von allein abgenommen haben. Die Zugrifsszeiten reduzieren sich ähnlich drastisch und teils sogar noch besser.
-------------------------------------------------------------
Eine Meisterleistung war das nicht, denn man muss beim Test auch einmal paar Seiten mehr verwenden und sich den Speicherverbrauch anzeigen lassen.
Den tatsächlichen Inhalt benötigt dabei keine einzige mir bekannte Funktion in dieser Form.
-------------------------------------------------
Abhilfe schafft folgendes:
class.content.inc.php
Ändern von
function GetAllContent($loadprops=true)
auf
function GetAllContent($loadprops=false)
und einmal den Cache löschen.
Damit ist zwar das Problem noch nicht beseitigt, es wird aber erheblich weniger Speicher in Anspruch genommen, da dann die eigentichen Inhalte nicht mehr mit abgelegt werden.
--------------------------------------------------
Die ursprüngliche Absicht von Wishy war es wohl ähnlich wie bei Pimenu ein quasi statisches Menü zu schaffen um die Geschwindigkeit zu erhöhen.
Die Hirarchy - Daten (aber leider auch die Inhaltsdaten) werden in contentcache.php gespeichert . Bei einer Änderung einer Seite wird sie neu erstellt.
Statt nun ein query zu machen um die Informationen zur Hierarchy bzw. alles was eine Navugation ermöglicht , wird diese Datei eingelesen und den anderen Einheiten , insbesondere Menüs zugeführt.
---------------------------------------
Der Nachteil dieser Methode - alles wird im Speicher 2 mal gehalten bzw. verbraucht 2 mal die Menge und das wird knapp.
-------------------------------------------------------------
Das Problem besteht auch darin, dass Wishy sich einfach an seinen Lieferumfang von Adodb hält. Würde er eine kleine 9KB Datei mitliefern, könnte er CacheExecute ausnutzen, dann würde ihm Adodb das alles mehr oder weniger von allein abgenommen haben. Die Zugrifsszeiten reduzieren sich ähnlich drastisch und teils sogar noch besser.
-------------------------------------------------------------
Eine Meisterleistung war das nicht, denn man muss beim Test auch einmal paar Seiten mehr verwenden und sich den Speicherverbrauch anzeigen lassen.
-
cyberman
Re: contentcache.php Teufel gegen Belzebub
Besten Dank für den Quick-Tipp und wie immer meine Bitte, dies vielleicht mal mit wishy direkt zu diskutieren. Wie Du weist, ist er ja Deinen Tipps durchaus aufgeschlossenPiratos wrote: Abhilfe schafft folgendes:
class.content.inc.php
Ändern von
function GetAllContent($loadprops=true)
auf
function GetAllContent($loadprops=false)
und einmal den Cache löschen.
.-
Piratos
Re: contentcache.php Teufel gegen Belzebub
Etwas ist da ja schon heraus gekommen (siehe englisches Posting) - aber hier dieser Punkt , der zwar zu etwas mehr Geschwindigkeit führt als vorher, ist und war der übelste Punkt was Speicherverbrauch und Geschwindigkeit in der ganzen CMS.
Ich hatte eigentich gedacht, das Wishy drauf verzichtet die Tabellen content und content_props komplett in den Speicher zu laden, aber genau das macht er jetzt wieder, nur sind die Folgen besser sichtbar.
Bei der reinen Tabellen content kann man das noch verschmerzen aber content_props nicht.
Und was wohl keinem klar ist - jeder Aufuf vom Contentmanager bzw. GetAllContents erzeugt wieder 2 Kopien im Speicher (bredacrumbs oder sitemap genügen da schon völlig).
Und - was wohl einigen nicht klar ist, weil sie Anwender sind - hier reden wir über alle Seiten des gesamten Webs plus den Steuerinformationen betreffend Hierarchy, die werden pro Aufruf dieser Funktion tatsächlich gleich 2 mal geladen, nur um eine einzige Seite anzuzeigen.
Und das sind bei meinem Testvolumen über 3,4 MB rein für nichts !!
Noch ein Nachteil ist der Umstand, dass der Verbrauch völlig ausser Kontrolle gerät, weil der Anwender entscheidet, welche Module oder Plugins er einsetzt und der weiss in der Regel nicht, dass vielleicht ein Module X oder Plugin Y seinen Speicher unnützerweise stark dezimiert.
Der Fehler ist nun bekannt, hoffen wir, dass nun eine Korrektur folgt.
Ich hatte eigentich gedacht, das Wishy drauf verzichtet die Tabellen content und content_props komplett in den Speicher zu laden, aber genau das macht er jetzt wieder, nur sind die Folgen besser sichtbar.
Bei der reinen Tabellen content kann man das noch verschmerzen aber content_props nicht.
Und was wohl keinem klar ist - jeder Aufuf vom Contentmanager bzw. GetAllContents erzeugt wieder 2 Kopien im Speicher (bredacrumbs oder sitemap genügen da schon völlig).
Und - was wohl einigen nicht klar ist, weil sie Anwender sind - hier reden wir über alle Seiten des gesamten Webs plus den Steuerinformationen betreffend Hierarchy, die werden pro Aufruf dieser Funktion tatsächlich gleich 2 mal geladen, nur um eine einzige Seite anzuzeigen.
Und das sind bei meinem Testvolumen über 3,4 MB rein für nichts !!
Noch ein Nachteil ist der Umstand, dass der Verbrauch völlig ausser Kontrolle gerät, weil der Anwender entscheidet, welche Module oder Plugins er einsetzt und der weiss in der Regel nicht, dass vielleicht ein Module X oder Plugin Y seinen Speicher unnützerweise stark dezimiert.
Der Fehler ist nun bekannt, hoffen wir, dass nun eine Korrektur folgt.
