tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Funk <>
Subject Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves mbeans-descriptors.xml
Date Sat, 20 Nov 2004 13:21:53 GMT
I never thought about it this way, but can the comparisons be made by using 
and not using Keep-Alive? I would guess that if Keep-alive is used - there 
would be a performance gain since the same thread needs to wait for the valve 
to write its log entry, before the next item in keep alive request is made.

If keep alive is turned off, there would be no performance boost - unless all 
the threads were in use.

I'm just playing devil's advocate. I ran some tests with AccessLogValve 
turned on vs turned off on some HP-UX boxes and saw no performance 
difference. So either my test was bad, or the HP os/disks we use do an 
awesome job of caching in the disk controller to provide superb I/O performance.

If I weren't swamped with my day job, I'd love to refactor access log valve 
into 2 parts:
  - The pattern creator. This creates the line item which needs logged. For 
example: Standard or Extended. This piece would decide when or when not to log.
  - A writer. A set of classes (some possibly abstract to inherit from) which 
allow logging in a variety of manners such as: FileLogger, BufferedLogger, 
PipedLogger, FileSizeLogger(rotate on size), FileDateLogger(rotate on Date), 
CombinedLogger (a stub which talks to a some controller which combines all 
the logs in a cluster into one file)

[But since I have no code to contribute at this time, I'll just stay quiet.]


Remy Maucherat wrote:

> Jean-Francois Arcand wrote:
>> Without access log valve, we are 20% faster. With the ByteBuffer one, 
>> 13%.
> There are 3 access log valves ;) Maybe you should give a chart.
> I'll do my byte based improvements (to be able to save on char to byte) 
> in your implementation.
> The buffer isn't big enough. 16k will hold 500 requests maximum. If you 
> were afraid of doing one I/O operations, it's bad, as you'll end up 
> doing a lot of I/O synchronously. Can we allow the buffers to grow ? At 
> least they would need to be a lot bigger otherwise (we could "reinvest" 
> the memory saved from not having a background thread :) ).
> Another trick if you want to tweak the interval inside the valve, you 
> can use an integer that you increment and do a modulo (i % n). I do that 
> for the manager checks (one check every 6 invocations of 
> backgroundProcess).

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message