Logging Block v3 vs log4net

Topics: Logging Application Block
May 21, 2007 at 9:11 PM
The last time I saw a speed comparison featuring log4net and the logging block was for entlib v1. Have there been any optimizations made that I should be aware of? If not, does anyone have any general thoughts on how fast the other blocks are? Ordinarily I don't worry too much about speed, but a lot of this stuff is designed to be used constantly, so it's important we know.

For anyone curious:
http://weblogs.asp.net/lorenh/archive/2005/02/18/376191.aspx
May 21, 2007 at 9:59 PM
I for one think that there is no exact answer to the question which one is better, especially regarding the performance because both libraries have several available listeners and for instance bad performance logging to database is not always caused by a listener/library.

I would say that the main reason choosing between log4net and Logging AB could be if you are going to use the other application blocks. If you are I think in all cases it's better to use Logging AB because blocks interact with each other.

And vice versa, log4net has more listeners in a package then Logging AB and if there is a listener which you should use according to requirements I think it's better to save time and choose log4net.

-
Thanks, Leonid
May 21, 2007 at 10:44 PM
Hi Leonid,
Thank you for the reply. I realize that there are different listeners, and that that may make the tests more difficult, but where the listeners in each package are functionally equivalent, it seems that a performance comparison would make sense.

As I mentioned earlier, I'm not one to generally get too upset w/ performance, but performance can be a pretty critical aspect of a logging framework because the code is executed so frequently. The same could be said for a lot of the components here.

I do take your meaning w/ regard to choosing based on the larger decision of whether you're using other aspects of entlib. Unfortunately, this has always been a point of concern for a lot of us. The whole, in for a penny, in for a pound nature of the blocks tended to discourage their use, because you were afraid of how deep and crazy the rabbit hole might be. I've heard that the code is more flexible these days though, which hopefully means that I can largely pick and choose what I need.
May 22, 2007 at 9:41 AM
Hello All,

Even I was in dilemma to choose between EntLib 3.0 vs log4net 1.2.9. There is NO performance comparison between these two found( eventhough there is comparison between EntLib 1.0/2.0 vs log4net) . So I thought of doing it on my own.
Below are the results I found.

1. Performance comparison ( Time taken to log n messages ) :

No of Messages Time Taken by
EntLib log4net
10,000 1 sec 1 sec
1 Lakh 5-6sec 2-3 sec
10Lakh 50-52 sec 10-12 sec
Thread safe yes yes

Support for Compact Framework : log4net do have support for compact framework 1.0. EntLib, In msdn site, it was not mentioned, I asked them query if they have any plans of future support like ( Mobile Client Software factory. )

support for WCF : Enterprise Library 3.0 do have support for WCF where internal WCF messages could be directed. In log4net, there is no support as such, but someone said, there could be work around. here is
the link for that http://www.nabble.com/System.Trace.Diagnostics-to-log4net-t3440933.html

log4net is basically developed for .Net 1.0, they have extended their support for 2.0 now.
log4net will not make frequent releases as they feel their product is quiet stable.
Enterprise Library is mainly developed for .Net 2.0 and they are in the process of extending their support for 3.0 ( like WCF.)

Regards
smitha r mangalore
May 22, 2007 at 4:05 PM
To Smitha: thanks for preformance results. What listerners did you use in your test?
May 22, 2007 at 4:49 PM
I would be careful about accepting someone's performance numbers. There are too many factors that influence performance. I could run identical tests and come up with completely different numbers and results. I take those numbers above with a grain of salt.

I use both the Logging Application Block and log4net and log performance has never been an issue and is the least of my worries. A typical application will log more aggressively at the beginning of deployment and then curtail logging as confidence is gained in the application. Pretty soon you are just logging exceptions and extraordinary events.

Unless you have a truly performance sensitive application with a lot of logging, I don't think you have to worry about either package. It really comes down to features, maintainability, extensibility, and whatever other requirements drive your application.

Regards,

Dave

__________________________________

David Hayden
Microsoft MVP C#
May 23, 2007 at 6:36 AM
Edited May 23, 2007 at 6:37 AM
Hi Miksh,

