Backend Root category load slow

[sonbui00]

It's very slow to load "Products List Preview and Sorting" section on root category in Admin. This ajax request take about 1-2 minute to load. Link: /admin/mui/index/render/key/___/?namespace=catalogstaging_category_upcoming_grid&isAjax=true /admin/virtualcategory/category_virtual/preview/ajax/1/store/1

As I check, a cycle run on code (check my image) will load all categories one by one and make query.

Preconditions

The site have many categories (500) under the root category and products (20 000)

Magento Version : 2.4.6

ElasticSuite Version : 2.11.1.1

Environment : Developer

Third party modules : No

Steps to reproduce

1. Go to Admin > Category

Expected result

1. It should be faster

Actual result

1. [Screenshot, logs]

[vahonc]

Hello @sonbui00

Do you use virtual categories? How many are in your catalog?

If so, how complex are the rules you use?

Have you tried to test how fast your catalog loads without ElasticSuite?

BR, Vadym

[sonbui00]

@vahonc I've sent wrong request url. The correct request URL: /admin/virtualcategory/category_virtual/preview/ajax/1/store/1 This call to the controller: src/module-elasticsuite-virtual-category/Controller/Adminhtml/Category/Virtual/Preview.php To show on section: "Products List Preview and Sorting"

Do you use virtual categories? Yes. How many are in your catalog? About 1200 total active - 613 virtual If so, how complex are the rules you use? Almost simple rule, like filter brand or list skus Have you tried to test how fast your catalog loads without ElasticSuite? Magento default do not have this function. "Products In Category" section load normally.

It's good when I disabled all virtual category.

[vahonc]

@sonbui00,

Half of your categories are virtual, so yes it could be a reason for loading performance.

You have to keep in mind that when computing category/product association for a high-level category (or the search result page), the engine will build a complex query to assemble all the products belonging to the currently viewed category:

• products belonging to non-virtual children of the current category
• products matching one of any virtual children of the current category

The resulting query could end up being quite complex and adding pressure to the computation mechanism done by Elasticsearch. That’s why, due to the current situation, we strongly recommend not using them for the whole category tree.

That's not the purpose behind virtual categories: they are designed to build ephemeral categories, such as dynamic corners: “special father day”, “actually discounted products”, “new products” and so on.

They are not a tool to automatically attach products to categories but a merchandising mechanism.

Let’s take a common misconception as an example: using some field that will never change to build virtual categories based on that. The most often occurring is the “create virtual categories based on brand”. A brand will never change, a Weber barbecue will always be a Weber: if you want to define brand categories, it should be done either during the import process (with a brand/category mapping), or even earlier into the Product Management system.

Virtual categories are here to help the merchants to create either an ephemeral category or a category based on something that will often change: discount, stock, total number of sales, etc…

And on top of that, since those categories are "virtual", the relationship between them and the products they contain is not materialized in the database, making them unable to be used for promotion rules, sitemap export, etc...

Therefore, try to reduce the number of virtual categories.

BR, Vadym