Microsoft Enterprise Library Logging Block compared to Log4net
Microsoft recently released 1.0 of the Enterprise Library. I was curious how the Logging block stacked up to Log4net.
Pros
- Configuration tool in the box - Slick little general purpose configuration tool used to configure all of the blocks in a consistent manner.
- Active development community - There's lots of buzz around the new MS library, unlike Log4net which is "incubating" over at apache with no releases since Beta 8 in 2003-07-15 ! (The Log4net developers need to get a release out...like...yesterday hint hint). Additionally there is Microsoft backing for Enterprise Library which can be considered a positive for the future of the library.
Cons
- No hierarchical configuration of categories - A nice feature of Log4net to be able to configure an entire hierarchy of loggers (if they are consistently named with dot delimited names) with a single switch rather than having to be explicit about every one. See Log4net's manual on Logger Hierarchy
- The tool restarts the web app on configuration change - When using logging in an ASP.NET web application, the configuration tool re-writes the web.config when you save configuration changings. This restarts the web app even though the changes were limited to the two logging configuration files that are external to web.config. Ideally you should be able to change log settings "in-flight" without restarting the web site, and rewriting the web.config seems to defeat the purpose of the file-watching that reconfigures itself when changes occur to these external configuration files. This is easy to work around by just editing the files by hand, but that sort of defeats the purpose of having a tool.
- No call-point short circuiting - There isn't a way to quickly determine whether logging is enabled at the call point to avoid unnecessary string building. It can be a big waste of time to concatenate or String.Format a large message string if it ultimately isn't going to be logged anywhere. See Log4net's FAQ for more information Log4net lets me write:
if (log.IsDebugEnabled)
{
log.Debug("Entry number: " + i + " is " + entry[i]);
}
- Priorities - This is minor, but I would have liked to see an enumeration of standard priorities in the block. The Priority parameter is just an arbitrary int. I guess this good and bad...good because you can choose any priority scheme you want, bad because it will be harder to enforce consistency among all developers (For example - 0 = Verbose for one group and 1 = Verbose for another.) You can't use System.Diagnostics.TraceLevel because the method of filtering on "MinimumPriority" is reversed, lower numbers are more verbose for zEntLib, higher numbers are more verbose for TraceLevel.
- Log4net appears to be much faster - In my testing, performance of the Enterprise Logging block was much slower than Log4net. Both on warm up time (the time it takes to configure the logging system and send the first log statement), and on logging 10000 messages in a tight loop.
| Enterprise Library | Log4net | |
| Warmup Time | 3014 - 5107 milliseconds | 100 - 161 milliseconds |
| Log 10000 messages | 9624 - 9814 milliseconds | 10 - 30 milliseconds |
Testing methodology - I wrote two equivalent empty appenders, one for Log4Net, and one for EntLib that do nothing but retrieve the log message into a string variable. This was done to completely factor out the cost of the appender, and hopefully measure the performance overhead of the logging framework itself. Then I wrote a console application that measures the warm up time and the time it takes to log 10000 messages in a tight loop. You can download the Visual Studio 2003 test solution from here I'd love to know if I've made an incorrect assumption in my test.