log4net :comparing adonetappender and rollingfileappender

Question

I am trying to see which one of these appenders would perform better (the shorter the time, the better).

RollingFileAppender or ADONetAppender?

What are the other parameters I should consider when choosing an appender ?

I saw that my WebServer "holds on" to the rollingfile. Can I set something like

<lockingModel type="log4net.Appender.FileAppender+MinimalLock" /> 

(reference: FileAppender section in log4net documentation) in my rolling file appender so that multiple applications/servers can write to the same file ?

our DB server is in a SAN drive, but the log files would be written locally to the hard drive (or may be a SAN drive in the near future)

Answer 1

We have better luck using the rolling file appender. We've noticed that if there is a network glitch the ADO.NET appender stops logging. For example, a reboot after service pack installs on a weekly basis would kill your logger.

Keep in mind that also means keeping your logs on the same server if you are going with file appender - http://ferventcoder.com/archive/2009/07/16/log4net-note-always-keep-your-logs-on-the-same-server.aspx

I've never seen the minimal locking mechanism. It does look like you will pay some performance penalties if you do use it: http://logging.apache.org/log4net/release/sdk/log4net.Appender.FileAppender.MinimalLock.html

Answer 2

I generally use RollingFileAppender to a local disk - this is robust and fast (if you can't write to a local disk, you generally have a fatal problem).

Writing to ADO.NET can fail - for example if the logging database is taken offline for backup purposes while your application is running.

I would also avoid using MinimalLock because of the performance overhead - instead have a separate log file for each application. If you occasionally need to see consolidated log data, you can merge the relevant parts of the logs, or simply open the relevant parts side-by-side in a viewer.

Answer 3

If your ADONetAppender loses the connection, it will stop logging, but with the option

  <reconnectonerror value="true" />

it will try to reconnect.