10

Which is the quickest appender for log4Net apart from ConsoleAppender?

Amitabh
  • 59,111
  • 42
  • 110
  • 159

3 Answers3

19

Checkout the BufferingForwardingAppender. We use this which forwards to a RollingFileAppender. It batches the writes and allows the code to continue without waiting for the write. We setup an Evaluator to force a flush at the WARN threshold and set lossy to false so we don't miss any messages.

<appender name="BufferingForwardingAppender" type="log4net.Appender.BufferingForwardingAppender">
    <bufferSize value="512" />
    <lossy value="false" />
    <evaluator type="log4net.Core.LevelEvaluator">
        <threshold value="WARN"/>
    </evaluator>
    <appender-ref ref="RollingFileAppender" />
</appender>
Philipp M
  • 1,877
  • 7
  • 27
  • 38
Mike Schall
  • 5,829
  • 4
  • 41
  • 47
  • 2
    Exactly what I didn't know I was looking for. – ctrlplusb Sep 02 '12 at 16:01
  • I have tested this in a simple web project and (surprisingly) scalability does not improve, is quite worse instead. **Test**: 500 requests / 50 users for 20 log lines per request. **Results**: No logging: 278 req/s, Rolling File Appender: 129 req/s, Buffering Forwarding with Rolling File: 76 req/s. – tozevv Oct 01 '13 at 14:50
  • 2
    Digging further and found this is known problem with this appender. See http://stackoverflow.com/questions/11319319/log4net-bufferingforwardingappender-performance-issue. With the proposed fix is 258 req/s with BufferingForwardingAppender – tozevv Oct 01 '13 at 14:57
  • from tozew's link, adding to config makes it better. – Ho Ho Ho Dec 19 '17 at 15:54
8

You could write a log4Net equivalent of NullAppender, which would be very fast... (Oops - I originally thought the question was about log4j; the same advice applies though.)

Of course, that wouldn't do anything useful - which leads me to wonder why you're placing so much importance on speed. The normal approach is to work out what you need, then benchmark/profile it to check whether it performs adequately. I suspect that you'll be swamped with more data than you can usefully process before it actually becomes a bottleneck. Do you have a known performance problem with logging?

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • No the performance problem is not with logging but in general I am looking into improving the performance of an application and have added log4Net to profile it at the runtime. I don't want this to be too much of an overhead as the application is already slow. So I am looking for the appender which is the fastest. – Amitabh Feb 02 '10 at 14:41
  • 1
    @Amitabh: If the application is already slow, that means logging is even *less* likely to have a significant impact. Really, use whatever gets you logs most easily, and then just use logging sensibly. That's likely to be the quickest way to improve your app's overall speed. – Jon Skeet Feb 02 '10 at 14:52
  • I'll add that sometimes the issue isn't how slow logging is but how invasive. For example, if you're logging from multiple threads, the very act of logging can cause them to synchronize, which throws off what you want to measure. The usual answer is to log into a queue, which is processed in a single thread. – Steven Sudit Feb 02 '10 at 15:02
  • I must say, logging with Log4Net can significantly slow down an application - depending on the level of logging and the number of messages. Writing to disk is always costly and the idea of asynchronous logging would be very nice for performance. – goku_da_master Mar 08 '12 at 16:10
0

you should consider

  1. writing to file is much faster than writing to console
  2. I guess your problem is with the pre-production (ceating the log data and then not using it) use log.canLog to make sure you can log before you create your data (this is usually the big time consumer)
  3. check you're not using all kinds of fields that are time consuming like current credentials of user etc...
Mickey Perlstein
  • 2,508
  • 2
  • 30
  • 37