magento2
magento2 copied to clipboard
Bug on category count (performance issue)
In src/vendor/magento/module-catalog/Model/ResourceModel/Category/Collection.php
Line 330-333 :
$productsCount = isset($categoriesProductsCount[$item->getId()])
? (int)$categoryProductsCount[$item->getId()]
: $this->getProductsCountFromCategoryTable($item, $websiteId);
should be
$productsCount = isset($categoryProductsCount[$item->getId()])
? (int)$categoryProductsCount[$item->getId()]
: $this->getProductsCountFromCategoryTable($item, $websiteId);
( categoriesProductsCount instead of categoryProductsCount )
This is causing performance issue on backend category page especially when having a big amount of categories/products.
Hi @Nuranto. Thank you for your report. To help us process this issue please make sure that you provided the following information:
- Summary of the issue
- Information on your environment
- Steps to reproduce
- Expected and actual results
Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:
@magento give me 2.4-develop instance
- upcoming 2.4.x release
For more details, please, review the Magento Contributor Assistant documentation.
Please, add a comment to assign the issue: @magento I am working on this
- Join Magento Community Engineering Slack and ask your questions in #github channel.
:warning: According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.
:clock10: You can find the schedule on the Magento Community Calendar page.
:telephone_receiver: The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, please join the Community Contributions Triage session to discuss the appropriate ticket.
:movie_camera: You can find the recording of the previous Community Contributions Triage on the Magento Youtube Channel
:pencil2: Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel
Hi @Nuranto, Could you create a PR with suggested changes and add a bit more info on how to reproduce it?
There is nothing to reproduce since it is just a performance issue.
Actually, I did more tests and it seems the table catalog_category_product_index
is used for fetching pairs, but that table seems deprecated, so my first fix proposal doesn't fix performance issue by its own. It's quite difficult to make it work in default store it since there is no index for default store. But I will make a PR for this.
Hi @engcom-Hotel. Thank you for working on this issue. In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:
-
[ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
Details
If the issue has a valid description, the labelIssue: Format is valid
will be added to the issue automatically. Please, edit issue description if needed, until labelIssue: Format is valid
appears. -
[ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add
Issue: Clear Description
label to the issue by yourself. -
[ ] 3. Add
Component: XXXXX
label(s) to the ticket, indicating the components it may be related to. -
[ ] 4. Verify that the issue is reproducible on
2.4-develop
branchDetails
- Add the comment@magento give me 2.4-develop instance
to deploy test instance on Magento infrastructure.
- If the issue is reproducible on2.4-develop
branch, please, add the labelReproduced on 2.4.x
.
- If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here! -
[ ] 5. Add label
Issue: Confirmed
once verification is complete. -
[ ] 6. Make sure that automatic system confirms that report has been added to the backlog.
Hello @Nuranto,
Thanks for the report and collaboration!
We have verified the issue by looking into the codebase and we have found that the variable with the name $categoriesProductsCount
is not defined anywhere in its scope. But we are using isset
method on that, due to this it is not giving any error and simply calling $this->getProductsCountFromCategoryTable($item, $websiteId)
method.
The correct variable name should be $categoryProductsCount
instead of $categoriesProductsCount
. Hence confirming the issue.
Thanks
:white_check_mark: Jira issue https://jira.corp.adobe.com/browse/AC-6568 is successfully created for this GitHub issue.
:white_check_mark: Confirmed by @engcom-Hotel. Thank you for verifying the issue.
Issue Available: @engcom-Hotel, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.
@Nuranto's original analysis here is correct. There was a bug fixed by https://github.com/magento/magento2/pull/35216
However, the actual problem here is not fully corrected by https://github.com/magento/magento2/pull/35216 but #35216 is part of the fix.
@Nuranto goes on to explain here: https://github.com/magento/magento2/pull/35216#issuecomment-1371194515 the actual issue in v2.4.3+ - including current 2.4-develop
).
To be even more clear he was even kind enough to provide a PR here (that was closed): https://github.com/magento/magento2/pull/34111
In essence, for triage, the bug is as follows:
When Magento goes to compute the "edit category" screen for the root category, it loads a list of all of the categories to fulfill the tree UI structure. Importantly, part of the information retrieved for those categories is the number of products in that category.
Currently, because of two separate bugs, this computation is prohibitively expensive and (for me) results in the entire "Edit Categories" UI to be completely unusable.
The bugs are as follows:
- A typo in the code remedied by https://github.com/magento/magento2/pull/35216
- A completely inaccurate table name
catalog_category_product_index
that should becatalog_category_product_index_{WEBSITE_ID}
-catalog_category_product_index
is always empty leading to a net-negative load time because the call is always extraneous.
@Nuranto was kind enough to fix the second one here: https://github.com/magento/magento2/pull/34111 but it looks like it was closed. @sidolov it looks like (as part of the community upvotes, the first PR was merged, however it doesn't actually fix the root issue, so please also focus on this issue AS IF it was as high priority as the now-merged PR).
Additionally, in all likelihood, the original indexer here should be re-worked to use common table expressions as it is now supported in all major versions of db's currently supported by Magento and there is no longer a need for the temporary index table.
Unfortunate for us however, Laminas doesn't support it.
with recursive category_tree (entity_id, parent_id) as (
select entity_id,
parent_id
from catalog_category_entity
where parent_id = 1
union all
select c.entity_id,
c.parent_id
from catalog_category_entity c
inner join category_tree
on c.parent_id = category_tree.entity_id
)
select parent_id as 'category_id', entity_id as 'child_id' from category_tree where parent_id > 1;
Notably, however, that parent_id
should be carefully selected per root catalog that you're trying to show in the admin UI.
For store0
it should 1
For store*
it should be the rootCategory of that store.
@damienwebdev Thank you, I feel less lonely on this one :p
In my case, I ended up removing product counts on that page, we didn't need it after all...
I guess some reviewers did not see the issue correctly because they had their catalog_category_product_index
filled by previous releases where it was still in use... So fixing the typo did fixed a part of the perf issue for them, if their category tree didn't change much since then.
@Nuranto that's a really interesting insight that I had not considered. There's likely a decent number of individuals with older databases where this table was never truncated and, as a result, the data probably looks somewhat correct (although in reality it is completely nonsensical).
Thanks for this realization, it will probably help along the way.
Hi,
internal team started working on this issue.
Thanks.
@engcom-Bravo, would be great if they will just port https://github.com/mage-os/mageos-magento2/pull/25 + https://github.com/mage-os/mageos-magento2/pull/47, so it won't have 2 different implementation between the 2 forks
Hi @Nuranto,
We have checked this issue on magento 2.4-develop and As per the latest codebase and we have found that the variable $categoriesProductsCount name has been changed and the issue no longer reproducible. Hence we are closing this issue.Please find the attached screenshot for your references.
Thanks.
Hi @engcom-Bravo, I double-checked - the change was merged in https://github.com/magento/magento2/pull/35216. The last comments states that it's not fixing the original issue https://github.com/magento/magento2/pull/35216#issuecomment-1625154983 https://github.com/magento/magento2/pull/35216#issuecomment-1371194515 https://github.com/magento/magento2/pull/35216#issuecomment-1625148983.
So the correct fix should be porting changes from https://github.com/mage-os/mageos-magento2/pull/25 + https://github.com/mage-os/mageos-magento2/pull/47.
I think we should re-open this issue
Hi @engcom-Bravo,
I agree with @ihor-sviziev's answer. The typo is fixed, but does not fix the real issue.
@ihor-sviziev Thanks for reopening the issue.
Hi @Nuranto,
Could you please update the description with the steps to reproduce and also Expected result and Actual result it will help us to proceed further.
Thanks.