-
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 processing of attributes with Table source_model #38934
Comments
Hi @martin-cod. Thank you for your report.
Join Magento Community Engineering Slack and ask your questions in #github channel. |
Performance workaround for the issue magento/magento2#38934
Hi @engcom-November. Thank you for working on this issue.
|
Hello @martin-cod, Thank you for report and collaboration! Looking at the codebase this issue can be confirmed. |
✅ Jira issue https://jira.corp.adobe.com/browse/AC-13119 is successfully created for this GitHub issue. |
✅ Confirmed by @engcom-November. Thank you for verifying the issue. |
It is worth noticing that even if \Magento\Eav\Model\Entity\Attribute\Source\Table::getAllOptions is cached, the first load is still prolonged and extremely slow since it loads all options that are not even necessary in this case, it is a big performance issue for stores with thousands of options when a specific product has only 2 or 3 options that need to be loaded. the final solution for both issues should be not to load all options anyway. if we are going to filter them afterwards. |
Summary
When working with product collections I found out that getting attribute values is very slow because of using method
\Magento\Eav\Model\Entity\Attribute\Source\Table::getSpecificOptions
. This method is not optimized to work with product collections because it loads data from Database every time attribute value is requested.Taking in mind that
\Magento\Eav\Model\Entity\Attribute\Source\Table
is a default source model for any attribute which has nosource_model
defined ineav_attribute
table it brings a siriouse performance degradation. For example, when working with attribute of textfrontend_input
type it usesgetSpecificOptions()
method which returns empty response every time.To get attribute value there 2 possible loading stacks.
Stack 1. Performance degradation is detected for only attributes of select, multiselect
frontend_input
typeStack 2. Performance degradation is detected for all attribute regardless of
frontend_input
typeExamples
See Summary section with explanations
Proposed solution
Use
\Magento\Eav\Model\Entity\Attribute\Source\Table::getAllOptions
call ingetSpecificOptions
method, so it will minimize the number of SQL queries to 1 per attribute per product collection because option values ingetAllOptions
method are cachedRelease note
No response
Triage and priority
The text was updated successfully, but these errors were encountered: