Skip to content
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

Open
5 tasks
martin-cod opened this issue Jul 15, 2024 · 6 comments · May be fixed by #39483
Open
5 tasks

Slow processing of attributes with Table source_model #38934

martin-cod opened this issue Jul 15, 2024 · 6 comments · May be fixed by #39483
Assignees
Labels
Area: Catalog Component: Eav Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed Priority: P3 May be fixed according to the position in the backlog. Progress: PR in progress Reported on 2.4.x Indicates original Magento version for the Issue report. Reproduced on 2.4.x The issue has been reproduced on latest 2.4-develop branch Triage: Dev.Experience Issue related to Developer Experience and needs help with Triage to Confirm or Reject it

Comments

@martin-cod
Copy link

martin-cod commented Jul 15, 2024

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 no source_model defined in eav_attribute table it brings a siriouse performance degradation. For example, when working with attribute of text frontend_input type it uses getSpecificOptions() 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 type

1. \Magento\Eav\Model\Entity\Attribute\Frontend\AbstractFrontend::getValue
2. \Magento\Eav\Model\Entity\Attribute\Frontend\AbstractFrontend::getOption
3. \Magento\Eav\Model\Entity\Attribute\Source\Table::getOptionText
4. \Magento\Eav\Model\Entity\Attribute\Source\Table::getSpecificOptions

Stack 2. Performance degradation is detected for all attribute regardless of frontend_input type

1. \Magento\Catalog\Model\Product::getAttributeText
2. \Magento\Eav\Model\Entity\Attribute\Source\Table::getOptionText
3. \Magento\Eav\Model\Entity\Attribute\Source\Table::getSpecificOptions

Examples

See Summary section with explanations

Proposed solution

Use \Magento\Eav\Model\Entity\Attribute\Source\Table::getAllOptions call in getSpecificOptions method, so it will minimize the number of SQL queries to 1 per attribute per product collection because option values in getAllOptions method are cached

public function getSpecificOptions($ids, $withEmpty = true) {
    $allOptions = $this->getAllOptions(false);
    $specificOptions = [];

    if (is_string($ids) && strpos($ids, ',') !== false) {
        $ids = explode(',', $ids);
    }

    if (!is_array($ids)) {
        $ids = (array)$ids;
    }

    if (count($allOptions) > 0) {
        foreach ($allOptions as $option) {
            if (isset($option['value']) && in_array($option['value'], $ids)) {
                $specificOptions[] = $option;
            }
        }
    }

    if ($withEmpty) {
        $specificOptions = $this->addEmptyOption($specificOptions);
    }

    return $specificOptions;
}

Release note

No response

Triage and priority

  • Severity: S0 - Affects critical data or functionality and leaves users without workaround.
  • Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
  • Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
  • Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
  • Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.
@martin-cod martin-cod added the Triage: Dev.Experience Issue related to Developer Experience and needs help with Triage to Confirm or Reject it label Jul 15, 2024
Copy link

m2-assistant bot commented Jul 15, 2024

Hi @martin-cod. Thank you for your report.
To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, Add a comment to the issue:


Join Magento Community Engineering Slack and ask your questions in #github channel.
⚠️ According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.
🕙 You can find the schedule on the Magento Community Calendar page.
📞 The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.

@engcom-Bravo engcom-Bravo added the Reported on 2.4.x Indicates original Magento version for the Issue report. label Jul 15, 2024
martin-cod pushed a commit to hawksearch/esindexing-magento-2 that referenced this issue Jul 15, 2024
@engcom-Hotel engcom-Hotel moved this to Ready for Confirmation in Issue Confirmation and Triage Board Aug 19, 2024
@engcom-November engcom-November self-assigned this Sep 24, 2024
Copy link

m2-assistant bot commented Sep 24, 2024

Hi @engcom-November. 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: 👇

  • 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
  • 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue.
  • 3. Add Area: XXXXX label to the ticket, indicating the functional areas it may be related to.
  • 4. Verify that the issue is reproducible on 2.4-develop branch
    Details- If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced 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.

@engcom-November
Copy link
Contributor

Hello @martin-cod,

Thank you for report and collaboration!

Looking at the codebase this issue can be confirmed.
Hence marking it the same.

@engcom-November engcom-November added Component: Eav Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed Reproduced on 2.4.x The issue has been reproduced on latest 2.4-develop branch Area: Catalog labels Sep 24, 2024
@github-jira-sync-bot
Copy link

✅ Jira issue https://jira.corp.adobe.com/browse/AC-13119 is successfully created for this GitHub issue.

Copy link

m2-assistant bot commented Sep 24, 2024

✅ Confirmed by @engcom-November. Thank you for verifying the issue.
Issue Available: @engcom-November, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.

@engcom-Bravo engcom-Bravo moved this from Ready for Confirmation to Confirmed in Issue Confirmation and Triage Board Sep 24, 2024
@engcom-November engcom-November added the Priority: P3 May be fixed according to the position in the backlog. label Sep 24, 2024
@abdel-aouby
Copy link

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.
issue #38344

the final solution for both issues should be not to load all options anyway. if we are going to filter them afterwards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Catalog Component: Eav Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed Priority: P3 May be fixed according to the position in the backlog. Progress: PR in progress Reported on 2.4.x Indicates original Magento version for the Issue report. Reproduced on 2.4.x The issue has been reproduced on latest 2.4-develop branch Triage: Dev.Experience Issue related to Developer Experience and needs help with Triage to Confirm or Reject it
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants