-
Notifications
You must be signed in to change notification settings - Fork 9.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slow performance of Products page builder element in the frontend when filtering by category #39577
Comments
Hi @ioweb-gr. Thank you for your report.
Join Magento Community Engineering Slack and ask your questions in #github channel. |
Hi @engcom-Hotel. Thank you for working on this issue.
|
Hello @ioweb-gr, Thanks for the report and collaboration! We have tried to reproduce the issue with the mentioned steps in the latest development branch i.e. 2.4-develop and it seems the issue has been reproducible for us. We have tried to reproduce the issue with almost 10 lakhs product and the query for us us as follows:
The above query took Then we have tried with your suggested query as follows:
which took It clearly shows that there is room for query optimization. Hence confirming the issue. Thanks |
✅ Jira issue https://jira.corp.adobe.com/browse/AC-13843 is successfully created for this GitHub issue. |
✅ Confirmed by @engcom-Hotel. Thank you for verifying the issue. |
The query difference compared to what I see is drastic. In your case it's half the time but in my case it was multiple times slower @engcom-Hotel Could you share the DB configuration you used to see if there's some optimization factor producing this difference? |
And actually using your own query it took for me 100ms
|
I did some playing around and it seems that the more category ids we put in the For example
This one took 100ms for me Whilst if I remove any of the category_ids from those , it takes 7 seconds. @engcom-Hotel would you mind giving it another shot by selecting only 2-3 categories in the |
Hello @ioweb-gr, I have tried it with 3 category IDs and the query took And then tried with 1 category ID and this time query took |
Thank you for confirming performance degradation @engcom-Hotel Let me tell you what I found from my investigation. It seems the amount of products in the categories plays a role but the inverse of what seems logical. Assuming the query only has one category I get different results if that category has less or more products. In particular, the more products it has, the faster the query becomes. I'm experimenting with filtering just on category_id = 794 which I can control the count of products. With 10 products it takes 15 seconds It's definitely the IFNULL condition that's causing this performance degradation but I can't understand why the number of products plays a role. In your case since you had added dozens of categories, the query became fast, even if it was 50% slower than the sample I gave. I tested in both MariaDB 10.6 and MySQL 8 to see if there's a difference in the optimizers. The execution plans appear identical though so it's really vexing. I also have one more observation that I noticed and it's that the query created by the PageBuilder Products element is ignoring the products_count in the widget. If you check the QUERY it has no "LIMIT" clause. In my widget I always limit the products to a sane number like 2 or 5 or 10 But the query is running for all. This could also play a part but a very small one. |
Preconditions and environment
Steps to reproduce
Add with the page builder a "Products" element to the homepage which filters products by category
Go to the frontend and with a profiler check the queries generated
For example in my case this one was generated
This query takes about 9 seconds to run.
If rewritten in a different way like this it runs in 69ms
So basically the way the category filter is used in the where condition is causing a huge delay.
With 2 instances of this type of widget the page takes over 20 seconds to load making it unusable.
Expected result
The products are loaded fast
Actual result
The page becomes unusable when using multiple widgets like this
Additional information
No response
Release note
No response
Triage and priority
The text was updated successfully, but these errors were encountered: