Did Nicko's suggestion resolve your issue Darren? I'm sure other people on the list are curious to know if you were able to increase your logging throughput.
--- Darren Blackett <[EMAIL PROTECTED]> wrote: > Thanks very much. I'm going to give this a go. I really appreciate > everyone's help. > > Darren > > -----Original Message----- > From: Nicko Cadell [mailto:[EMAIL PROTECTED] > Sent: 02 June 2005 22:14 > To: Log4NET User > Subject: RE: ASP.NET Blocking Problem > > 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 > > > > > > > > > > > > >
