[
https://issues.apache.org/jira/browse/WICKET-7003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Del Bene updated WICKET-7003:
------------------------------------
Affects Version/s: 9.11.0
> The http RequestLogger is very expensive. #524
> ------------------------------------------------
>
> Key: WICKET-7003
> URL: https://issues.apache.org/jira/browse/WICKET-7003
> Project: Wicket
> Issue Type: Improvement
> Affects Versions: 9.11.0
> Reporter: Andrea Del Bene
> Priority: Major
>
> The http RequestLogger is very expensive. In our system, we see almost 4kb of
> memory allocation in this code to create a logging String that is ~700 bytes
> long, per logging message being created.
> * the use of AppendingStringBuffer immediately doubles the memory
> requirement compared to StringBuilder as the former treats
> all characters as UTF16. The log messages here appear to be mostly Latin1.
> * Calls to getRequestHandlerString allocate an AppendingStringBuffer, resize
> it once, and then call toString().
> This results in nearly 1KB of garbage object creation (along with 5 objects)
> and repeated data copies per call.
> * Portions of the final String will have been copied up to 5 times in the
> accumulation of the logging String.
> Much better would be to have a single StringBuilder that is used repeatedly,
> with the createRequestData() call synchronized.
> This would save ~800 bytes of memory per logging request. I did not implement
> that here as I expect some push back on serializing that call. Logging has to
> be serialized anyway to avoid interleaving the output, and if logging is a
> contention hotspot
> then the rest of the application isn't doing much work.
> The impact here is to act as an L1 D$ flush in the processor. While this code
> might be fast (it will clearly evidence high hit rates in the cache), it
> evicts other data from the L1 D$ resulting in subsequent code being slower.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
