Performance und Limits

Das Plugin läuft bei jedem Storefront-Seitenaufruf für Produkt-, Kategorie- und Landing-Seiten. Damit die Regelauswertung in einem großen Shop nicht zum limitierenden Faktor wird, bringt es zwei harte Limits mit.

Die zwei Limits

Definiert in Subscriber\PageLoadedSubscriber:

Konstante	Wert	Bedeutung
`LIMIT_PER_REQUEST`	100	Seitengröße beim Abrufen von `p2lab_cms_assigner_cms_page_to_rule`-Zeilen. Das Plugin lädt Kandidatlayouts in Batches von 100.
`LIMIT_TOTAL`	500	Die harte Obergrenze. Das Plugin wertet höchstens 500 Kandidatlayouts pro Request aus, bevor es aufgibt und auf das Basislayout zurückfällt.

Also: wenn Sie 600 Layouts mit angehängten Regeln haben, werden Layouts 501–600 niemals ausgewertet. Der erste Treffer innerhalb der ersten 500 gewinnt.

Reihenfolge: `rule.priority ASC`

Kandidaten werden in rule.priority-aufsteigender Reihenfolge durchlaufen (Shopwares Standard-Regelpriorität). Niedriger Prioritätswert wertet zuerst aus. Nutzen Sie dies, um die wahrscheinlichsten Treffer früh gewinnen zu lassen und im 500er-Cap-Budget zu bleiben.

Wenn Sie insgesamt weniger als 500 regelgebundene Layouts haben, ist die Prioritätsreihenfolge nur als Tiebreaker relevant. Mit mehr wird sie zu einem Korrektheitsthema.

So bleiben Sie schnell

Halten Sie Regelbedingungen günstig. Verkaufskanal, Kundengruppe, Datumsbereich, Ist Startseite, Sprache, Währung — alle O(1). Die zwei Element in Kategorie mit Unterkategorien-Bedingungen machen pro Auswertung eine zusätzliche DB-Abfrage, um den Kategorien-path zu durchlaufen; bevorzugen Sie die einfachere Element in Kategorie, wenn Nachkommens-Matching nicht benötigt wird.
Scopen Sie Regeln auf einen Verkaufskanal. Eine Verkaufskanal-Bedingung kürzt die meisten Regeln früh ab.
Vermeiden Sie es, dieselbe Regel vielen Layouts anzuhängen, wenn ein einzelnes Layout sie tragen könnte. Jedes (cmsPage, rule)-Paar ist eine Zeile; der Matcher läuft sie durch.
Verwenden Sie Prioritäten, um die häufigsten Treffer zuerst auszuwerten.

Was der Matcher pro Request tatsächlich macht

Für jeden relevanten Request:

Eine Repository-Suche nach p2lab_cms_assigner_cms_page_to_rule-Zeilen in Batches von 100, mit den Associations cmsPage und rule.conditions.
Für jeden Batch In-Memory-Regelauswertung pro Layout.
Bei einem Treffer ein zusätzlicher cmsPageLoader->load(...)-Aufruf, um das gewählte Layout mit seiner Slot-Konfiguration aufzulösen.

Das sind drei Kostenkategorien: DB-Lookup, Regelauswertung, CMS-Page-Load. Keine davon wird über Requests hinweg gecached.

Wann besorgt sein

Ein Shop mit dutzenden regelgebundenen Layouts wird das Plugin nicht spüren. Ein Shop mit hunderten sollte auf Prioritäten achten. Wenn Sie sich LIMIT_TOTAL = 500 Kandidatlayouts nähern, machen Sie wahrscheinlich etwas, wofür das Plugin nicht ausgelegt ist — überlegen Sie, ob mehrere Layouts kombiniert werden könnten oder ob Sie wirklich überall regelbasierte Zuweisung brauchen.

Verwandt

Interna des Ersetzungsflusses — die vollständige Schleife.
Fehlerbehebung — wenn ein Layout still nicht erscheint.