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.
Comments
- Anonymous
March 15, 2005
The comment has been removed - Anonymous
March 15, 2005
A PlugIns framework.
I reckon it's a great future-proofing mechanism, but since everyone does it differently, it becomes a very messy operation.
Some use XML config files, some use the registry, others expose an attribute, yet others try to impose a folder structure in the deployment.
A lot of software uses standardized plugins, as we all know. All I'm asking is a standard framework with EL2 that provides a common base. - Anonymous
March 15, 2005
The comment has been removed - Anonymous
March 15, 2005
I should know better than to feed the trolls.... Over engineered two words; additionally, in a library--perhaps more properly a framework--that has a goal of extensibility, pattern oriented design is exactly what is required for the framework to survive multiple releases with its architecture intact. In this case, and possibly in many others, simple is at odds with a useful and complete architecture. - Anonymous
March 16, 2005
Good post Tom. I also liked Loren's.
I'm after a clean migration path. (Both directions.) In my target scenario:
1) I check in code whether I need to log.
2) Configure on the fly, no restart.
I'd appreciate it if there was a carefully thought out ILogging interface so that I can switch with less pain.
Do you have anything in the works? - Anonymous
March 27, 2005
nice post...have done logging thru' log4net
but would like to learn more about EntLib - Anonymous
March 27, 2005
The comment has been removed - Anonymous
March 28, 2005
I agree that performance of logging itself is not so important in most scenarios.
What is important though is that logging comes back as quick as possible if turned OFF.
In my test, 100000 calls in a loop cost as much as 6 seconds. Again, this is when no logging occurs.
Which in praxis means to me that for debug-tracing you can just as well go back to printf statements, since you have to comment the stuff out later anyways.
The possibility to ask the logger, if he is going to log is essential as noted in other posts and was also there in EIF.
Cheers! - Anonymous
July 20, 2008
PingBack from http://www19.a2hosting.com/~tarasn/devintelligence.com/?p=644