After thinking about this some more, and deliberating on the subtle issues that were coming up, I decided to reduce the scope of my enhancement. I still like the idea of using a standard logger for this logging, but for now I thought I would focus more on my specific problem. I wrote more about this in the issue. https://issues.apache.org/bugzilla/show_bug.cgi?id=52688
Is this something that could be adopted in a future 7.0 release? -----Original Message----- From: Mark Claassen [mailto:markclaass...@gmail.com] Sent: Tuesday, March 27, 2012 11:17 AM To: Tomcat Developers List Subject: Re: AccessLogValve enhancement That improved my timings considerably. Instead of between 300 - 1100, they are between 100 - 330. However, they are still slower than the current mechanism. (Although, I am not sure how much this benchmark is worth, anyway.) I would imagine that the Async logger has lots of optimizations in it to handle the threading aspects; I wonder if it would be better under load than the current mechanism? This info is not going to catalina.out. Other comments? Suggestions for direction: 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. Mark On Tue, Mar 27, 2012 at 9:46 AM, Konstantin Kolinko <knst.koli...@gmail.com>wrote: > 2012/3/27 Mark Claassen <markclaass...@gmail.com>: > > > > 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 > > > > 1. Try to configure JULI with org.apache.juli.AsyncFileHandler. > It might show better numbers. > > (The usual FileHandler by default performs flush() after each log message). > > 2. Is the same printed to console? If yes then remove ConsoleHandler. > > Best regards, > Konstantin Kolinko > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For > additional commands, e-mail: dev-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
