User tests: Successful: Unsuccessful:
Pull Request for Issue #43649.
Currently while checking access, the Access::preload()
pulling everything from the access table.
It is neglectable for small sites, however for large sites it has huge impact on the site performance.
I added a new method for "smart preload", which allows to preload only needed items. And applied this method for most of the com_content views, where it make sense.
In the View class (or other places before access check) developer call to pre-load access for loaded items with (example for com_content
):
$assetsList = ['com_content.article.1', 'com_content.article.2', 'com_content.category.1'];
Access::preloadItems('com_content', $assetsList);
Where the $assetsList
is a list for asset name for $items
.
This will load access information for these items and its parent in to memory.
And each following call of $user->authorise('core.xxx', $assetName)
will reuse preloaded item.
Create a site with 20k articles (more is better). Can use following plugin to generate random content https://github.com/Fedik/plg_sampledata_bigdata
Enable debug.
Open article detail or blog view.
Look for memory usage in the debug bar, and for time.
In my test:
memory usage around 45Mb
time 200-300ms
In my test:
memory usage around ~12Mb
time ~100ms
Please select:
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_categories com_content Front End Libraries |
Labels |
Added:
Feature
bug
PR-5.2-dev
|
Title |
|
Labels |
Added:
Performance
Removed: bug |
Labels |
Added:
PR-5.3-dev
Removed: PR-5.2-dev |
Title |
|
This pull request has been automatically rebased to 6.0-dev.
Title |
|
Labels |
Added:
PR-6.0-dev
Removed: PR-5.3-dev |
@SniperSister please have a look also this one. In combination with #45542 it should be a bigger improvement in performance for the Content component for large sites.
I updated the PR description, with example how it works.
Will rebase it after upmarge