|Mark Claassen||Feb 15, 2012 1:23 pm|
|Mark Thomas||Feb 15, 2012 1:32 pm|
|Mark Claassen||Feb 15, 2012 1:55 pm|
|Konstantin Kolinko||Feb 15, 2012 2:06 pm|
|Mark Claassen||Feb 16, 2012 7:16 am|
|Mark Claassen||Feb 16, 2012 1:05 pm||.zip|
|Konstantin Kolinko||Feb 16, 2012 1:11 pm|
|Mark Claassen||Feb 16, 2012 1:44 pm|
|Filip Hanik - Dev Lists||Feb 17, 2012 7:22 am|
|Francis Galiegue||Feb 17, 2012 7:54 am|
|Filip Hanik - Dev Lists||Feb 17, 2012 8:04 am|
|Rainer Jung||Feb 17, 2012 8:13 am|
|Christopher Schultz||Feb 19, 2012 9:20 am|
|Mark Thomas||Feb 19, 2012 9:49 am|
|Mark Claassen||Feb 19, 2012 6:53 pm|
|Christopher Schultz||Feb 21, 2012 8:37 am|
|Mark Claassen||Feb 24, 2012 8:49 am|
|Mark Claassen||Mar 27, 2012 6:29 am|
|Konstantin Kolinko||Mar 27, 2012 6:46 am|
|Mark Claassen||Mar 27, 2012 8:16 am|
|Mark Claassen||Mar 29, 2012 9:51 am|
|Konstantin Kolinko||Mar 29, 2012 1:43 pm|
|Mark Claassen||Apr 11, 2012 11:09 am|
|Subject:||Re: AccessLogValve enhancement|
|From:||Mark Claassen (mark...@gmail.com)|
|Date:||Mar 27, 2012 6:29:43 am|
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.