FEATURE: Speed up UI flow queries with custom queries #3817
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Merged
2 tasks
|
Have to rebase, something is off with all those changes |
|
Also have to check whether I broke the "presets" feature of the document tree |
|
After discussing this a bit with @mhsdesign, it can make sense to add a "findNodesByIdentifiers" to the NodeDataRepository for 8.4 and use the new method instead of adding queries in this PR. This could also be useful for Neos 9. I will open an issue and link it. |
Currently translated at 100.0% (121 of 121 strings) Translation: Neos/Neos.Ui - Main - 8.3 Translate-URL: https://hosted.weblate.org/projects/neos/neos-ui-main-8-3/nl/
Currently translated at 100.0% (121 of 121 strings) Translation: Neos/Neos.Ui - Main - 8.3 Translate-URL: https://hosted.weblate.org/projects/neos/neos-ui-main-8-3/es/
…nodedata With this change the minimal required nodedata for each node in the rendered content is inserted as data attribute and not as inline script anymore. This improves performance as no extra function call is executed for each node. Additonally the reduction in rendered node attributes reduces the output filesize and again improves loading time. To prevent just-in-time loading of nodes all incomplete nodedata is requested after the guest frame has finished loading.
Co-authored-by: Marc Henry Schultz <[email protected]>
…r guest frame The content tree is loaded early and can load fully loaded nodes without being slower as the response time is the same. But this way we can skip lots of nodes from being loaded by the guest frame if they are already present in the store.
The UI filters itself, so the two children queries with different nodetypefilters have no effect on the final outcome and are just slowing down the response.
This way the followup methods that add the childnodes to the resulting noderesults can directly read the children from the 1st level cache. The speedup is ~50% (1s -> 500ms) in my tests for 175 nodes.
This way we only need one query to get all requested nodes instead of a query for each one.
Sebobo
force-pushed
the
bugfix/optimise-ui-flowqueries
branch
from
cde3bab
to
a9b14b2
Compare
|
Needs a rebase when #3770 was unmerged into 8.4 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What I did
This is a follow up for #3770 in which we load all nodes requested by the UI directly from the database instead of querying each node by itself and its document and content children separately.
How I did it
Extract some methods from the NodeDataRepository and added them to the NodeService in the UI to resolve all requested nodes with one db query and prefetch all child nodes of the resulting nodes to fill them into the 1st-level cache.
How to verify it
Flow query performance for loading a large page in a large project with the page tree, content tree and nodes required for the displayed content. The page tree requests 175 nodes (the 332KB request), the content tree requests 58 nodes ( the 129kb request) and the guest frame requests 191 nodes (the 615kb request) which haven't been loaded by the content tree yet and with the duplicates removed.
Performance UI 8.3.8:
Performance with branch #3770:
Performance with this branch:
