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:fmesc...@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
