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:[email protected]] > Sent: 24 February 2012 13:28 > To: [email protected] > 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:[email protected]] >> Sent: 24 February 2012 10:13 >> To: [email protected] >> 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 >
