Wydajność i limity

Plugin uruchamia się na każdym wczytaniu strony storefront dla stron produktów, kategorii i stron docelowych. By ewaluacja reguł nie stała się czynnikiem limitującym w dużym sklepie, dostarczany jest z dwoma twardymi limitami.

Dwa limity

Zdefiniowane w Subscriber\PageLoadedSubscriber:

Stała	Wartość	Znaczenie
LIMIT_PER_REQUEST	100	Rozmiar strony przy pobieraniu wierszy p2lab_cms_assigner_cms_page_to_rule. Plugin ładuje kandydackie layouty w batchach po 100.
LIMIT_TOTAL	500	Twarda granica. Plugin będzie ewaluował najwyżej 500 kandydackich layoutów na request, zanim się podda i wróci do bazowego layoutu.

Czyli: jeśli masz 600 layoutów z przypiętymi regułami, layouty 501–600 nigdy nie zostaną zewaluowane. Pierwsze trafienie wśród pierwszych 500 wygrywa.

Kolejność: rule.priority ASC

Kandydaci są przechodzeni w porządku rosnącym rule.priority (standardowy priorytet reguł Shopware). Niższa wartość priorytetu ewaluuje pierwsza. Wykorzystaj to, by najbardziej prawdopodobne do trafienia reguły wygrywały szybko i mieściły się w budżecie cap 500.

Jeśli masz mniej niż 500 layoutów z regułami łącznie, kolejność priorytetu ma znaczenie tylko jako rozstrzygnięcie remisu. Z większą ilością staje się sprawą poprawności.

Jak pozostać szybkim

• Trzymaj warunki reguł tanie. Sales Channel, Customer Group, Date Range, Is Homepage, Language, Currency — wszystkie O(1). Dwa warunki Item in category with children robią dodatkowy DB lookup per ewaluacja by przejść path kategorii; preferuj prostszy Item in category gdy matchowanie potomków nie jest potrzebne.
• Scope’uj reguły do kanału sprzedaży. Warunek Sales Channel krótkozamyka większość reguł wcześnie.
• Unikaj przypinania tej samej reguły do wielu layoutów gdy jeden layout mógłby ją nieść. Każda para (cmsPage, rule) to wiersz; matcher je przechodzi.
• Używaj priorytetów by ewaluować najczęstsze trafienia pierwsze.

Co matcher faktycznie robi per request

Dla każdego istotnego requesta:

1. Jedno wyszukiwanie w repozytorium wierszy p2lab_cms_assigner_cms_page_to_rule w batchach po 100, z asocjacjami cmsPage i rule.conditions.
2. Dla każdego batcha in-memory ewaluacja reguł per layout.
3. Przy trafieniu jedno dodatkowe wywołanie cmsPageLoader->load(...) by rozwiązać wybrany layout z jego konfiguracją slotów.

To trzy kategorie kosztu: DB lookup, ewaluacja reguł, wczytanie strony CMS. Żadna z nich nie jest cache’owana między requestami.

Kiedy się martwić

Sklep z dziesiątkami layoutów z regułami nie odczuje plugina. Sklep z setkami powinien zwracać uwagę na priorytety. Jeśli zbliżasz się do LIMIT_TOTAL = 500 kandydackich layoutów, prawdopodobnie robisz coś, do czego plugin nie został zaprojektowany — rozważ czy wiele layoutów mogłoby zostać połączonych, lub czy naprawdę potrzebujesz wszędzie regułowego przypisywania.

Powiązane

• Wewnętrzności przepływu zastępowania — pełna pętla.
• Rozwiązywanie problemów — gdy layout po cichu się nie pojawia.