> DEBUG info at no price.. so to speak
Can't help on the buffering, but your comment above isn't necessarily
correct at any rate. It depends on where the performance his of the
Debug() call is. Sure there's a hit on writing the log to disk, and the
buffering helps there, but there is also the h
the RichTextBox appender, I will have the same output but without the overhead
(i.e. DEBUG info at no price.. so to speak).
thanks
Graham
From: WALSH, Graham (CALYON)
Sent: jeudi 26 février 2009 09:09
To: Log4NET User
Subject: RE: DEBUG vs INFO
sorry, but
évrier 2009 20:36
To: Log4NET User
Subject: Re: DEBUG vs INFO
What appenders are you using? I assume one of them is the rolling file
appender? How large is the log file produced with the setting at DEBUG vs
INFO?
If you need to keep the debug information you can look at the
BufferingForw
From: Michael Schall [mailto:mike.sch...@gmail.com]
Sent: mercredi 25 février 2009 20:36
To: Log4NET User
Subject: Re: DEBUG vs INFO
What appenders are you using? I assume one of them is the rolling file
appender? How large is the log file produced with the setting at DEBUG vs
INFO?
If you ne
What appenders are you using? I assume one of them is the rolling file
appender? How large is the log file produced with the setting at DEBUG vs
INFO?
If you need to keep the debug information you can look at
the BufferingForwardingAppender. The following will buffer 255 messages
before writing
Graham,
That's not a log4net issue as much as it's an issue in your application.
Sounds like your application (like many) makes lots of log.Debug()
calls, to log, um, debug information. By switching the logging from
DEBUG to INFO you've stopped all those log entries from being written to
disk. Eve
Hi,
I just switch from DEBUG to INFO in our application logging and the
difference is pretty much stunning. E.G. our perf has gone from 23
seconds down to 14 because of the change. Is this a known issue. i.e.
debug log level is expected to impose this kind of overhead.
Thanks
Graham
Ce message
