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]
