-
Notifications
You must be signed in to change notification settings - Fork 9.4k
Cache the results of isCacheable calls to improve performance #40112
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
base: 2.4-develop
Are you sure you want to change the base?
Conversation
This function call is relatively expensive when $elements has the full layout in it. Especially the PageCache module is calling this function a lot from the following places: - Magento\PageCache\Model\Layout\LayoutPlugin - Magento\PageCache\Observer\ProcessLayoutRenderElement On my local machine I've seen the impact to be anywhere between 20-40 milliseconds, when the page has been loaded a few times to warm up cache (config, block, layout, etc...), but FPC is circumvented. We could also opt to move this to the PageCache module, but I think it is ok to optimize this within the Layout class within the framework.
Hi @igorwulff. Thank you for your contribution!
Allowed build names are:
You can find more information about the builds here For more details, review the Code Contributions documentation. |
@magento run all tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✅ The change looks good to me.
The method you're improving, originally did not look like a good example of code, however.
I was considering whether ?bool
wouldn't be better than bool|null
but there's no functional difference. I'm personally more towards ?bool
if ($blockName !== false && $this->structure->hasElement($blockName)) { | ||
$cacheable = false; | ||
break; | ||
if (!isset($this->isCacheableCache)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not using use comparator here? $this->isCacheableCache === null
We are sure that isCacheableCache property exists, so we can avoid this check
Just tried this patch and when you have all caches enabled, it will broke my customer account pages and checkout pages, since it won't be able to properly fetch the customer's ID. Could also be my installation, but reverting this patch did solve the issues. |
@magento create issue |
✔️ QA PassedSteps to reproduce
Many Functional CE, B2B, EE tests are failing because of the PR changes. eg. https://public-results-storage-prod.magento-testing-service.engineering/reports/magento/magento2/pull/40112/72848e021a98a44835eeff89b84c343b/Functional/allure-report-ce/index.html#categories/dd9384a199a6c054c5f17cb5b8083038/422e4a77ca570a6f/ there are 156 tests are failing ![]() Moving this PR to Extended testing to work on build stability. |
@magento run all tests |
@magento run Functional Tests B2B, Functional Tests CE, Functional Tests EE |
Fixed all mentioned test failures. @igorwulff and @lbajsarowicz requesting for review again. |
@magento run all tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes seems good to me and the failed tests seems flaky, hence approving the PR.
@magento run Unit Tests |
@magento run all tests |
The testing has been done, as mentioned in here. Since the build is failing moving it to Extended Testing. |
@magento run Functional Tests B2B, Functional Tests CE, Functional Tests EE, Integration Tests, Unit Tests |
@magento run Functional Tests B2B |
This function call is relatively expensive when $elements has the full layout in it. Especially the PageCache module is calling this function a lot from the following places:
On my local machine I've seen the impact to be anywhere between 20-40 milliseconds, when the page has been loaded a few times to warm up cache (config, block, layout, etc...), but FPC is circumvented.
We could also opt to move this to the PageCache module, but I think it is ok to optimize this within the Layout class within the framework.
Description (*)
Related Pull Requests
Fixed Issues (if relevant)
Manual testing scenarios (*)
Questions or comments
Contribution checklist (*)
Resolved issues: