Good news,
please, open a bug report with the a AccessLogValve patch.
Thanks
Peter
Am 06.01.2007 um 09:00 schrieb Takayuki Kaneko:
Hi,
I modified AccessLogValve in about five points.
1) use buffering like FastCommonAccessLogValve
2) generate the date character string on each 1000ms like
FastCommonAccessLogValve
3) move the parsing pattern into the initail phase, it was executed on
each requst
4) manage "common" and "combine" and any pattern by the same flow
5) remove DecimalFormat because it isn't threadsafe
On 1/5/07, Mladen Turk <[EMAIL PROTECTED]> wrote:
The same could be done by simply
buffering the log and then flushing to the disk on overflow.
Yeah, I think buffering has the most impact for the performance.
So, I implemented 1).
But I think 2) and 3) has the bigger impact under the high load.
It was ludicrous to process same things many times.
On 1/5/07, Yoav Shapira <[EMAIL PROTECTED]> wrote:
It's also nice to have unbloated software. We don't need three
Valves
that do the same thing, and actually we shouldn't even need two: one
should suffice. Maybe it's Takayuki's new one.
I'd like to integrate these Valves, too.
But my modification was a little big, so I made it as another Valves.
I think my Valve has the same function AccessLogValve has.
I will make a patch on the trunk of AccessLogValve if you want.
On 1/5/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:
Not bad, the pattern processing is very cheap (that's the only
addition,
basically), so it's the same performance as the fast valve. I like
it.
I appreciate your comment.
Thanks,
-Takayuki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
