[
https://issues.apache.org/jira/browse/WICKET-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Del Bene resolved WICKET-6780.
-------------------------------------
Resolution: Fixed
> Improve performance of resource mapping
> ---------------------------------------
>
> Key: WICKET-6780
> URL: https://issues.apache.org/jira/browse/WICKET-6780
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-core
> Affects Versions: 8.7.0, 9.0.0-M5
> Reporter: Thomas Heigl
> Priority: Major
> Attachments: image-2020-05-05-10-59-50-624.png
>
>
> {{ResourceMapper}} showed up very prominently in my production profiler:
> !image-2020-05-05-10-59-50-624.png|width=952,height=551!
> For mapping an incoming request to a handler, the {{CompoundRequestMapper}}
> iterates over all registered mappers and calculates a compatibility score.
> For resources, this involves extracting the component and page info from the
> URL. This seems to be quite an expensive operation.
> If a request comes in, Wicket parses the component info for *every*
> registered resource. In my case, several hundred. It does this, *before* it
> checks if the request path would even match the requested resource, which
> would be a much cheaper operation. It has to do so, because it has to remove
> potential caching information from the URL before applying url matching.
> I have implemented a heuristic that bypasses this check if the initial
> segments of the resource path do not match the incoming request. E.g.
> A resource is mounted under {{/static/css/my.css}}. The initial segments
> would be {{static}} and {{css}}. They contain no parameters and do not
> contain caching information because this information is either encoded in the
> file name or a query parameter.
> This is currently implemented as a custom {{ResourceMapper}} that I use for
> all my resources, but it might be a worthy improvement for the default mapper
> implementation:
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
