Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Date: Wed, 5 Jul 2000 04:23:11 -0700
From: Alex Chaffee <guru@edamame.stinky.com>
To: costin@eng.sun.com
Cc: tomcat-dev@jakarta.apache.org, alex@jguru.com
Subject: Re: VOTE: Timestamps in log
Message-ID: <20000705042311.H29683@edamame.stinky.com>
Reply-To: alex@jguru.com
References: <20000705032129.D29683@edamame.stinky.com>
 <Pine.GSO.4.21.0007051036030.28814-100000@costin.dnt.ro>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <Pine.GSO.4.21.0007051036030.28814-100000@costin.dnt.ro>;
 from costin@eng.sun.com on Wed, Jul 05, 2000 at 10:53:40AM -0700


> > (Anyone replying may say +1 for "2000-07-04 13:45:11" and -1 for
> > "963636252"; if nobody but Costin objects, I'll keep it how it is by
> > default.)
> 
> AFAIK a -1 with valid reasons is a veto. Anyway, if you feel it's so
> important to have formated dates by default - I'm fine, you can go ahead.

You're right, of course; and thanks for your vote towards consensus.


On Wed, Jul 05, 2000 at 10:53:40AM -0700, costin@eng.sun.com wrote:
> > My rule of thumb in programming is "don't pre-optimize".  Most people
> > using Tomcat will not be running high-load web sites (since most
> > people in the world don't run high-load web sites) so it's better to
> > optimize for clarity over performance.  
> 
> I think this is far from a "pre-optimize" case - we are talking about a
> default option in the final product ( maybe post-optimize). 

Given that anyone who cares can turn it off in a config file, this
argument doesn't sway me.  The default should be "most useful to most
people" which I feel here means "most legible".


> Time-stamping anything but the access log is a waste, and formating the
> date is also a waste.  

I disagree; I've often been able to track down errors, by
synchronizing different log file entries, thanks to timestamps.  And
since this is usually done with grep and less, it's good that it's
formatted so it's legible to a human eye.


> > Also, given that the log writer is running in a backround thread
> > anyway (nice design, whoever wrote that, btw), it will never impact
> > the latency of a request in any case.
> 
> I spent last months tuning up tomcat, and believe me - GC has a huge
> impact in latency.

Ah. OK. Excellent point.


> Most of the performance improvements between tocmat 3.1 and 3.2 comes from
> reducing the GC and reusing the objects. Date formating is a big GC
> generator, and it's almost imposible to reuse the date formating objects
> with the current API ( or I coulnd't find a way ). 

The date formatter itself is actually reusable ( I made it an instance
var), however...

> I would be happy to vote +1 if you find a way to format the date that
> allows object reuse ! 
> ( and again - it wouldn't be pre-optimization )

Aha, a challenge! :-)

SimpleDateFormat.format(Date date, StringBuffer toAppendTo,
FieldPosition pos) is what I'm using, and you're right, it seems to
sometimes (though not always) allocate a few StringBuffers along the
way, which it discards for GC.  (I'd have to track this down more
carefully; it makes heavy use of lookup tables for strings, and uses
StringBuffer.append a lot.)

Now, the current LogEntry object has a toString() method, which
allocates, fills, and converts a StringBuffer, which may cause at
least one StringBuffer and a String to be left in the heap for each
message, but that happens regardless of timestamping.

I suppose that this whole process should be tuned to use only
stream.write() methods and no internal Strings or StringBuffers,
right?  Until that happens, though, we can safely write off the logger
as "untuned" and hopefully the extra object or two left around by the
date formatter won't make it *that* much less tuned (relative to other
processes)... Given your tuning experience, do you (perhaps with
reservations) agree?

 - Alex


-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/