Hello Matthew, Yikes! The MDC implementation in logback is not intended to be called in hot spots. You call it when a request arrives. If requests arrive hundreds of times each milisecond, then there might be a performance concerns as you point out. The cloning is done for sake of serialization. I think cloning is necessary for correct serialization of MDC values. As you point out, cloning could be done within LoggingEvent. If you deem that logback's implementation of MDC is too slow for your purposes (I'd check if that is really true), you could write your own implementation of MDC and have it interpreted by your own MDCConverter. In logback, it is rather easy to register your own pattern converters. Holler if you decide to go down this road and you need help. If the above does not work for you, then please kindly enter a bug report. There is a reasonably good chance that your proposal will be implemented. Matthew Finn wrote:
Hello,
I am interested in converting my application to logback, but I have some performance concerns about its MDC implementation.
My application uses MDC extensively for async IO, so it may call MDC.put and MDC.remove extremely frequently, because each thread may be handling 1000s of interleaved connections using state machines.
I see in the source for LogbackMDCAdapter that for every call to MDC.put and MDC.remove, the HashMap is cloned. Could this clone potentially be handled during the creation of LoggingEvents instead of the call to MDC? The creation of logging events is expected to entail memory allocation, so it seems that it would be a better fit there, even if some applications might have a very low number of calls to MDC versus logging calls. It seems that the same energy expended in minimizing log statement impact when logging is turned off should also apply to MDC calls.
Thanks
Matt
-- Ceki Gülcü QOS.ch is looking to hire talented developers in Switzerland. If interested, please contact c e k i AT q o s . c h