Also der Vortrag von dem eZ Publish Partner Kaliop Interactive Media aus Frankreich war echt der Hammer. Dies bestätigten mir auch weitere Entwickler. Hier wurden richtiggehend Geheimnisse veröffentlicht, die bisher fast keiner kannte. Für mich war es DAS Highlight des gesamten eZ Summer Camps.

 

 

 

 

Das Team kam gleich mit vier Skippern (Speakers) an.

  • Gilles Guirand – CTO und eZ Publish board member
  • Gilles Ballini – Lead engineer
  • Stephane Sobecki – Lead engineer
  • Jerome Lecocq – Lead engineer

Der Aufbau des Vortrags war einfach Klasse. Hierbei wurde auch erklärt, wie der Cache in eZ Publish erstellt wird.
Vorab die Frage: Für was braucht man den Cache?

Die benötigen CPU- und RAM-Ressourcen auf dem Server werden mit Hilfe des Chaches stark reduziert, ebenso werden die Templates in PHP Files umgewandelt und im Dateisystem abgelegt.

#site.ini
[TemplateSettings]
TemplateCompile=enabled
NodeTreeCaching=enabled #ist per default disabled

Die Einstellung NodeTreeCaching bewirkt eine deutliche Steigerung der Geschwindigkeit.

Wie berechnet eZ den Hash der Dateien?

Md5( filepath ) / internalCharset / language / useFullUrlText / accessText / pageLayoutVariable / indexFile / extraName

Diese Dateien werden unter /var/cache/template/complied/ abgelegt.

Precompile von Templates

Wenn man nun neue Entwicklungen oder Änderungen live stellt, hat man immer das Problem, dass der erste Nutzer auf der Seite längere Ladezeiten benötigt, da zu diesem Zeitpunkt die jeweilig aufgerufene Seite neu gecacht wird. Es gibt aber einen Trick, mit dem man dies schon im Vorhinein genieren kann.

Gehen wir mal von der Tatsache aus, dass wir das pagelayout.tpl und das page_head.tpl angepasst haben.

php bin/php/eztc.php -s mysiteaccess --force YOURPATH/templates/page_head.tpl
YOURPATH/templates/pagelayout.tpl

oder wir wollen einfach alle page_* Templates genieren.

find YOURPATH/ -name "page_*.tpl" | xargs php bin/php/eztc.php -s YOURSITEACCESS --force

Damit werden nur die Templates neu kompiliert. Natürlich muss man hier etwas aufpassen. Wenn man im page_head.tpl was geändert hat, dann muss man auch das Template darüber neu kompilieren.

Share Templates

Das war mir – wie viele andere Punkte – ganz neu. Soweit ich das jetzt in Erfahrung gebracht habe, wird diese Einstellung die man in der site.ini vornimmt für eZ Installationen mit verschiedenen Domains und gleichen Sprachen verwendet. Dabei werden die jeweiligen Templates immer pro Sprache kompliert, nicht pro Siteaccess. Doch sollte man auch diese Einstellung ein wenig mit Vorsicht genießen.

Aufbau des Hashs bei Share Templates

Md5( filepath ) / language

Die Einstellung in der site.ini

[TemplateSettings]
ShareCompiledTemplates=enabled #(per default disabled)

Share Templates können nicht vorkompiliert werden.

Der INI Cache

Wann wird der INI Cache erstellt?

On the fly, natürlich nur wenn der jeweilige Cache nicht existiert. Über eine etwas versteckte Einstellung in der config.php kann man dies etwas anpassen.

define( 'EZP_INI_FILEMTIME_CHECK', true ) ;

Eine Aktivierung kann zu Einbußen bei der Geschwindigkeit führen, I/O.

Wie leere ich den INI Cache?

1) leert das Verzeichnis var/cache/ini

php bin/php/ezcache.php --clear-id=global_ini

2) leert das Verzeichnis var/cache/ini und var/cache/active_extensions_{hash}.php

php bin/php/ezcache.php --clear-tag=ini

Es gibt noch die Möglichkeit, die INI Werte nicht zu kompilieren. Dazu muss in der site.ini die unten stehende Einstellung vorgenommen werden. Die Werte werden dann beim Aufruf dynamisch aufgerufen. (bitte mit Vorsicht nutzen)

[eZINISettings]
DynamicTemplateMode=enabled #default disabled

Über den Operator ezINI kann man dies auch beim Operator mitgeben, dann trifft diese Einstellung nicht überall zu. (Bitte für Details in der Core Doku nachlesen.)

VIEWCACHE

Wer noch nie was vom ViewCache gehört hat: Unbedingt aktivieren!

[ContentSettings] 
ViewCaching=enabled

Eine interessante Einstellung zum Thema ViewCache befindet sich ebenfalls in der site.ini: Beim Veröffentlichen eines Artikels kann man ein PreCompile anstossen. Natürlich würde dies die Veröffentlichungszeit eines Artikels etwas beeinträchtigen, auf der anderen Seite ist jedoch der erste Aufruf auf der Seite schneller. Es gilt also abzuwägen, was im jeweiligen Projekt wichtiger ist.

#site.ini.append.php: 
[ContentSettings] 
PreViewCache=enabled

Zur Erklärung: Im Viewcache befindet sich alles, was sich im full.tpl oder unter content/view befindet. (module_result.content)

Zum Beispiel: Es werden auch Cache Files für Offset Aufrufe erstellt mydomain.com/site/(page)/2

So, jetzt wird es spannend! Als ich das gehört habe, flutschten mir fast die Augen raus. (Bitte nicht wörtlich nehmen 😉 )

Wann wird der Viewcache geleert?

1) Wenn ein Redakteur den (bestehenden) Artikel veröffentlicht.
2) Wenn man im Backend in der Mitte oben links auf das große Icon klickt und folgenden Punkt auswählt.

Bei „Ansichtscache leeren“ wird nur der Cache von dem einem Knoten (Artikel) geleert. Beim Punkt „Ansichtscache von hier leeren“ auswählt werden alle Artikel darunter neu erstellt.

Ok, das selbe Spiel kann man auch über die Shell machen.

php bin/php/ezcontentcache.php –clear-node=2

So, falls du nun schon mehr mit eZ Publish gemacht hast, ist das noch immer nichts bahnbrechend Neues für dich. Aber jetzt – jetzt kommt’s 🙂

Man kann auch mehrere Knoten angeben mit

php bin/php/ezcontentcache.php –clear-node=2,38,28

Alles klar, das war noch immer keine Zauberei – aber den folgenden Befehl kanntest du sicherlich noch nicht.

php bin/php/ezcontentcache.php –clear-node=/company/about

Man kann auch die gesamte URL angegeben und mit -clear-subtree leert er den Cache der darunter liegenden Punkte.

php bin/php/ezcontentcache.php –clear-subtree=/company/about

Und auch hier kann man mehrere Punkte mitgeben.

php bin/php/ezcontentcache.php –clear-subtree=/company/about,/news

Zur Info: Mit dieser Information ist sind die vier Jungs von Kaliop erst auf der 28 Folie heraus gerückt 🙂

Cache Event

Schon mal was von einem Event Listener gehört?

[Event]
Listeners[]=content/cache@log::logviewcache

# log = deine PHP class name
# logviewcache = die Statische Methode

Ein Beispiel für so eine Klasse wäre

<?php

class log
{   
    
     static public function logviewcache( $nodeList )
    {
		$uri = $GLOBALS['_SERVER']['REQUEST_URI'];
		eZLog::write('node_id count : '. count( $nodeList ). ' / node_id list : ' . implode(', ', $nodeList ) . ' / URI : '.$uri, 'cachethresold.log');

		return $nodeList;
    }
}
?>

Wichtig ist hier unbedingt die Autoloads neu zu generieren!

Cache-Block

Also Cache-Blöcke sind manchmal eine eigene Wissenschaft, das habe ich früh erkannt. Doch sie sind unbedingt notwendig und sollten in der Regel im Entwicklungsprozess berücksichtigt werden und nicht erst kurz vorm Online stellen. Mit Cache-Blöcken verringert man die Datenbankzugriffe und die Ladezeit.

Wenn möglich, setze immer die Ablaufzeit.

{cache-block expiry=86400}

{/cache-block}

Die Zahl 86400 ist ein Timestamp -> nach einem Tag den Cache-Block neu erstellen.

Die oft genutzte Einstellung „subtree_expiry“ kann ausser NodeIDs noch mehr.

{cache-block subtree_expiry='event/'}

{/cache-block}

{cache-block subtree_expiry=1912}

{/cache-block}

Man kann auch die URL angeben, würde ich persönlich aber nur ungern machen.

Cache-Blöcke können natürlich auch verschachtelt aufgebaut werden, dies jedoch bitte mit Vorsicht nutzen.

Wenn man in seinem Projekt nun „Echtzeit Anzeigen“ braucht, dann lautet das Motto ganz eindeutig – VERGISS den Cache-Block!

Hier hilft nur entweder ESI (Edge Side Include) – benötigt natürlich einen Proxy (Varnish, Akamai etc.) – oder einfach AJAX (dies kann leicht über eZ JSCore durchgeführt werden).

Man kann auch alle Cache-Blöcke im Cache leeren.

php bin/php/ezcache.php –clear-id=template-block

Wenn man jetzt einen spezifischen Cache-Block löschen möchte, muss man schon etwas tricksen.

find var/SITEACCESS/cache/template-block/ -name "*.cache" -exec grep -iHl "string-to-search" {} \; -delete

„string-to-search“ ist jetzt kein Befehl sondern dieser Text ist der Inhalt im Cache-Block.

Oder man setzt eine ID im Cacheblock – das wusste ich zum Beispiel auch nicht.

{cache-block id=MYSUPERBLOCK ignore_content_expiry expiry=0}

{/cache-block}

Dann sucht man unter var/cache/template-block/ nach MYSUPERBLOCK…./…/…. .cache und löscht das File.

Expire.php

Dieses File sollte sich unter var/cache befinden. Dort findet man alle Timestamps für die nächste Entfernung der Cache-Dateien.

eZ Cache leeren

php bin/php/ezcache.php --clear-id=[ID]
php bin/php/ezcache.php --clear-id=[ID] --purge
php bin/php/ezcache.php --clear-tag=[TAG]
php bin/php/ezcache.php --clear-tag=[TAG] --purge
php bin/php/ezcache.php --clear-all
php bin/php/ezcache.php --clear-all --purge

# Hilfe
php bin/php/ezcache.php --help
php bin/php/ezcache.php --list-ids
php bin/php/ezcache.php --list-tags

So ich hoffe ich habe nichts vergessen 🙂 Es war ein rundum interessanter Vortrag mit lauter spannenden, neuen Erkenntnissen.

https://blog.silversolutions.de/wp-content/uploads/2018/12/tools-tipps_dummy.pnghttps://blog.silversolutions.de/wp-content/uploads/2018/12/tools-tipps_dummy-150x150.pngDavid HohlB2B.technologieEntwicklung,Events,Tipps & TricksAlso der Vortrag von dem eZ Publish Partner Kaliop Interactive Media aus Frankreich war echt der Hammer. Dies bestätigten mir auch weitere Entwickler. Hier wurden richtiggehend Geheimnisse veröffentlicht, die bisher fast keiner kannte. Für mich war es DAS Highlight des gesamten eZ Summer Camps.         Das Team kam gleich mit vier...Die e-Commerce B2B Experten bloggen über Händler-Shops, ERP, PIM und das integrierte CMS eZ Publish