[
https://issues.apache.org/jira/browse/SLING-9535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Derks updated SLING-9535:
----------------------------------
Description:
Improve performance of sling:alias Query when Optimize alias resolution is
activated in the Resource Resolver Factory:
!image-2020-06-19-18-29-24-335.png!
By checking the logs at startup this query is executed:
{noformat}
(query=SELECT sling:alias FROM nt:base WHERE sling:alias IS NOT NULL, path=*,
property=[sling:alias=[is not null]]){noformat}
*The part that will be good to improve is that the query is not executed for
path=*, instead a predefined set of locations is used.*
(Something similar as it is for the Vanity Paths will be nice):
!image-2020-06-19-18-33-21-657.png!
Then if none fo these are configured then the query is executed with path=*.
In our project several versions are created per page and it turns out that the
sling:alias found under _/jcr:system/jcr:versionStorage_ are also including in
the query exceeding the 10000 limit mentioned in the warning message of the
property:
_This might have an impact on the startup time and on the alias update time if
the number of aliases is huge (over 10000)_
We might have a different approach to solve our issue but did not want to leave
this topic in the air. Might be also a good improvement for others.
Thanks
was:
Improve performance of sling:alias Query when Optimize alias resolution is
activated in the Resource Resolver Factory:
!image-2020-06-19-18-29-24-335.png!
By checking the logs at startup this query is executed:
{noformat}
(query=SELECT sling:alias FROM nt:base WHERE sling:alias IS NOT NULL, path=*,
property=[sling:alias=[is not null]]){noformat}
*The part that will be good to improve is that the query is not executed for
path=*, instead a predefined set of locations is used.*
(Something similar as it is for the Vanity Paths will be nice):
!image-2020-06-19-18-33-21-657.png!
Then if none fo these are configured the the query is executed with path=*.
In our project several versions are created per page and it turns out that the
sling:alias found under _/jcr:system/jcr:versionStorage_ are also including in
the query exceeding the 10000 limit mentioned in the warning message of the
property:
_This might have an impact on the startup time and on the alias update time if
the number of aliases is huge (over 10000)_
We might have a different approach to solve our issue but did not want to leave
this topic in the air. Might be also a good improvement for others.
Thanks
> Improve performance of sling:alias Query when Optimize alias resolution is
> activated
> ------------------------------------------------------------------------------------
>
> Key: SLING-9535
> URL: https://issues.apache.org/jira/browse/SLING-9535
> Project: Sling
> Issue Type: Improvement
> Components: ResourceResolver
> Reporter: Leonardo Derks
> Priority: Major
> Attachments: image-2020-06-19-18-29-24-335.png,
> image-2020-06-19-18-33-21-657.png
>
>
> Improve performance of sling:alias Query when Optimize alias resolution is
> activated in the Resource Resolver Factory:
> !image-2020-06-19-18-29-24-335.png!
> By checking the logs at startup this query is executed:
> {noformat}
> (query=SELECT sling:alias FROM nt:base WHERE sling:alias IS NOT NULL, path=*,
> property=[sling:alias=[is not null]]){noformat}
> *The part that will be good to improve is that the query is not executed for
> path=*, instead a predefined set of locations is used.*
> (Something similar as it is for the Vanity Paths will be nice):
> !image-2020-06-19-18-33-21-657.png!
> Then if none fo these are configured then the query is executed with path=*.
>
> In our project several versions are created per page and it turns out that
> the sling:alias found under _/jcr:system/jcr:versionStorage_ are also
> including in the query exceeding the 10000 limit mentioned in the warning
> message of the property:
> _This might have an impact on the startup time and on the alias update time
> if the number of aliases is huge (over 10000)_
>
> We might have a different approach to solve our issue but did not want to
> leave this topic in the air. Might be also a good improvement for others.
>
> Thanks
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
