Long startup time with many vanityPath or alias

[Antonio Sanso <as...@adobe.com>]

hi *,

in SLING-3290 [0] I have started to write some performance test regarding long startup time with many vanityPath or alias.

As you might see from the attached graph the startup time increases considerably with the number of vanityPath. 

The same should applies to aliases (I am writing the test case). 

The reason behind this is comment and should be IMHO the usage of a query that updates the global map entry. 
In fact the "issue" doesn't occur only at startup but as well every time a vanityPath/alias is updated.

IMHO would be nice to try to improve this situation.

WDYT?

regards

antonio 

[0] https://issues.apache.org/jira/browse/SLING-3290

Re: Long startup time with many vanityPath or alias

[Bertrand Delacretaz <bd...@apache.org>]

On Mon, Jan 6, 2014 at 3:00 PM, Justin Edelson <ju...@justinedelson.com> wrote:
> ...My personal opinion is that supporting 10k vanity paths is a non-goal,
> but that's just me :)...

I would agree but users are creative sometimes ;-)

Worst case, we might provide a way to disable the default vanity paths
handling completely and let people implement their own variant, for
exotic use cases.

> ...I believe Felix has proposed a solution to "migrate" vanity paths from
> wherever they are defined into /etc/map through some kind of approval
> workflow. Search the list archives for more details....

I remember these discussions but haven't followed in detail. Looking
at this I tried to list all the ways that we have to map incoming URLs
to resources and vice-versa, and it makes me wonder if we really need
all these mechanisms:

a) Vanity URLs, sling:vanityPath
http://sling.apache.org/old-stuff/request-processing.html

b) Mappings via /etc/map with sling:match, sling:alias,
sling:internalRedirect, sling:redirect
http://sling.apache.org/documentation/the-sling-engine/mappings-for-resource-resolution.html

c) sling:alias and sling:redirect on any resource
Documented a the same URL as b)

d) Resource resolver virtual URLs
No docs?

e) Resource resolver URL mappings
No docs?

f) Resource resolver namespace mangling
No docs?

Not sure if this list is even complete...

-Bertrand

Re: Long startup time with many vanityPath or alias

[Justin Edelson <ju...@justinedelson.com>]

Hi,

On Mon, Jan 6, 2014 at 8:18 AM, Antonio Sanso <as...@adobe.com> wrote:
>
> On Jan 6, 2014, at 2:10 PM, Bertrand Delacretaz <bd...@apache.org> wrote:
>
>> On Mon, Jan 6, 2014 at 2:03 PM, Antonio Sanso <as...@adobe.com> wrote:
>>> anyone :) ?...
>>
>> I see only observations in
>> https://issues.apache.org/jira/browse/SLING-3290, what are you looking
>> for?
>>
>
> right :)
>
> It would be nice to try to come with an approach to improve the situation,
> This issue would affect not only the startup time but the update as well .
> Also the alias features is impacted.
> IMHO we should replace the search for vanityPath/aliases and come up with a new solution.
> This is the only way to "scale"

Have you done any profiling to see where the time is going?

My personal opinion is that supporting 10k vanity paths is a non-goal,
but that's just me :)

I believe Felix has proposed a solution to "migrate" vanity paths from
wherever they are defined into /etc/map through some kind of approval
workflow. Search the list archives for more details.

Justin
>
> regards
>
> antonio
>
>> If it's agreement that long startup times are bad, I do agree ;-)
>>
>> -Bertrand
>

Re: Long startup time with many vanityPath or alias

[Antonio Sanso <as...@adobe.com>]

On Jan 6, 2014, at 2:10 PM, Bertrand Delacretaz <bd...@apache.org> wrote:

> On Mon, Jan 6, 2014 at 2:03 PM, Antonio Sanso <as...@adobe.com> wrote:
>> anyone :) ?...
> 
> I see only observations in
> https://issues.apache.org/jira/browse/SLING-3290, what are you looking
> for?
> 

right :)

It would be nice to try to come with an approach to improve the situation,
This issue would affect not only the startup time but the update as well .
Also the alias features is impacted.
IMHO we should replace the search for vanityPath/aliases and come up with a new solution.
This is the only way to "scale"

regards

antonio

> If it's agreement that long startup times are bad, I do agree ;-)
> 
> -Bertrand

Re: Long startup time with many vanityPath or alias

[Bertrand Delacretaz <bd...@apache.org>]

On Mon, Jan 6, 2014 at 2:03 PM, Antonio Sanso <as...@adobe.com> wrote:
> anyone :) ?...

I see only observations in
https://issues.apache.org/jira/browse/SLING-3290, what are you looking
for?

If it's agreement that long startup times are bad, I do agree ;-)

-Bertrand

Re: Long startup time with many vanityPath or alias

[Antonio Sanso <as...@adobe.com>]

anyone :) ?

On Dec 19, 2013, at 10:02 AM, Antonio Sanso <as...@adobe.com> wrote:

> hi *,
> 
> in SLING-3290 [0] I have started to write some performance test regarding long startup time with many vanityPath or alias.
> 
> As you might see from the attached graph the startup time increases considerably with the number of vanityPath. 
> 
> The same should applies to aliases (I am writing the test case). 
> 
> The reason behind this is comment and should be IMHO the usage of a query that updates the global map entry. 
> In fact the "issue" doesn't occur only at startup but as well every time a vanityPath/alias is updated.
> 
> IMHO would be nice to try to improve this situation.
> 
> WDYT?
> 
> regards
> 
> antonio 
> 
> [0] https://issues.apache.org/jira/browse/SLING-3290
> 
>