[ https://issues.apache.org/jira/browse/SLING-3844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14177271#comment-14177271 ]
Rob Ryan commented on SLING-3844: --------------------------------- [~asanso] I agree that in the typical case this will likely prove adequate. But why set ourselves up for the potential pitfall of the multi-alias case (even it it is vanishingly rare)? As opposed to mirroring the existing datastructure in the inverse? Anyway, I don't object to this so much as to veto it :-) even if I had a veto vote. > 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.3.4#6332)