Path: csiph.com!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: Logging problem Date: Sat, 10 Mar 2012 20:23:53 +0000 (UTC) Organization: UK Free Software Network Lines: 40 Message-ID: References: <11598111.961.1331330200504.JavaMail.geo-discussion-forums@pbcr5> 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 1331411033 27067 84.45.235.129 (10 Mar 2012 20:23:53 GMT) X-Complaints-To: usenet@localhost.localdomain NNTP-Posting-Date: Sat, 10 Mar 2012 20:23:53 +0000 (UTC) User-Agent: Pan/0.135 (Tomorrow I'll Wake Up and Scald Myself with Tea; GIT 30dc37b master) Xref: csiph.com comp.lang.java.programmer:12854 On Sat, 10 Mar 2012 13:00:25 -0400, Arved Sandstrom wrote: > Come, come, Martin, desktop Windows isn't quite so bad. > I wasn't saying it was - just that The Microsoft Way tends not to use logs to the extent that *NIXen do. I admit its been quite a while since I've used Windows in developer mode, but about the only place I can remember seeing good logging was from ODBC, and only then if it was configured on. The ODBC log entries weren't timestamped, but were pretty good in all other respects.[*] OTOH every *NIX system I've used produces timestamped logs and has a mechanism for changing logfiles and keeping the number kept under control. IOW I've never see a log under Windows that let me see what had happened at about 02:30:15 last Wednesday but all Unices support that sort of thing. Hey, Novice - this example below is a good example of the unexpected places where a decent log can come in useful. [*] I was using the ODBC logs to help me tune one of the more incompetently written databases I've seen. No adequate application documentation of course! So, I was reduced to exercising every function of the application with ODBC logging turned on and then working through the log to work out what indexes and table storage strategies were needed to make the database perform: AKA doing a traditional access path frequency analysis after the app had gone live and promptly slowed to a crawl. You really can't expect a join on 25,000 accounts to be fast if there are no indexes to support it, though somebody had done exactly that. And, of course the problem didn't show up during development, which had populated the test database with the traditional handful of accounts: when each table occupies no more than one or two disk blocks all queries are quick. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |