ProcessWire - Performance
Caching
wireCache
https://processwire.com/blog/posts/processwire-core-updates-2.5.28/#wirecache-upgrades https://processwire.com/talk/topic/15286-delete-and-generate-new-markup-cache/ https://processwire.com/talk/topic/10548-my-way-of-using-wirecache-and-some-hints-to-make-life-easier-with-it/
Auf die WireCache Klasse kann mit der $cache variable zugegriffen werden. Die angelegten Caches werden in der PW Datenbank gespeichert. Es gibt diverse Methoden
https://processwire.com/api/ref/wire-cache/
Standard Cachezeit ist 24h
Beispiel - delayed output variable eines Templates cachen. Je nach Seite wird ein neues Cache Objekt angelegt. Wir nutzen ein Prefix (c für cache und content für die Variable $content) und hängen die Page ID an. So kann man den Cache leicht identifizieren.
$cacheId = 'c_content_'.$page->id;
$content = $cache->get($cacheId);
if(!$content) {
include("./partials/layout-blocks.inc");
$content = renderLayoutBlocks($page,$additionalHeaderData); // 2nd passed by reference
$cache->save($cacheId, $content);
}
Beispiel Cache für AJAX, GET, POST umgehen
if (!count($input->get) && !count($input->post) && !$config->ajax) {
// cache logic from above
}
Performante Datenbankabfragen
Mit Modul oder per Hand (pdo) möglich.
https://modules.processwire.com/modules/rock-finder/ https://processwire.com/talk/topic/16346-how-to-transform-page-selectors-into-sql-queries/
my module is a companion module for RockGrid. Those grids always need an array of objects as data source. Using $pages->find() and then foreach() to create such an array is terribly inefficient when dealing with several thousands of pages. That's why I built RockFinder -> it creates an efficient SQL statement for you and it is almost as easy as using regular PW selectors.
The benefit of using SQL is that it is incredibly efficient. The downside is that some pw-related tasks become a headache (like checking for published state, sort order, multilanguage field values, to name just a few). RockFinder takes care of all that.
It returns an array of objects that you can easily pass to a RockGrid or do whatever you want with it.
Performance Testen
Zeit und RAM
// 8000 pages with title and body fields
$pp = $pages('template=basic, parent=1384');
$out = '';
foreach($pp as $p) {
$t = $p->title . microtime();
$b = $p->body . mt_rand(0, 1e5);
$out .= $t . $b;
}
echo strlen($out);
// 18384.08ms, 25.00 MB
// 8000 pages with title and body fields
$pp = $pages('template=basic, parent=1384');
$out = '';
foreach($pp as $p) {
$out .= $p->title . microtime();
$out .= $p->body . mt_rand(0, 1e5);
}
echo strlen($out);
// 17617.05ms, 25.00MB
$out = '';
foreach($pages('template=basic, parent=1384') as $p) {
$out .= $p->title . microtime();
$out .= $p->body . mt_rand(0, 1e5);
}
echo strlen($out);
// 17927.9ms, 25.00MB
Performance und Repeater Matrix
https://processwire.com/talk/topic/20156-are-there-hidden-scalabilityperformance-issues-when-making-heavy-use-of-repeater-matrix-or-pagetable-fields/
Backend
- Repeater Items per AJAX laden
https://processwire.com/blog/posts/more-repeaters-repeater-matrix-and-new-field-rendering/#repeater-upgrades-continued-in-pw-3.0.5
Frontend
- Können viele Datenbank (PDO) Queries auslösen, da alle Page Objekte geladen werden müssen.
Auswahl aus verschiedenen Repeatern über ein Select, statt einzelnes RepeaterMatrix Feld
Evtl. könnte man ein Auswahlfeld generieren, das dann wiederum einen Contentblock wählt, statt alles in ein RepeaterMatrix Feld zu packen.
- Layoutblock -> Select Feld
- Optionen werden geladen.
Alternativ PageTables
https://processwire.com/talk/topic/7459-module-pagetableextended/
Könnte Performancemäßig die bessere Alternative sein. Prüfen und auch mit PageTableExtended verbinden.