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

Rob Ryan edited comment on SLING-3844 at 8/19/14 2:43 PM:
----------------------------------------------------------

[~asanso] I don't follow. The reverse mapping is critical to the performance 
improvement, no? Without a map reading from child names to child aliases the 
resolver.map() loop which replaces names in the path with their alias will 
revert to its old bad performance. Do you see another way?

The bad performance comes from two factors: creating a resource for each 
element of the path being mapped and the actual lookup of the sling:alias 
property in that resource.


was (Author: rr...@adobe.com):
[~asanso] I don't follow the reverse mapping is critical to the performance 
improvement, no? Without a map reading from child names to child aliases the 
resolver.map() loop which replaces names in the path with their alias will 
revert to its old bad performance. Do you see another way?


> Resolver.map() spends too much time looking up sling:alias
> ----------------------------------------------------------
>
>                 Key: SLING-3844
>                 URL: https://issues.apache.org/jira/browse/SLING-3844
>             Project: Sling
>          Issue Type: Improvement
>          Components: ResourceResolver
>    Affects Versions: Resource Resolver 1.1.0
>            Reporter: Rob Ryan
>            Assignee: Antonio Sanso
>              Labels: Performance
>         Attachments: sling.resourceresolver.diff
>
>
> In a performance test expected to reflect reasonably real-world conditions 
> (50 concurrent users of a mixed load 'forum' type application) I found 
> Resolver.map taking more that 30% of the time used. This was tracked 
> primarily to checking each path element of the mapped path for sling:alias 
> properties to substitute into the result.
> In consultation with [~cziegeler] and [~asanso] I proceeded to implement the 
> inverse of Antonio's work on sling:alias for Resolver.resolve. The resulting 
> patch is attached. In our case the Resolver.map cost fell from 30% of time 
> used to 5%.
> If the resource.resolver.optimize.alias.resolution setting of the Apache 
> Sling Resource Resolver Factory is set to false then the patch fallback to 
> the original method of finding aliases. When the optimization is enabled the 
> aliases are looked up in hash maps maintained by observation and queries for 
> sling:alias along the same lines as Antonio's work.



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

Reply via email to