Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
8.7.0, 9.0.0-M5
-
None
-
None
Description
ResourceMapper showed up very prominently in my production profiler:
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: