On Wednesday 16 November 2011, Paul Querna wrote: > On Wed, Nov 16, 2011 at 2:44 AM, Rainer Jung <rainer.j...@kippdata.de> wrote: > > On 15.11.2011 20:57, Jeff Trawick wrote: > >> On Tue, Nov 15, 2011 at 2:32 PM, William A. Rowe Jr. > >> > >> <wr...@rowe-clan.net> wrote: > >>> 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<s...@sfritsch.de> > >>>> > >>>> wrote: > >>>>>> On Tue, 15 Nov 2011, pque...@apache.org 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. > >> > >> Timeout 60 isn't nearly as bad as the old Timeout 300 that is > >> probably still in wide use, but mod_reqtimeout can provide a > >> much more reasonable out of the box configuration. I think we > >> should keep it in place by default. > > > > +1 > > What I am really opposed to is that the LoadModule causes such a > degradation in performance.
In my quick (and maybe not that accurate) tests, the penalty caused by mod_reqtimeout (1.4%) was smaller than the penalty of not having BufferedLogs on (2.1%). But there is no question that the current default 'BufferedLogs off' is better for the majority of users, just the same as having reqtimeout enabled is better for the majority of users. Actually, RequestReadTimeout should probably be into the core, but none got around to moving it. > I am 100% +1 to adding conf commands to the default configuration > in the httpd.conf, but what I do not like is that having just a > LoadModule with nothing else causes reqtimeout to do work. It is > too trivial for people to have accidental load modules in many > distros. There are other cases where just loading a module can have much larger influence on the performance (look at AP_AUTH_INTERNAL_PER_URI versus AP_AUTH_INTERNAL_PER_CONF in the auth hooks). We need to educate users that they should disable modules that they don't need.
