Simon, The BufferingAppenderSkeleton handles the buffering of events for the ADONetAppender. The LoggingEvent object refers to a lot of information that is specific to the call state and thread at the point where the event is logged. For example: the thread name, MDC, NDC, thread principal, caller location information. As the LoggingEvent is to be stored in a buffer outside of the context of the current call and thread all this information needs to be cached. This can be rather expensive to do if you don't actually want to log the information. The BufferingAppenderSkeleton can be told not to capture this state by setting the Fix property on the ADONetAppender to Partial. Partial captures the following: Mdc | Ndc | Message | ThreadName | Exception | Domain.
Programmatically: Appender.Fix = log4net.spi.FixFlags.Partial; Or in the config file: <appender ...> <fix value="Partial" /> </appender> Nicko > -----Original Message----- > From: Simon Wallis [mailto:[EMAIL PROTECTED] > Sent: 20 October 2004 22:36 > To: [email protected] > Subject: Performance of buffered vs. non-buffered logging > > I've been running some performance tests today on using the > log4net ADONetAppender. I have a simple ASP.NET page that > does one log request, and I'm using ACT to hit this page with > 50, 100, 150, 200, 300 and 400 users with a 5-10 second > random delay between each request. > > I did one set of tests with a bufferSize of 1 and another set > of tests with a bufferSize of 50. Surprisingly the first set > of tests outperformed (albeit just marginally) the set with > bufferSize of 50. The database is not local, it is on the > network, so I would have expected the buffered tests to > greatly outperform the non-buffered. > > Any comments on this? It seems strange. > > Simon. >
