tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cos...@eng.sun.com>
Subject Re: VOTE: Timestamps in log
Date Wed, 05 Jul 2000 19:19:11 GMT
> > 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.

I agree with that - my only problem is that we don't have a good way
to format the timestamp.



> > 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?

Yes.

It would be great to be the "extra object or two", it's much more.
The logging creates more GC than the request processing, and that's
not good, but for 3.2 I don't think we want to tune up the
formatter.

A date formater that is efficient and can be reused is very important,
we do need date conversion for cookies and some headers
( and we can't turn this off :-).

I guess we can start this dicussion again when we do have a
date formatter.


( BTW,  try to run "ab -c 40 ", with logger turned of and on with
date and with millis, and maybe OptimizeIt. It's very interesting).

Costin




Mime
View raw message