Skip to content
P2Lab Advanced Layouts Assigner

Performance and limits

The plugin runs on every storefront page load for product, category and landing pages. To stop the rule evaluation from becoming the limiting factor on a large shop, it ships with two hard limits.

The two limits

Section titled “The two limits”

Defined in Subscriber\PageLoadedSubscriber:

ConstantValueMeaning
LIMIT_PER_REQUEST100Page size when fetching p2lab_cms_assigner_cms_page_to_rule rows. The plugin loads candidate layouts in batches of 100.
LIMIT_TOTAL500The hard ceiling. The plugin will evaluate at most 500 candidate layouts per request before giving up and falling back to the base layout.

So: if you have 600 layouts with rules attached, layouts 501–600 will never be evaluated. The first match within the first 500 wins.

Order: rule.priority ASC

Section titled “Order: rule.priority ASC”

Candidates are walked in rule.priority ascending order (Shopware’s standard rule priority). Lower priority value evaluates first. Use this to make the most-likely-to-match rules win quickly and stay within the 500-cap budget.

If you have fewer than 500 rule-bound layouts in total, priority order only matters as a tie-breaker. With more, it becomes a correctness concern.

How to stay fast

Section titled “How to stay fast”
  • Keep rule conditions cheap. Sales Channel, Customer Group, Date Range, Is Homepage, Language, Currency — all O(1). The two Item in category with children conditions do an extra DB lookup per evaluation to walk the category path; prefer the simpler Item in category when descendant matching isn’t needed.
  • Scope rules to a sales channel. A Sales Channel condition short-circuits most rules early.
  • Avoid attaching the same rule to many layouts when one layout could carry it. Each (cmsPage, rule) pair is a row; the matcher walks them.
  • Use priorities to evaluate the most-frequent matches first.

What the matcher actually does per request

Section titled “What the matcher actually does per request”

For each relevant request:

  1. One repository search for p2lab_cms_assigner_cms_page_to_rule rows in batches of 100, with cmsPage and rule.conditions associations.
  2. For each batch, in-memory rule evaluation per layout.
  3. On a match, one additional cmsPageLoader->load(...) call to resolve the picked layout with its slot config.

That’s three categories of cost: DB lookup, rule evaluation, CMS page load. None of them are cached across requests.

When to worry

Section titled “When to worry”

A shop with dozens of rule-bound layouts will not notice the plugin. A shop with hundreds should pay attention to priorities. If you’re approaching LIMIT_TOTAL = 500 candidate layouts, you’re likely doing something the plugin isn’t designed for — consider whether multiple layouts could be combined or whether you really need rule-based assignment everywhere.

Section titled “Related”