You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Felix Meschberger <fm...@adobe.com> on 2012/02/24 11:12:52 UTC
[ResourceResolver] sling:alias support
Hi all,
We have had support for sling:alias properties for a long time. This allows to create URL aliases for example for i18n. Yet, it also creates some overhead for resolution of non-existing URLs.
Whenever an URL cannot directly be resolved it is split in segments and the resource tree is walked down from the top resolving each segment: If a child resource is not found, all children are inspected for a sling:alias property. Only if none has been found, the iteration terminates and resource resolution fails.
This is potentially a costly operation and may not always be required.
I wonder, whether we should have a configuration option to be able to switch off sling:alias support (Default would be enabled sling:alias support for backwards compatibility).
Regards
Felix
Re: [ResourceResolver] sling:alias support
Posted by Antonio Sanso <as...@adobe.com>.
+1
Antonio
On Feb 24, 2012, at 11:12 AM, Felix Meschberger wrote:
> Hi all,
>
> We have had support for sling:alias properties for a long time. This allows to create URL aliases for example for i18n. Yet, it also creates some overhead for resolution of non-existing URLs.
>
> Whenever an URL cannot directly be resolved it is split in segments and the resource tree is walked down from the top resolving each segment: If a child resource is not found, all children are inspected for a sling:alias property. Only if none has been found, the iteration terminates and resource resolution fails.
>
> This is potentially a costly operation and may not always be required.
>
> I wonder, whether we should have a configuration option to be able to switch off sling:alias support (Default would be enabled sling:alias support for backwards compatibility).
>
> Regards
> Felix
Re: [ResourceResolver] sling:alias support
Posted by Michael Dürig <md...@apache.org>.
On 24.2.12 12:48, Jeff Young wrote:
> Felix,
>
> Have we done any profiling to confirm that sling:alias resolution does actually contribute a meaningful percentage?
>
Here is a graph [1] which shows that adding nodes one by one scales
linearly in the number of nodes already added. The horizontal axis shows
the number of nodes, the vertical axis time in milliseconds.
The test was done with a backend [2] which provides an insertion time
which is constant on average (i.e. does not depend on the number of nodes).
Michael
[1]
https://docs.google.com/presentation/pub?id=1xOMTsqG5_MB9sbjHJpLH-57kh4V5__CEFP7zKwVUFfI&start=false&loop=false&delayms=3000
[2] http://svn.apache.org/viewvc/jackrabbit/sandbox/jackrabbit-mk/
>
>
> -----Original Message-----
> From: Felix Meschberger [mailto:fmeschbe@adobe.com]
> Sent: 24 February 2012 10:13
> To: dev@sling.apache.org
> Subject: [ResourceResolver] sling:alias support
>
> Hi all,
>
> We have had support for sling:alias properties for a long time. This allows to create URL aliases for example for i18n. Yet, it also creates some overhead for resolution of non-existing URLs.
>
> Whenever an URL cannot directly be resolved it is split in segments and the resource tree is walked down from the top resolving each segment: If a child resource is not found, all children are inspected for a sling:alias property. Only if none has been found, the iteration terminates and resource resolution fails.
>
> This is potentially a costly operation and may not always be required.
>
> I wonder, whether we should have a configuration option to be able to switch off sling:alias support (Default would be enabled sling:alias support for backwards compatibility).
>
> Regards
> Felix
RE: [ResourceResolver] sling:alias support
Posted by Jeff Young <je...@adobe.com>.
+1
Jeff.
> -----Original Message-----
> From: Felix Meschberger [mailto:fmeschbe@adobe.com]
> Sent: 29 March 2012 19:25
> To: dev@sling.apache.org
> Subject: Re: [ResourceResolver] sling:alias support
>
> Hi,
>
> This is kind of strong evidence IMHO. Thanks for sharing.
>
> Regards
> Felix
>
> Am 29.03.2012 um 11:44 schrieb Antonio Sanso:
>
> > Hi Jeff,
> >
> > in [0] you can find a kind of evidence for it.
> >
> > Regards
> >
> > Antonio
> >
> > [0] https://issues.apache.org/jira/browse/SLING-2311
> >
> > On Feb 24, 2012, at 1:48 PM, Jeff Young wrote:
> >
> >> Felix,
> >>
> >> Have we done any profiling to confirm that sling:alias resolution
> does actually contribute a meaningful percentage?
> >>
> >> Jeff.
> >>
> >>
> >> -----Original Message-----
> >> From: Felix Meschberger [mailto:fmeschbe@adobe.com]
> >> Sent: 24 February 2012 10:13
> >> To: dev@sling.apache.org
> >> Subject: [ResourceResolver] sling:alias support
> >>
> >> Hi all,
> >>
> >> We have had support for sling:alias properties for a long time. This
> allows to create URL aliases for example for i18n. Yet, it also creates
> some overhead for resolution of non-existing URLs.
> >>
> >> Whenever an URL cannot directly be resolved it is split in segments
> and the resource tree is walked down from the top resolving each
> segment: If a child resource is not found, all children are inspected
> for a sling:alias property. Only if none has been found, the iteration
> terminates and resource resolution fails.
> >>
> >> This is potentially a costly operation and may not always be
> required.
> >>
> >> I wonder, whether we should have a configuration option to be able
> to switch off sling:alias support (Default would be enabled sling:alias
> support for backwards compatibility).
> >>
> >> Regards
> >> Felix
> >
Re: [ResourceResolver] sling:alias support
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
This is kind of strong evidence IMHO. Thanks for sharing.
Regards
Felix
Am 29.03.2012 um 11:44 schrieb Antonio Sanso:
> Hi Jeff,
>
> in [0] you can find a kind of evidence for it.
>
> Regards
>
> Antonio
>
> [0] https://issues.apache.org/jira/browse/SLING-2311
>
> On Feb 24, 2012, at 1:48 PM, Jeff Young wrote:
>
>> Felix,
>>
>> Have we done any profiling to confirm that sling:alias resolution does actually contribute a meaningful percentage?
>>
>> Jeff.
>>
>>
>> -----Original Message-----
>> From: Felix Meschberger [mailto:fmeschbe@adobe.com]
>> Sent: 24 February 2012 10:13
>> To: dev@sling.apache.org
>> Subject: [ResourceResolver] sling:alias support
>>
>> Hi all,
>>
>> We have had support for sling:alias properties for a long time. This allows to create URL aliases for example for i18n. Yet, it also creates some overhead for resolution of non-existing URLs.
>>
>> Whenever an URL cannot directly be resolved it is split in segments and the resource tree is walked down from the top resolving each segment: If a child resource is not found, all children are inspected for a sling:alias property. Only if none has been found, the iteration terminates and resource resolution fails.
>>
>> This is potentially a costly operation and may not always be required.
>>
>> I wonder, whether we should have a configuration option to be able to switch off sling:alias support (Default would be enabled sling:alias support for backwards compatibility).
>>
>> Regards
>> Felix
>
Re: [ResourceResolver] sling:alias support
Posted by Antonio Sanso <as...@adobe.com>.
Hi Jeff,
in [0] you can find a kind of evidence for it.
Regards
Antonio
[0] https://issues.apache.org/jira/browse/SLING-2311
On Feb 24, 2012, at 1:48 PM, Jeff Young wrote:
> Felix,
>
> Have we done any profiling to confirm that sling:alias resolution does actually contribute a meaningful percentage?
>
> Jeff.
>
>
> -----Original Message-----
> From: Felix Meschberger [mailto:fmeschbe@adobe.com]
> Sent: 24 February 2012 10:13
> To: dev@sling.apache.org
> Subject: [ResourceResolver] sling:alias support
>
> Hi all,
>
> We have had support for sling:alias properties for a long time. This allows to create URL aliases for example for i18n. Yet, it also creates some overhead for resolution of non-existing URLs.
>
> Whenever an URL cannot directly be resolved it is split in segments and the resource tree is walked down from the top resolving each segment: If a child resource is not found, all children are inspected for a sling:alias property. Only if none has been found, the iteration terminates and resource resolution fails.
>
> This is potentially a costly operation and may not always be required.
>
> I wonder, whether we should have a configuration option to be able to switch off sling:alias support (Default would be enabled sling:alias support for backwards compatibility).
>
> Regards
> Felix
Re: [ResourceResolver] sling:alias support
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 24.02.2012 um 15:10 schrieb Jeff Young:
> Antonio,
>
> Not quite direct evidence, but probably close enough to act on.
The actual evidence is just the code that is built to run to evaluate the alias properties. They are used as a last resort for resolving an URL.
Consider a deep and broad hierarchy (we are currently doing some tests with a high number of children below a common parent (working towards Jackrabbit 3)). And this tears on performance.
Say you have a node /content/x with 2000 children, none of which is called "foo". Now you try to resolve /content/x/foo, the 2000 children of /content/x will be scanned to see whether there is a sling:alias property and whether such a property has the value foo.
Granted, this only happens if an URL tends to be unresolvable, which might often be the case or not.
Regards
Felix
>
> +1
>
> BTW: is it the checking for an alias that slows things down, or the resolution of the alias path? If the later, it'd be nice to spit out a warning to the log if we ever find a sling:alias but the configuration is set to ignore it.
>
> Jeff.
>
>
> -----Original Message-----
> From: Antonio Sanso [mailto:asanso@adobe.com]
> Sent: 24 February 2012 13:28
> To: dev@sling.apache.org
> Subject: Re: [ResourceResolver] sling:alias support
>
> Hi Jeff
>
> On Feb 24, 2012, at 1:48 PM, Jeff Young wrote:
>
>> Felix,
>>
>> Have we done any profiling to confirm that sling:alias resolution does actually contribute a meaningful percentage?
>
>
> we have a Jira ticket somehow related [0]. Not profiling though. There is some kind of profiling for vanityPath [1] as part of [2].
>
> Regards
>
> Antonio
>
>
> [0] https://issues.apache.org/jira/browse/SLING-2239
> [1] https://issues.apache.org/jira/secure/attachment/12500677/performance.pdf
> [2] https://issues.apache.org/jira/browse/SLING-2255
>>
>> Jeff.
>>
>>
>> -----Original Message-----
>> From: Felix Meschberger [mailto:fmeschbe@adobe.com]
>> Sent: 24 February 2012 10:13
>> To: dev@sling.apache.org
>> Subject: [ResourceResolver] sling:alias support
>>
>> Hi all,
>>
>> We have had support for sling:alias properties for a long time. This allows to create URL aliases for example for i18n. Yet, it also creates some overhead for resolution of non-existing URLs.
>>
>> Whenever an URL cannot directly be resolved it is split in segments and the resource tree is walked down from the top resolving each segment: If a child resource is not found, all children are inspected for a sling:alias property. Only if none has been found, the iteration terminates and resource resolution fails.
>>
>> This is potentially a costly operation and may not always be required.
>>
>> I wonder, whether we should have a configuration option to be able to switch off sling:alias support (Default would be enabled sling:alias support for backwards compatibility).
>>
>> Regards
>> Felix
>
RE: [ResourceResolver] sling:alias support
Posted by Jeff Young <je...@adobe.com>.
Antonio,
Not quite direct evidence, but probably close enough to act on.
+1
BTW: is it the checking for an alias that slows things down, or the resolution of the alias path? If the later, it'd be nice to spit out a warning to the log if we ever find a sling:alias but the configuration is set to ignore it.
Jeff.
-----Original Message-----
From: Antonio Sanso [mailto:asanso@adobe.com]
Sent: 24 February 2012 13:28
To: dev@sling.apache.org
Subject: Re: [ResourceResolver] sling:alias support
Hi Jeff
On Feb 24, 2012, at 1:48 PM, Jeff Young wrote:
> Felix,
>
> Have we done any profiling to confirm that sling:alias resolution does actually contribute a meaningful percentage?
we have a Jira ticket somehow related [0]. Not profiling though. There is some kind of profiling for vanityPath [1] as part of [2].
Regards
Antonio
[0] https://issues.apache.org/jira/browse/SLING-2239
[1] https://issues.apache.org/jira/secure/attachment/12500677/performance.pdf
[2] https://issues.apache.org/jira/browse/SLING-2255
>
> Jeff.
>
>
> -----Original Message-----
> From: Felix Meschberger [mailto:fmeschbe@adobe.com]
> Sent: 24 February 2012 10:13
> To: dev@sling.apache.org
> Subject: [ResourceResolver] sling:alias support
>
> Hi all,
>
> We have had support for sling:alias properties for a long time. This allows to create URL aliases for example for i18n. Yet, it also creates some overhead for resolution of non-existing URLs.
>
> Whenever an URL cannot directly be resolved it is split in segments and the resource tree is walked down from the top resolving each segment: If a child resource is not found, all children are inspected for a sling:alias property. Only if none has been found, the iteration terminates and resource resolution fails.
>
> This is potentially a costly operation and may not always be required.
>
> I wonder, whether we should have a configuration option to be able to switch off sling:alias support (Default would be enabled sling:alias support for backwards compatibility).
>
> Regards
> Felix
Re: [ResourceResolver] sling:alias support
Posted by Antonio Sanso <as...@adobe.com>.
Hi Jeff
On Feb 24, 2012, at 1:48 PM, Jeff Young wrote:
> Felix,
>
> Have we done any profiling to confirm that sling:alias resolution does actually contribute a meaningful percentage?
we have a Jira ticket somehow related [0]. Not profiling though. There is some kind of profiling for vanityPath [1] as part of [2].
Regards
Antonio
[0] https://issues.apache.org/jira/browse/SLING-2239
[1] https://issues.apache.org/jira/secure/attachment/12500677/performance.pdf
[2] https://issues.apache.org/jira/browse/SLING-2255
>
> Jeff.
>
>
> -----Original Message-----
> From: Felix Meschberger [mailto:fmeschbe@adobe.com]
> Sent: 24 February 2012 10:13
> To: dev@sling.apache.org
> Subject: [ResourceResolver] sling:alias support
>
> Hi all,
>
> We have had support for sling:alias properties for a long time. This allows to create URL aliases for example for i18n. Yet, it also creates some overhead for resolution of non-existing URLs.
>
> Whenever an URL cannot directly be resolved it is split in segments and the resource tree is walked down from the top resolving each segment: If a child resource is not found, all children are inspected for a sling:alias property. Only if none has been found, the iteration terminates and resource resolution fails.
>
> This is potentially a costly operation and may not always be required.
>
> I wonder, whether we should have a configuration option to be able to switch off sling:alias support (Default would be enabled sling:alias support for backwards compatibility).
>
> Regards
> Felix
RE: [ResourceResolver] sling:alias support
Posted by Jeff Young <je...@adobe.com>.
Felix,
Have we done any profiling to confirm that sling:alias resolution does actually contribute a meaningful percentage?
Jeff.
-----Original Message-----
From: Felix Meschberger [mailto:fmeschbe@adobe.com]
Sent: 24 February 2012 10:13
To: dev@sling.apache.org
Subject: [ResourceResolver] sling:alias support
Hi all,
We have had support for sling:alias properties for a long time. This allows to create URL aliases for example for i18n. Yet, it also creates some overhead for resolution of non-existing URLs.
Whenever an URL cannot directly be resolved it is split in segments and the resource tree is walked down from the top resolving each segment: If a child resource is not found, all children are inspected for a sling:alias property. Only if none has been found, the iteration terminates and resource resolution fails.
This is potentially a costly operation and may not always be required.
I wonder, whether we should have a configuration option to be able to switch off sling:alias support (Default would be enabled sling:alias support for backwards compatibility).
Regards
Felix