ProcessWire - Performance: Unterschied zwischen den Versionen
| (3 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 5: | Zeile 5: | ||
https://processwire.com/talk/topic/10548-my-way-of-using-wirecache-and-some-hints-to-make-life-easier-with-it/ | 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. | |
| − | |||
| − | |||
| − | |||
| − | + | <syntaxhighlight lang="php"> | |
| − | $ | + | $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); | |
| − | + | } | |
| − | + | </syntaxhighlight> | |
| − | |||
| − | // | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | ==== Beispiel Cache für AJAX, GET, POST umgehen ==== | ||
| + | <syntaxhighlight lang="php"> | ||
if (!count($input->get) && !count($input->post) && !$config->ajax) { | if (!count($input->get) && !count($input->post) && !$config->ajax) { | ||
// cache logic from above | // cache logic from above | ||
Aktuelle Version vom 13. Februar 2020, 16:56 Uhr
Caching[Bearbeiten]
wireCache[Bearbeiten]
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[Bearbeiten]
if (!count($input->get) && !count($input->post) && !$config->ajax) {
// cache logic from above
}
Performante Datenbankabfragen[Bearbeiten]
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[Bearbeiten]
Zeit und RAM[Bearbeiten]
// 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[Bearbeiten]
https://processwire.com/talk/topic/20156-are-there-hidden-scalabilityperformance-issues-when-making-heavy-use-of-repeater-matrix-or-pagetable-fields/
Backend[Bearbeiten]
- 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[Bearbeiten]
- 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[Bearbeiten]
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[Bearbeiten]
https://processwire.com/talk/topic/7459-module-pagetableextended/
Könnte Performancemäßig die bessere Alternative sein. Prüfen und auch mit PageTableExtended verbinden.
