[
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)