The issue is that the AppenderSkeleton takes a conservative implementation attitude and provides the basic locking that most appender subclasses would need. It locks on the appender instance, this does serialise the outputting for that appender instance. While this is good for many appenders it does introduce a rather painful bottleneck for appenders that can output in parallel.
The AdoNetAppender is designed to be a flexible appender that can be runtime configured for most users. It is not the most performant implementation. If you have a fixed database schema you are working to it is relatively simple to create a new appender that writes to a database, and you don't need to extend the AppenderSkeleton, therefore you can remove the locking overhead. Attached is a simple appender that writes to a fixed schema database. You can customize it to your requirements. As you will see it is very simple compared to the AdoNetAppender and only the ConnectionString can be specified in the config file, but it should alleviate your performance issues. An example config for this appender would be: <appender name="FastDbAppender" type="SampleAppendersApp.Appender.FastDbAppender, SampleAppendersApp"> <connectionString value="Persist Security Info=False;Integrated Security=false;server=<servername>;database=log4net_test;Connect Timeout=30;User ID=<user>;Password=<password>" /> </appender> Note that you will need to update the type attribute to be the assembly qualified typename for the appender wherever you decide to put it. Cheers, Nicko > -----Original Message----- > From: Darren Blackett [mailto:[EMAIL PROTECTED] > Sent: 02 June 2005 19:15 > To: 'Log4NET User' > Subject: RE: ASP.NET Blocking Problem > > App Block - not yet. I'll do some digging in there and see > if, for this type of logging it is a better fit. > > However, I was hoping to get the solution using what I'd > already done with log4net. I'll do some digging in nlog. > Overrigding the doappend call is a potentially viable option, > however, would you say that the general feeling is I'm using > log4net in a way that is contrary to its primary design > function and therefore I should look to do this type of > logging a different way? > > I'm also going to have a look at Corneliu's suggestion. > > -----Original Message----- > From: Ron Grabowski [mailto:[EMAIL PROTECTED] > Sent: 02 June 2005 17:11 > To: Log4NET User > Subject: Re: ASP.NET Blocking Problem > > Nicko checked in a MSMQ appender into source control a few days ago. > I'm not familiar with MSMQ in terms of what it guarantees to > capture (is it just a sink?). You could try writing things to > there then write another program to extract the data out and > insert it into the database. > > I glanced at NLog's DatabaseAppender.cs code and it looks > like when you set its KeepConnection property to false, calls > to DoAppend are not enclosed in a lock{} block. > > Have you looked into the Microsoft Enterprise Library Logging Block? > > - Ron > > --- Kevin Williams <[EMAIL PROTECTED]> wrote: > > > [EMAIL PROTECTED] wrote: > > > My concern with implementing buffering is that if my > appdomain dies > > I > > > will lose the contents of the buffer. I've seen the app > domain die > > in > > > testing and can't afford to lose the information in my live > > application. > > > I also have to guarantee that this data has reached the database > > before > > > I move on to actually do something (messaging isn't an option). > > > > Just a thought - I have no idea if it would work for you. > > > > Perhaps you could create a Remoting listener service (as in > NT/200x/XP > > service) to do the database logging. You could communicate to that > > from the RemotingAppender. This could give you an asynchronous > > messaging buffer running in a separate AppDomain and, > arguably, a more > > stable environment than ASP.NET. > > > > Cheers, > > > > Kevin > > > > > >
FastDbAppender.cs
Description: FastDbAppender.cs
