[
https://issues.apache.org/jira/browse/SLING-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14085847#comment-14085847
]
Carsten Ziegeler commented on SLING-3290:
-----------------------------------------
I'm note sure if we should mix the two issues for now. As Felix points out, the
long term goal is to just use /etc/map as the source of truth (some time ago I
created SLING-3206 for a first step). Startup might still be slow if we have to
traverse a large tree in /etc/map, so I think Antonio's idea of the bloom
filter still makes sense.
Re guava: let's please not introduce this - if we require something from that
lib, just embedd the single class you need, but I definitely don't want this
lib as an OSGi bundle
> 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: SLING-3290-patch.txt, 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)
