On 11/15/2011 12:33 PM, Stefan Fritsch wrote:
On Tuesday 15 November 2011, Paul Querna wrote:
On Tue, Nov 15, 2011 at 9:17 AM, Stefan Fritsch<[email protected]>
wrote:
On Tue, 15 Nov 2011, [email protected] wrote:
Author: pquerna
Date: Tue Nov 15 15:49:19 2011
New Revision: 1202255
URL: http://svn.apache.org/viewvc?rev=1202255&view=rev
Log:
disable mod_reqtimeout if not configured
Why that? We have just changed the default to be enabled in
r1199447 and several developers at the hackathon agreed to this
change.
Didn't know it was discussed in depth at the hackathon, and there
wasn't any discussion on the list....
It showed up quite quickly in my profiling of the Event MPM,
because every pull/push on the filters would cause a
apr_time_now() call.
I don't really like that just by loading the module, it changes the
behavior and performance of the server so drastically.
It only acts on reads from the client. Normal non-POST requests arrive
in one or two packets, which would mean approx. 3 additional
apr_time_now calls per request. I haven't done benchmarks, but I can't
imagine that this has a drastic impact on performance. And if it costs
1-2%, then that's a small cost compared to the impact of slowloris
type attacks which eat lots of memory.
The general intention of the recent changes in default configs and
module selection/loading was to make it easier to only load those
modules that are really needed, have a reasonable default config, and
have the compiled-in default values be the same as those in the
example config files.
Which means, build by default, disable by default. I think that keeps
everyone happy. When abuse arrives, it's trivial to load.