I used simple flat file listener and verified the same code with Rolling Flat file listener. It works the same.
I apologige for missing such an important parameter.

Regards,
smitha
May 23, 2007 at 6:47 AM
I agree with DavidHayden.

I initially was very happy working with enterprise Library. But soon when I tried to compare it with log4net, I found from this link
http://weblogs.asp.net/lorenh/archive/2005/02/18/376191.aspx that enterprise library takes 10 sec to log 10k messages...that is almost comes up to 1ms for each message, which will be too costly for my project performance. Their analysis was based on the initial release of enterprise Library. So I thought of testing it on my own based on my proj requirement. and that was my analysis. I used simple for loop to log so may messages. Definately performance may chnage based on other factors too. But my analysis proves that, there is drastic improvement in performance and feature improvement in the Enterprise Library 3.0. So I would prefer going for it.

Please keep commenting on this, as it will keep this discussion more interesting.

Regards
smitha
May 23, 2007 at 6:50 AM
Edited May 23, 2007 at 6:50 AM
Enterprise Library Logging Application Block 3.0 vs log4net 1.2.9

1. Enterprise Library application block is more structured and well maintained.
Exception Handling, policy injection and all other application block have almost similar architecture. This reduces the development time and maintenance effort.

2. In case of logging information at very high load (more than 10,000messages), log4net has better performance over Enterprise Library.
(At moderate load, both have same performance).

3. Enterprise Library is coming up with quick releases with better features and performance.log4net lags in this aspect.

4. log4net is developed for .Net framework 1.0 and they have extended support for 2.0. Where as Enterprise Library Logging application block is developed for .Net Framework 2.0 and they are extending their support for .Net 3.0

5. Support for WCF : Enterprise Library 3.0 do support WCF. Log4net does not provide support for WCF. But there could be work around.

6. Support for Compact Framework: log4net does have support for .NetCF 1.0.
Enterprise Library 3.0 does not have support for .NetCF. There is high probability that they extend their support in future releases like Mobile Client Software Factory.

7. Enterprise Library can easily talk to Smart client application and other application blocks of Enterprise Library.

8. Enterprise Library can be easily extensible with minimal effort.

From the above analysis, it is advisable to go with Microsoft P&P product Enterprise Library application block.
However call should be taken based on your proj reqt.

Regards
smitha r mangalore
May 23, 2007 at 12:25 PM

jeffdeville wrote:
Hi Leonid,
Thank you for the reply. I realize that there are different listeners, and that that may make the tests more difficult, but where the listeners in each package are functionally equivalent, it seems that a performance comparison would make sense.

As I mentioned earlier, I'm not one to generally get too upset w/ performance, but performance can be a pretty critical aspect of a logging framework because the code is executed so frequently. The same could be said for a lot of the components here.

I do take your meaning w/ regard to choosing based on the larger decision of whether you're using other aspects of entlib. Unfortunately, this has always been a point of concern for a lot of us. The whole, in for a penny, in for a pound nature of the blocks tended to discourage their use, because you were afraid of how deep and crazy the rabbit hole might be. I've heard that the code is more flexible these days though, which hopefully means that I can largely pick and choose what I need.


I think here we have not a question of Logging AB performance (even in the comparison with Log4net) rather then the question of Logging AB and listeners usage. In my opnion if you have 10,000 log entries to be logged out to a file (rolling file btw) at a certain period of time it is not all ok with design I suppose.

First of all I would say if you are not quite satisfied with performance of the concrete listener you are able to implement your own (derive or extend any standard listener). For example you may add caching to file listener that realizes something like "lazy-saving".

Another example, let's say we have client applications logging very intensively to a single place. If we use file trace listener or even database trace listener I guess we would have performance problems. I think this scenario is exactly the case when we should use MSMQ log distribution so you will not wait until log messages are saved somewhere. Also you can implement a web service that receives messages from all clients and log them let's say to database but through a cache initially. Manually implemented listener sends log entries to this web service.

Another words I want to come up here with an idea that usually there is always a chance to change logic of how you log your data.

-
Thanks, Leonid