httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <>
Subject Re: cvs commit: httpd-2.0/docs/manual/mod mod_log_config.html
Date Thu, 10 Jan 2002 02:49:53 GMT
Joshua Slive wrote:

>>-----Original Message-----
>>From: Ian Holsman []
>>>> new option LogExcludeByType
>>>> main use is so that you can ignore logging images
>>>Hmmm... I'm pretty close to a -1 on this one.  We were just discussing
>>>simplifying the logging directives, while this will compilicate
>>them for no
>>>good reason.  Can you justify why this is an improvement over
>>> and
>>> ?
>>I guess the answer is mainly a speed one.
>>setenvif is a regex call while this isn't.
>Can you really benchmark speed differences between the two?

Yes.  And the difference is quite large.  The cost of a single regex
comparison isn't too bad compared to the cost of a single hash table
lookup (about 300 cycles for the regex match vs ~100 for the hash table
lookup on a Sparc, based on our most recent round of profiling data).
The problem is that mod_setenvif does a *lot* of regex operations per
request.  Specifically, it does O(N) regex comparisons for N SetEnvIf
rules, compared to O(1) hash table lookups per request for LogExcludeByType.
At least in its present form, mod_setenvif simply isn't a scalable

I'm mildly alarmed that we're actually advocating it as a general-purpose
solution in the documentation URLs listed above; we really should warn
readers that the processing cost scales linearly with the number of rules.

>Wouldn't we be better off designing a fast-path for mod_setenvif that could
>take something like
>SetEnvIf REQUEST_URI \.gif$
>and test it without a regex?  (I admit that I don't know how much work that
>would be.)

That would work if you could also reduce the O(N) comparisons per request
to O(1)...without that additional improvement, though, it still won't 
scalewell as the number of SetEnvIf rules increases.


View raw message