[
https://issues.apache.org/jira/browse/SLING-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13151078#comment-13151078
]
Carsten Ziegeler commented on SLING-2255:
-----------------------------------------
Thanks for your patch, Antonio! It definitely goes into the right direction,
however :) I have some remarks
Is it by intention, that you do
if
(this.factory.getMapEntries().getVanityMaps().containsKey(getPathVanityKey(absPath))){
in the JcrResourceResolver? Shouldn't it be requestPath instead of absPath?
For the whole checking of the mapping, we currently favour simple
implementation over performance: everything is checked in the same way by using
regexps. With your patch I think we're just going half of the way as still the
old code is in place (more or less) but with additional checks to get a better
performance.
I'm not 100% sure and have to further check, but I think the better approach
would be to change the implementation completely and only use regexps where it
really makes sense - so we would distinguish between vanity mappings where we
really don't need regexps (at least not for each and every vanity path) and
really regexp based matchings. Not sure if this is going to fly though....
The other potential problem I see atm is that the current implementation loads
configurations and vanity paths into a single map and then sorts them - with
your change, you don't mix these two anymore which might be a change in
behaviour.
This mapping is at the heart of Sling and right now I feel not very confident
in changing this in the described way. But regardless of my comments, really
great work so far, Antonio! I'll further investigate to see what we can do.
> Improve JcrResourceResolver#resolve performance when big number of vanityPath
> are present
> -----------------------------------------------------------------------------------------
>
> Key: SLING-2255
> URL: https://issues.apache.org/jira/browse/SLING-2255
> Project: Sling
> Issue Type: Improvement
> Components: JCR
> Affects Versions: JCR Resource 2.0.10
> Reporter: Antonio Sanso
> Assignee: Carsten Ziegeler
> Priority: Minor
> Fix For: JCR Resource 2.1.0
>
> Attachments: SLING-2255.txt, performance.pdf
>
>
> At the moment the performance of JcrResourceResolver#resolve is tight with
> the number of sling:vanityPath present in the repository.
> Large number of vanityPath means large response time specially in the worse
> case scenario (namely huge number of vanityPath and request that doesn't
> match any vanityPath) but also in the average cases.
> Sling currently employs generic regexps also for vanityPath, but since the
> regex behind a vanityPath is well know there is room for optimization.
> I'll attach a graphs that shows the situation and a potential patch.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
