Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!feeds.phibee-telecom.net!usenet.ukfsn.org!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: analysis of java application logs Date: Tue, 24 May 2011 12:29:21 +0000 (UTC) Organization: UK Free Software Network Lines: 63 Message-ID: References: <941ivgF1amU1@mid.individual.net> NNTP-Posting-Host: 84.45.235.129 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: localhost.localdomain 1306240161 18803 84.45.235.129 (24 May 2011 12:29:21 GMT) X-Complaints-To: usenet@localhost.localdomain NNTP-Posting-Date: Tue, 24 May 2011 12:29:21 +0000 (UTC) User-Agent: Pan/0.133 (House of Butterflies) Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4529 On Tue, 24 May 2011 12:26:39 +0100, Nigel Wade wrote: > On 23/05/11 23:25, Martin Gregorie wrote: >> On Mon, 23 May 2011 15:02:23 -0400, Lew wrote: >> >>> On 05/23/2011 01:16 PM, Daniele Futtorovic wrote: >>>> Let me emphasize: IMHO debugging logs and logs for analysis are two >>>> different things and should be kept strictly separated -- possibly >>>> logged to a different target respectively. >>> >>> That last is rather a brilliant idea, to use different targets. >>> Heretofore I've espoused that logs are primarily an operations tool, >>> not a debugging tool, although in service of the former they >>> inevitably and inherently must support the former. The problem I've >>> always seen is that logging statements are left up to the programmer, >>> and not specified for the project. >>> >> I tend to use at least two logging streams: debugging and operational. >> I leave debugging statements in production code: its normally off (of >> course) but can be turned on if needed. > > There is one caveat to leaving debug logging in production code; it may > affect performance. Even with output disabled the string arguments are > still constructed, unless they are constant. If logging is located in a > tight loop, or critical section, it might become significant. > Fair point. However, my usual debugging statement takes the form: if (debug > 0) debugger.trace(result + " = method(" + arg + ")"); Ugly, I know, but quite efficient, since when debugging is off even the cost of the method call cost is. I use an integer to control debugging rather than a boolean so I can control its volume: "java Application -dd" would be expected to provide more detailed debugging output than "java Application -d" > In one particular application I profiled I found this to be eating up > 80% of the CPU time. Admittedly, this was a rather special case, but > it's still something which ought to be borne in mind if you leave debug > logging code in production software. > Agreed. On occasion I've used a circular buffer to accumulate tracing information which gets only dumped if an exception occurs. This is great if you're chasing rarely occurring problems in a high volume, long running process since it obviates searching through megabytes of tracing info to find 20-30 lines of relevant tracing. You'd expect this too to be quite expensive to run, so I'd use the same mechanism outlined earlier to ensure that tracing set off means that circular buffer is never filled rather than merely suppressing the buffer dump operation. That said, I used to administer an OS (ICL's George 3) that continuously traced its internal operations to a fine-grained and a coarse-grained circular buffer which could be dumped after a crash and still managed to run fast enough to be a very usable OS. -- martin@ | Martin Gregorie gregorie. | Essex, UK- org |