Description
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.