Comments on the EntLib/Log4Net feature and performance comparison

I know a few people have been waiting to hear our team's thoughts on Loren Halvorson's comparision of the Enterprise Library Logging & Instrumentation Application Block and Log4Net. So here goes...

First, let me state that we do not consider Enterprise Library to be a competitor to Log4Net – we think it’s great that both solutions exist so customers can pick whichever best meets their needs. We also see Log4Net and Enterprise Library as targeting different scenarios (something that isn’t really captured in the comparison) – for example it seems that Log4Net is optimized towards simpler scenarios for sending freeform messages to log sinks, while EntLib puts more focus on the types of things we see in more complex enterprise applications, including request tracing, gathering of additional context information, internal instrumentation through WMI and perf counters, and support for “operations friendly” log sinks like WMI and (coming soon) ETW. This doesn't make Enterprise Library better (or worse) than Log4Net, but it does mean that the best tool for one app may not be the best for another.

Regarding performance, as Loren himself points out this test doesn’t reflect any normal usage patterns so you can’t really draw many conclusions from it (does anyone really need to send 10,000 messages to the void in a tight loop?). Even testing a more realistic scenario is still likely to be of limited use, as every application has its own usage pattern and environment. For example, we did extensive performance testing of Enterprise Library on our hardware in what we saw as a typical usage pattern (i.e. writing messages once per transaction to the event log and other sinks from a web app with externally-generated load) – but your own application will use logging in a different way (different sinks, different message sizes), will run on different hardware, and most importantly will have different performance goals. This last point is important – the point of performance testing and tuning isn’t to make your apps run as fast as possible (which is a futile activity, as you never know when you are done) – it’s to run within your app’s performance goals. Everything your app does, including business logic and cross-cutting things like logging will take time, but if everything happens within your goals then you’re done. So our recommendation here is to choose whatever logging solution meets your needs (be it EntLib, Log4Net, System.Diagnostics or something else), use it intelligently, test early and often against your performance goals, and optimize (or change course) if you run into trouble. (See https://microsoft.com/perf for more on this!)

Now you may be thinking that I’m dodging the question and looking at a career in politics here – yes it is obvious that in the particular scenario that was tested, Log4Net has some efficiencies over EntLib. I’m not disputing this, and there may well be some opportunities to optimize EntLib in the next version (which we’re working on now – you can submit your ideas as comments to my earlier blog posting). Still my point is that you cannot draw any conclusions from this test on whether this makes EntLib or Log4Net better for your app – the only way to get this information is to do your own homework, taking your own app’s functional requirements and perf goals into account.

Finally, we are aware that the startup time can be an issue in Enterprise Library – especially for smart client usage (for a server, the app starts so rarely it’s probably not a big issue). This will get better with .NET Framework 2.0, but in the meantime we released a custom configuration transformer class that can use Mvp.Xml’s precompiled serialization classes to dramatically improve the startup time. You can download this transformer and other additional configuration providers at the Enterprise Library community site (you need to be a member of the community and signed in to see the Releases section of the site).

This posting is provided "AS IS" with no warranties, and confers no rights.