[jira] [Updated] (WICKET-6780) Improve performance of resource mapping
[
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
[jira] [Updated] (WICKET-6780) Improve performance of resource mapping
[
https://issues.apache.org/jira/browse/WICKET-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Heigl 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:
||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|
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
[jira] [Updated] (WICKET-6780) Improve performance of resource mapping
[
https://issues.apache.org/jira/browse/WICKET-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Heigl 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:
||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|
was:
{{ResourceMapper}} showed up very prominently in my production profiler:
!image-2020-05-05-10-59-50-624.png!
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
