concache zum Cachen der Frontendausgabe

xmurrix
Beiträge: 3147
Registriert: Do 21. Okt 2004, 11:08
Wohnort: Augsburg
Kontaktdaten:

concache zum Cachen der Frontendausgabe

Beitrag von xmurrix » Do 29. Jun 2006, 16:37

Hallo Community,

das Caching des Frontends wurde hier schon ein paar mal angesprochen, es gibt auch von einigen Forenusern sehr gute Vorschläge zur Implementierung der Caching-Funktionalität.

Nun, am Besten ist die Steuerung des Caching-Verhaltens direkt bei Modulausgaben, da hier explizit festgelegt werden kann, ob die Ausgabe zum Cachen ist oder nicht. Diese Lösung bedarf aber einer Änderung der Contenido Sourcen, da unter anderem das Verhalten der Funktion "conGenerateCode" geändert werden muss, um dies zu realisieren.

Da ich so wenig Änderungen wie möglich an den Sourcen machen wollte, habe ich das Caching direkt in die "front_content.php" eingepflanzt. Verwendet wird hierbei das Caching von PEAR (genauer die Klasse Cache_Output). Das PEAR Caching bietet eine Funktionalität zum Speichern von dynamischen Ausgaben, also je nach Scriptverhalten.

Die Ausgabe wird als Datei auf dem Dateisystem abgelegt.

Das ganze kann unter http://www.purc.de/upload/contenido/concache0.8.zip heruntergeladen werden.
Neue Version mit Statistik Fix: concache0.9

Vorteile:
- Wenig Änderungen an den Sourcen (nur ein paar Zeilen in front_content.php)
- 50% - 70% Performancegewinn
- Bei Änderungen an Inhalten wird die Ausgabe neu gecached
- Caching ist abhänging von $REQUEST_URL, $_GET und $_POST Variablen, auch $auth möglich

Bekannte Nachteile:
- Es wird die komplette Ausgabe gecached. Ein Problem ist dabei z. B. ein Counter-Modul, da dieser die Seitenaufrufe zählt.
Wird die Seite gecached, gibt es keine korrekte Zählung. Hierbei wäre die Alternative, solche Module, z. B. in die "config.after.php" im Mandantenverzeichnis auszulagern, aber das sollte jeder für sich selber entscheiden.
- Keine explizite Cachingausnahme für bestimmte Artikel.

Configuration des Caching ('cms/includes/concache.php'):

Code: Alles auswählen

// flag zum ausschalten des caching, wenn das script von contenido aus aufgerufen wird, z. b. bei vorschau
$cfgConCache['excludecontenido'] = true;

// flag zum aktivieren des caching. bei true wird caching aktiviert, bei false ist es ausgeschaltet.
$cfgConCache['enable'] = true;

// flag zum erstellen von debug informationen.
$cfgConCache['debug'] = true;

// html template für debug information
$cfgConCache['infotemplate'] = '<div id="debug">%s</div>';

// flag zur ausgabe von weiteren cache informationen als html kommentar
$cfgConCache['htmlcomment'] = true;

// gültigkeit der caches in sekunden
$cfgConCache['lifetime'] = 3600;

// verzeichnis in die die cache-dateien abgelegt werden. wichtig: das script brauch hier schreibrechte.
$cfgConCache['cachedir'] = $cfgClient[$client]['path']['frontend'].'cache/';

// cache gruppe, ist ein unterordner von 'cachedir'
$cfgConCache['cachegroup'] = 'content';

// dateinamen prefix für erstellte cachedateien
$cfgConCache['cacheprefix'] = 'cache_';

// array mit verschienen variablen, von deren wert/inhalt das scriptverhalten abhängig ist.
// per default wird  $REQUEST_URI, $_POST and $_GET verwendet, da diese Variablen im Großen und Ganzen die Modulausgaben beinflussen. 
// es ist auch möglich, das $auth objekt hinzuzufügen, wenn z. B. die ausgabe von authentifizierten usern abhängig ist.
$cfgConCache['idoptions'] = array(
    'uri'  => &$REQUEST_URI, 
    'post' => &$_POST, 
    'get'  => &$_GET
);
Änderungen an der front_content.php:
Zwischen folgenden Zeilen concache inkludieren, cache objekt und instanziieren.
Warum hier? Da wir die $idart und $idcat brauchen und diese vorher ermittelt werden

Code: Alles auswählen

...
$idartlang = getArtLang($idart, $lang);

if ($idartlang === false)
{
	header($errsite);	
}

// START: concache, murat purc
cInclude('frontend', 'includes/concache.php');
$oCacheHandler = new cConCacheHandler($GLOBALS['cfgConCache'], &$db);
$oCacheHandler->start($iStartTime); // $iStartTime ist optional und ist die startzeit des scriptes, z. b. am anfang von fron_content.php
// END: concache

/* If user hast contenido-
   backend rights. */
if ($contenido)
{
...
und vor der Zeile

Code: Alles auswählen

...
// START: concache, murat purc
$oCacheHandler->end();
echo $oCacheHandler->getInfo();
// END: concache

if (file_exists("config.after.php"))
{
	@ include ("config.after.php");
}
...

Installation:
1. Zip herunterladen und entpacken
2. Inhalt von Ordner "Pear/Cache" in den Contenido-PEAR Ordner kopieren, also Contenidoinstallation/Pear
3. Inhalt von Ordner "cms/includes" in den Mandanten-Include Ordner kopieren (cms/includes/)
4. Zeilen in "front_content.php" einfügen.

Möchte noch anmerken, dass es sich hierbei um eine Erweiterung handelt, dessen Einsatz ich eher für erfahrene User empfehle. Außerdem sollte das noch nicht auf einem Produktivauftritt verwendetet werden, da es noch in der Entwicklungsphase ist.
Das Caching Wurde noch nicht unter verschiedenen Konstellationen (OS, PHP/MySQL-Version) getestet, sollte aber kein Problem sein.

Freue mich über Kritik und Anregungen von euch.

Grüße
xmurrix
Zuletzt geändert von xmurrix am Fr 7. Jul 2006, 17:01, insgesamt 1-mal geändert.

HerrB
Beiträge: 6935
Registriert: Do 22. Mai 2003, 12:44
Wohnort: Berlin
Kontaktdaten:

Beitrag von HerrB » Do 29. Jun 2006, 17:07

Der Cache arbeitet IMHO Datei-basiert. In welchem Verzeichnis werden die Dateien gespeichert?

Gruß
HerrB
Bitte keine unaufgeforderten PMs oder E-Mails -> use da Forum!

Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net

stese
Beiträge: 1040
Registriert: Fr 3. Dez 2004, 17:47
Wohnort: München
Kontaktdaten:

Beitrag von stese » Do 29. Jun 2006, 17:09

wird in der config festgelegt:

Code: Alles auswählen

// verzeichnis in die die cache-dateien abgelegt werden. wichtig: das script brauch hier schreibrechte.
$cfgConCache['cachedir'] = $cfgClient[$client]['path']['frontend'].'cache/';

// cache gruppe, ist ein unterordner von 'cachedir'
$cfgConCache['cachegroup'] = 'content';

// dateinamen prefix für erstellte cachedateien
$cfgConCache['cacheprefix'] = 'cache_'; 
klingt auf jeden fall gut - muss ihc bei gelegenheit mal austesten - vor allem der performance gewinn interessiert mich

xmurrix
Beiträge: 3147
Registriert: Do 21. Okt 2004, 11:08
Wohnort: Augsburg
Kontaktdaten:

Beitrag von xmurrix » Do 29. Jun 2006, 17:11

HerrB hat geschrieben:Der Cache arbeitet IMHO Datei-basiert. In welchem Verzeichnis werden die Dateien gespeichert?
Richtig, das Ganze wird im "cache"-Ordner innerhalb des Mandantenverzeichnisses abgelegt.
Dies kann aber über die Konfiguration geändert werden, siehe:

Code: Alles auswählen

$cfgConCache['cachedir'] = $cfgClient[$client]['path']['frontend'].'cache/';
Gruß
xmurrix

HerrB
Beiträge: 6935
Registriert: Do 22. Mai 2003, 12:44
Wohnort: Berlin
Kontaktdaten:

Beitrag von HerrB » Do 29. Jun 2006, 17:12

Call me blind... Den Parameter hatte ich übersehen... :oops:

Gruß
HerrB
Bitte keine unaufgeforderten PMs oder E-Mails -> use da Forum!

Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net

emergence
Beiträge: 10644
Registriert: Mo 28. Jul 2003, 12:49
Wohnort: Austria
Kontaktdaten:

Beitrag von emergence » Di 4. Jul 2006, 15:09

cooles teil ;-)
*** make your own tools (wishlist :: thx)

xmurrix
Beiträge: 3147
Registriert: Do 21. Okt 2004, 11:08
Wohnort: Augsburg
Kontaktdaten:

Beitrag von xmurrix » Di 4. Jul 2006, 15:21

emergence hat geschrieben:cooles teil ;-)
Dankesehr...
Gibt es schon Testergebnisse, in wieweit das Caching mit dynamischem Content harmoniert, also ob die Frontend-Ausgabe auch wirklich korrekt funktioniert?
Theoretisch sollte dies ja kein Problem sein, bei diversen Tests sind mir keine fehlerhaften Ausgaben untergekommen.

Ich kann mir auch eine Modulversion davon vorstellen, vobei es sich dann um 2 Module handelt.
Das erste Modul kann man am Anfang des Templates angeben und das Letzte am Ende. Somit ist dann eine Cachekonfiguration jeder einzelnen Seite möglich.

Gruß
xmurrix

Dodger77
Beiträge: 3626
Registriert: Di 12. Okt 2004, 20:00
Wohnort: Voerde (Niederrhein)
Kontaktdaten:

Beitrag von Dodger77 » Di 4. Jul 2006, 16:12

xmurrix hat geschrieben:Gibt es schon Testergebnisse, in wieweit das Caching mit dynamischem Content harmoniert, also ob die Frontend-Ausgabe auch wirklich korrekt funktioniert?
Theoretisch sollte dies ja kein Problem sein, bei diversen Tests sind mir keine fehlerhaften Ausgaben untergekommen.
Ich habe es gerade mal kurz getestet. Das läuft soweit sehr gut. Der Performancegewinn ist spitze.

Nur lassen sich damit so lustige Sachen wie Zufallsbilder beim Aufruf oder zeit-/datumsabhängige Ausgaben dann nicht mehr umsetzen. Aber da bist du ja schon drauf eingegangen.

emergence
Beiträge: 10644
Registriert: Mo 28. Jul 2003, 12:49
Wohnort: Austria
Kontaktdaten:

Beitrag von emergence » Di 4. Jul 2006, 19:02

xmurrix hat geschrieben:Gibt es schon Testergebnisse, in wieweit das Caching mit dynamischem Content harmoniert, also ob die Frontend-Ausgabe auch wirklich korrekt funktioniert?
ich hab das in einer relativ komplizierten testumgebung getestet...
auch mit formularen usw.. sieht an sich sehr sauber aus...
in meiner testumgebung von 1.2 sekunden auf 0.2 sekunden macht schon was her... ;-)

ich würd halt bei einer seite mit sehr vielen dynamischen elementen die cache zeit runtersetzen...
momentan werden die inhalte ja 60 minuten zwischengespeichert...
im extremfall kann man es ja auf 5-10 minuten runtersetzen...

müsste mich dann mal genauer mit den code auseinander setzten...
nur hab ich da wiedermal das problem -> keine zeit...
*** make your own tools (wishlist :: thx)

stese
Beiträge: 1040
Registriert: Fr 3. Dez 2004, 17:47
Wohnort: München
Kontaktdaten:

Beitrag von stese » Di 4. Jul 2006, 21:12

funktioniert auch super mit modrewrite. läuft bei mir auf polycoder.de und jeder menge custom modulen.

eine klitzekleine änderung habe ich allerdings:

bitte in der concache.php folgende zeile

Code: Alles auswählen

$cfgConCache['idoptions'] = array(
    'uri'  => &$REQUEST_URI,
    'post' => &$_POST,
    'get'  => &$_GET
); 
in

Code: Alles auswählen

$cfgConCache['idoptions'] = array(
    'uri'  => &$_SERVER['REQUEST_URI'], 
    'post' => &$_POST, 
    'get'  => &$_GET
);
abändern, dann ist auch der parameter uri immer korrekt gesetzt ($REQUEST_URI hätte vorher globalisiert werden müssen, war bei mir leer und macht bei modrewrite schon sinn). die erweiterung ist topp.


und noch ein hinweis an alle anderen user: wer zum testen die variable force=1 in [mandant]/config.php gesetzt hat, wird lange auf ein cache file warten ;) nur wenn parameter force=0 ist wird gecached (was auch sinn macht)

silicone
Beiträge: 299
Registriert: Di 15. Mär 2005, 10:33
Kontaktdaten:

Beitrag von silicone » Di 4. Jul 2006, 21:30

Hallo,
beim Versuch, dein Script in eine Contenido 4.6.8.5 auf Strato einzubinden hagelt es leider folgende Fehlermeldungen:

Code: Alles auswählen

Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of [runtime function name](). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. in /mnt/am2/04/991/00000014/htdocs/cms/front_content.php on line 369

Warning: Cannot modify header information - headers already sent by (output started at /mnt/am2/04/991/00000014/htdocs/cms/front_content.php:369) in /mnt/am2/04/991/00000014/htdocs/conlib/session.inc on line 479

Warning: Cannot modify header information - headers already sent by (output started at /mnt/am2/04/991/00000014/htdocs/cms/front_content.php:369) in /mnt/am2/04/991/00000014/htdocs/conlib/session.inc on line 484

Warning: Cannot modify header information - headers already sent by (output started at /mnt/am2/04/991/00000014/htdocs/cms/front_content.php:369) in /mnt/am2/04/991/00000014/htdocs/conlib/session.inc on line 485

Warning: Cannot modify header information - headers already sent by (output started at /mnt/am2/04/991/00000014/htdocs/cms/front_content.php:369) in /mnt/am2/04/991/00000014/htdocs/conlib/session.inc on line 486

Warning: Cannot modify header information - headers already sent by (output started at /mnt/am2/04/991/00000014/htdocs/cms/front_content.php:369) in /mnt/am2/04/991/00000014/htdocs/conlib/session.inc on line 487

Warning: Cannot modify header information - headers already sent by (output started at /mnt/am2/04/991/00000014/htdocs/cms/front_content.php:369) in /mnt/am2/04/991/00000014/htdocs/conlib/session.inc on line 488

Warning: Cannot modify header information - headers already sent by (output started at /mnt/am2/04/991/00000014/htdocs/cms/front_content.php:369) in /mnt/am2/04/991/00000014/htdocs/conlib/session.inc on line 489

Warning: Cannot modify header information - headers already sent by (output started at /mnt/am2/04/991/00000014/htdocs/cms/front_content.php:369) in /mnt/am2/04/991/00000014/htdocs/conlib/session.inc on line 128

Warning: Cannot modify header information - headers already sent by (output started at /mnt/am2/04/991/00000014/htdocs/cms/front_content.php:369) in /mnt/am2/04/991/00000014/htdocs/cms/front_content.php on line 148
Kannst du damit etwas anfangen?

Gruß,
Thomas

EDIT: Ist nicht die Version 4.6.8.5, sondern die 4.6.8.15 aus dem CVS...
Zuletzt geändert von silicone am Di 4. Jul 2006, 21:35, insgesamt 1-mal geändert.

stese
Beiträge: 1040
Registriert: Fr 3. Dez 2004, 17:47
Wohnort: München
Kontaktdaten:

Beitrag von stese » Di 4. Jul 2006, 21:34

bei php5 ist die funktion per default deaktiviert -> provider fragen, ob er es einschaltet. die suche nach Call-time pass-by-reference (wie in deiner fehlermeldung gleich die ersten beiden begriffe) hätten dich auch zur lösung gebracht

silicone
Beiträge: 299
Registriert: Di 15. Mär 2005, 10:33
Kontaktdaten:

Beitrag von silicone » Di 4. Jul 2006, 21:53

Hallo,
hab zwar gesucht, konnte aber nichts damit anfangen. Da der Auftritt bei Strato liegt, kann ich wohl auch nicht auf die "Gnade" des Providers hoffen.

kummer
Beiträge: 2423
Registriert: Do 6. Mai 2004, 09:17
Wohnort: Bern, Schweiz
Kontaktdaten:

Beitrag von kummer » Mi 5. Jul 2006, 07:54

zuerst einmal danke, dass sich jemand um dieses problem gekümmert hat. eine leistungsverbesserung ist ja immer gewünscht. ich habe dazu einfach folgende drei fragen:

(1) ist es möglich, die dauer des cachings zu regulieren? ich nehme ja mal an, dass das caching nicht erkennen kann, dass sich eine ausgabe verändern würde, wenn alle scripts neu ausgeführt würden, da diese ausführung ja nicht mehr vorgenommen wird. es wäre also sinnnvoll, wenn man z.b. einstellen könnte, dass jede seite maximal 24 stunden gecached wird.

(2) dann als zweites: ist es möglich, einzelne seiten (also kombinationen von übergabewerten) vom caching auszuschliessen. ich denke, das wäre z.b. sinnvoll bei rss-feeds und ähnlichem.

(3) wie sieht es eigentlich bei formularen aus? die will man ja im allgemeinen nicht gecached haben.

falls pear das alles nicht bereits vorsieht, müsste man sich vielleicht überlegen, bei der einbindung auf einen get-übergabewert zu prüfen (z.b. disable=true) und nur bei fehlendem übergabewert ein caching vorzunehmen. dann wäre es nämlich möglich, bereits beim aufruf einer seite fest zu legen, dass der besucher 'mit frischer ware' bedient wird.

danke!

gruss,
andreas
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)

stese
Beiträge: 1040
Registriert: Fr 3. Dez 2004, 17:47
Wohnort: München
Kontaktdaten:

Beitrag von stese » Mi 5. Jul 2006, 08:11

@kummer
zu 1) ja ist in der concache.php als setting geregelt.

zu 2.) ist mir bisher nix aufgefallen, aber man könnte dies recht einfach mit mandanten einstellungen bewerkstelligen.

zu 4.) prinzipiell werden seiten mit dem parameter force=1 nicht gecached rausgegeben, wenn ich das korrekt interpretiert habe. sollte also über diesen parameter zu regeln sein ...

Gesperrt