Thanks Walden for the reply, that makes total sense. The error is on our part (we're in production with debug on as its a greenfield project). This second reply to my question brings me to my point. What was actually happening (and this is speculation), is that my code changes related to performance we're having no impact on the results/times of our processing. I had introduced multi-threading in three or four areas of the code to reduce bottlenecks. They weren't having any impact. What I THINK was happening is that the DEBUG log messages were causing disk writes which were taking time and thus causing thrashing/lots of context switching. The new threads were working alright but kept being interrupted, hence the lack of any performance improvement with my changes. With INFO on (and some changes to log level in key parts of the code) , the users will not be aware of the changes in log level. In addition I intend to fall back onto Michaels suggestion below. i.e. if they absolutely MUST have logging at DEBUG level, I'll try have it bufferred as indicated below. thanks much for the replies. G ________________________________
From: Michael Schall [mailto:[email protected]] 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 need to keep the debug information you can look at the BufferingForwardingAppender. The following will buffer 255 messages before writing to the file, unless there is a WARN or higher message, then the buffer is flushed immediately. This should hopefully let the error message that crashes the system still make it to the log file.:) I don't know how your loggers are setup, but you can turn off at that level as well. <log4net> <appender name="BufferingForwardingAppender" type="log4net.Appender.BufferingForwardingAppender" > <bufferSize value="255" /> <lossy value="false" /> <evaluator type="log4net.Core.LevelEvaluator"> <threshold value="WARN"/> </evaluator> <appender-ref ref="RollingFile" /> </appender> <appender name="RollingFile" type="log4net.Appender.RollingFileAppender"> <file value="..\..\log\web.log" /> <appendToFile value="true" /> <maximumFileSize value="100MB" /> <maxSizeRollBackups value="-1" /> <layout type="log4net.Layout.PatternLayout"> <conversionPattern value="%5level [%date] [%thread] %-30.30logger{2} %message%newline" /> </layout> </appender> <root> <level value="DEBUG" /> <appender-ref ref="BufferingForwardingAppender" /> </root> </log4net> On Wed, Feb 25, 2009 at 8:31 AM, Walden H. Leverich <[email protected]> wrote: 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. Even more, if your app developers were smart about it, they checked the IsDebugEnabled property before making the log.Debug() call, so you're not even evaluating the parms to that call, and sometimes that can be quite expensive. So, it's a "known issue" that logging more stuff takes more time, but I wouldn't call it a bug. -Walden -- Walden H Leverich III Tech Software (516) 627-3800 x3051 [email protected] http://www.TechSoftInc.com Quiquid latine dictum sit altum viditur. (Whatever is said in Latin seems profound.)
Ce message et ses pièces jointes (le "message") est destiné à l'usage exclusif de son destinataire. Si vous recevez ce message par erreur, merci d'en aviser immédiatement l'expéditeur et de le détruire ensuite. Le présent message pouvant être altéré à notre insu, CALYON Crédit Agricole CIB ne peut pas être engagé par son contenu. Tous droits réservés. This message and/or any attachments (the "message") is intended for the sole use of its addressee. If you are not the addressee, please immediately notify the sender and then destroy the message. As this message and/or any attachments may have been altered without our knowledge, its content is not legally binding on CALYON Crédit Agricole CIB. All rights reserved.
