[logback-user] MDC performance concerns

[Ceki Gulcu]

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