[
https://issues.apache.org/jira/browse/SLING-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14084560#comment-14084560
]
Felix Meschberger commented on SLING-3290:
------------------------------------------
Re Guava: Unless we can prove real use of this library, I am hesitant to add it
to the Sling runtime because I always have the impression of this being a
spider-like truck-sized super-heavy library. (I may be wrong, though).
Re Bloom: This may be the right approach within the current box, but ...
Lets get out of the box of the current implementation of collection of vanity
path information: Currently we collect this information real-time into an
in-memory structure. Whenever an update takes place, this same procedure takes
place again. Two problems here: in-memory and full-work-on-update. One nice
property though: It is simple :-) Oh, and then there is another, far larger
problem: Any content author can create vanity paths regardless of whether
vanity paths are strictly managed or not (and in general vanity paths are
managed much stricter than regular content page URLs).
Now, lets turn around and consider [~tmueller] idea: As I have stated elsewhere
(but potentially not in the realm of Sling), we have to change the way how
vanity paths are loaded in that we copy the information from sling:vanityPath
properties into the -- already existing -- {{/etc/map}} structure. Only this
structure is ever read by the MapEntries class.
When a sling:vanityPath property is modified, an event listener just updates
the {{/etc/map}} entry and MapEntries class takes not. This reamoves the search
from the MapEntries initialization.
Another side-effect of this separation is that we can add controls to vanity
path mapping. For example in a Web Content Management System, a workflow might
be triggered which causes validation of the vanity path mapping and only when
confirmed, will the {{/etc/map}} entry be set.
Finally and independently, the MapEntries class can be improved as to maybe not
eagerly load all entries but to load on-demand (and drop unused entries). And
here a bloom filter, might help in deciding whether something should be read
from the repository at all (whether that brings any performance gain is another
question, though)
> 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)
