Joshua Slive wrote: >>-----Original Message----- >>From: Ian Holsman [mailto:[EMAIL PROTECTED]] >> > >>>> 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 >>>http://httpd.apache.org/docs/logs.html#conditional and >>>http://httpd.apache.org/docs/env.html#examples ? >>> >>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 solution. 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. --Brian
