[ 
https://issues.apache.org/jira/browse/SLING-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14018699#comment-14018699
 ] 

Thomas Mueller commented on SLING-3290:
---------------------------------------

I assume vanity path information needs to be available fully in memory, always. 
Right?

Could Sling cache the vanity paths information from time to time in one node, 
as a binary? Kind of like a "precompiled header". That binary would need to be 
removed (or marked as invalid) whenever vanity paths are modified. To avoid 
rapid re-writing of that binary when vanity paths are changed, it should only 
be stored once per minute or so. An observation listener could probably take 
care of that (to update the in-memory structure at runtime, and to remove the 
outdated binary, and write the new binary from time to time).


> Long startup time with many vanityPath
> --------------------------------------
>
>                 Key: SLING-3290
>                 URL: https://issues.apache.org/jira/browse/SLING-3290
>             Project: Sling
>          Issue Type: Improvement
>          Components: ResourceResolver
>            Reporter: Antonio Sanso
>            Assignee: Antonio Sanso
>              Labels: vanity
>         Attachments: StartupWithManyVanityPath.jpg
>
>
> When many vanityPath or alias are present the system take long time to 
> startup , Same when a vanityPath/alias is removed or updated .
> The reason behind is the usage of a query that updates the global mapentry.
> I have added a new Test to the performance test suite and this is the outcome
> {code}
> 0 vanityPath                  16ms
> 1  vanityPath                 19ms
> 10 vanityPath         70ms
> 100 vanityPath                111ms
> 1000 vanityPath               200ms
> 10000 vanityPath              1173ms
> 30000 vanityPath              3358ms
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to