[jira] [Updated] (WICKET-6780) Improve performance of resource mapping

["Andrea Del Bene (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrea Del Bene updated WICKET-6780:
------------------------------------
    Description: 
{{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:
 

  was:
{{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:
||Benchmark||Mode||Cnt||Score||Error||Units||
|MapperBenchmark.compatibilityScore|thrpt|5|  6251028,198|± 1110953,287|ops/s|
|MapperBenchmark.compatibilityScoreWithPrefixMatching|thrpt|5|13154340,419|± 1435077,659|ops/s|


> 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.3.4#803005)