Ok.  I am back working on this again.

>From the previous comments, I am not sure my efforts are going in the right
direction.  However, I have a working implementation that uses the standard
logging mechanism now, while addressing some of the previous concerns.

I did a quick performance test, and it is true that the default mechanism
is quite a bit faster than the standard JULI logger.  For this test, I just
modified the source code to write each log message 1000 times.  The first
set of timings (in millis) is from the current AccessLogValve, and the
second set is using JULI.

AccessLogValve Elapsed Time: 8
AccessLogValve Elapsed Time: 19
AccessLogValve Elapsed Time: 63
AccessLogValve Elapsed Time: 6
AccessLogValve Elapsed Time: 7
AccessLogValve Elapsed Time: 8

INFO: AccessLogValve Elapsed Time: 830
INFO: AccessLogValve Elapsed Time: 1122
INFO: AccessLogValve Elapsed Time: 451
INFO: AccessLogValve Elapsed Time: 531
INFO: AccessLogValve Elapsed Time: 764
INFO: AccessLogValve Elapsed Time: 347

Granted, this certainly falls into the "Contrived micro-benchmark" realm.
A real test would involve lots of threads each writing very little.  Also,
each thread would be doing a lot of other things, making the time spent in
the access logger less significant.  However, even in the worse case, it
still only took a millis to write one message.

Honing my test case to test the speed of 1 single message (not just the
write, but the whole process of creating and then writing the  message), I
got that it takes between 0 - 1 millis in the first case, and 0 - 2 millis
with JULI.  Most messages took 1 millis for each.  (I have a pretty old
machine I am testing on now.)  I didn't test the speed of the file rolling
and such.  Also, I have no idea which would perform better under a heavy
load.

I don't really have the facilities to do a realistic performance test.
However, I think something can be gleaned from the above results.  Does
anyone have any advice or suggestions on what direction I should go?  My
main goal is to have automatic deletion of old log files.  This is
something I would imagine others would like as well, so I thought I would
present here instead of just doing something myself.  I certainly do not
what to make anything more complicated to use / configure than it has to be.

I am considering 5 options:
1) I can add my "outputLoggerName" attribute, which will switch the valve
to use the JULI logger
2) I can create some sort of AccessLogWriter that the AccessLogValves will
delegate their writing to
    - With 2 implementations, one being the current method and one being a
JULI implementation
    - Potentially removing one in the future if performance is not an issue.
3) I can just add an attribute to the AccessLogValves to automatically
delete older files
4) I can just make my own private subclass to do what I want, and leave the
tomcat code unaltered
5) Scrap the current file writing implementation in the AccessLogValve and
go straight JULI

I would welcome any advice.

Thanks,
Mark

Reply via email to