You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Stefan Fritsch <sf...@sfritsch.de> on 2011/06/19 14:49:31 UTC
MPM-Event, renaming MaxClients, etc.
Hi,
I have just commited some significant improvements in how MPM reacts
when it runs out of workers (sorry for the big diff). If the number of
connections of a process is above
threads_per_child + WORKER_OVERCOMMIT * (idle_workers - 1)
or if all workers are busy, we don't accept new connections in that
process. Such a dynamic connection limit is necessary because we may
have both async and non-async (ssl) connections.
WORKER_OVERCOMMIT is fixed at 2 at the moment, but should of course be
a config option. I think this may already be enough to tune MPM event
to some specific setup. For example, the value 2 seems ok if the
server serves some large files to slow clients, i. e. the workers will
block for some time during write completion because of disk seeks. If
a server mainly serves small files or has all files in RAM, a larger
value may be better. Does anyone have a suggestion for a good name for
this option? AsyncWorkerThreadFactor?
Speaking about config options, I think that MaxClients should be
renamed to MaxWorkers, because it limits the number of worker threads,
not the number of clients. As with the MaxRequestsPerChild ->
MaxConnectionsPerChild rename, we would still accept the old name with
a warning. Thoughts?
There are still quite a few improvements possible in the mpm event
code, but I don't think any of these are blockers for the next beta:
- It is still possible to stall async connections by making lots of
ssl connections to that process. Probably a process should always keep
one worker in reserve for async work.
- Sometimes, the state 'C' is not cleared in the scoreboard after the
connection is closed.
- I think connection_count doesn't need to be accessed atomic anymore.
- Probably a lot of other optimizations.
Cheers,
Stefan
Re: MPM-Event, renaming MaxClients, etc.
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Tuesday 21 June 2011, Daniel Ruggeri wrote:
> On 6/20/2011 4:48 PM, William A. Rowe Jr. wrote:
> > On 6/20/2011 4:36 PM, Stefan Fritsch wrote:
> >> On Monday 20 June 2011, Roy T. Fielding wrote:
> >>> On Jun 20, 2011, at 12:01 PM, Stefan Fritsch wrote:
> >>>> ....
> >>>
> >>> That kind of last-minute change is going to kill people trying
> >>> to upgrade from 2.2 to 2.4 with a shared config. We should
> >>> make MaxRequestWorkers an alias for MaxClients in a released
> >>> 2.2.x
> >>
> >> I think you missed that MaxClients still works in 2.4 (albeit
> >> with a warning on startup). So I don't think it's such a big
> >> deal.
> >
> > Perhaps we should lower the severity from warning to info? Not
> > every admin needs constant reminders while they are running 2.2
> > and 2.4 from a single config.
>
> +1... warning seems a bit dire for the circumstances.
Sounds reasonable. r1137813
Re: MPM-Event, renaming MaxClients, etc.
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Tue, 21 Jun 2011, Jeff Trawick wrote:
> On Mon, Jun 20, 2011 at 7:22 PM, Roy T. Fielding <fi...@gbiv.com> wrote:
>> My point wasn't the warning, actually, but rather the fact that a config
>> that uses MaxRequestWorkers (instead of MaxClients) will abort an instance
>> of httpd 2.2.x. Hence, a person upgrading to 2.4.x will get tripped up
>> if they try to do so incrementally with shared config files across
>> many web servers, unless they happen to notice that this change is
>> merely cosmetic and they keep MaxClients instead.
>>
>> For a trivial improvement like this, we should make it easier on admins
>> by backporting the alias to 2.2.x (even if we do not use it on 2.2.x).
>>
>> ....Roy
>
> Many (most?) admins will be encountering other one-way changes (e.g.,
> AcceptMutex,SSLMutex -> Mutex). Using one config for both 2.2.x and
> 2.4.x is going to be an IfVersion exercise.
>
> I think they'd be better served with an IfVersion cheatsheet at the
> bottom of http://httpd.apache.org/docs/trunk/upgrading.html than with
> addressing a subset of changes by adding compatibility code to 2.2.x.
I also can't imagine any config running without changes. Think of
mod_access_compat now being required for Allow/Deny/Satisfy/Order.
I am not against backporting things that make upgrading easier. But we
should wait with that until 2.4.0 is out and then see which changes would
actually make sense.
Cheers,
Stefan
Re: MPM-Event, renaming MaxClients, etc.
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, Jun 20, 2011 at 7:22 PM, Roy T. Fielding <fi...@gbiv.com> wrote:
> On Jun 20, 2011, at 2:48 PM, William A. Rowe Jr. wrote:
>> On 6/20/2011 4:36 PM, Stefan Fritsch wrote:
>>> On Monday 20 June 2011, Roy T. Fielding wrote:
>>>> On Jun 20, 2011, at 12:01 PM, Stefan Fritsch wrote:
>>>>> On Monday 20 June 2011, William A. Rowe Jr. wrote:
>>>>>> On 6/20/2011 9:07 AM, Greg Ames wrote:
>>>>>>> On Sun, Jun 19, 2011 at 8:49 AM, Stefan Fritsch <sf@sfritsch.de
>>>>>>> <ma...@sfritsch.de>>
>>>>>>>
>>>>>>> wrote:
>>>>>>> Speaking about config options, I think that MaxClients
>>>>>>> should be renamed to MaxWorkers, because it limits the
>>>>>>> number of worker threads, not the number of clients. As
>>>>>>> with the MaxRequestsPerChild -> MaxConnectionsPerChild
>>>>>>> rename, we would still accept the old name with a warning.
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> +1. That's more accurate for sure, and more important when you
>>>>>>> loose the 1:1 thread:connection ratio.
>>>>>>
>>>>>> Can we call this MaxRequestWorkers, now that we have different
>>>>>> sorts of workers living in the same process?
>>>>>
>>>>> Good point. Committed as r1137744
>>>>
>>>> That kind of last-minute change is going to kill people trying to
>>>> upgrade from 2.2 to 2.4 with a shared config. We should make
>>>> MaxRequestWorkers an alias for MaxClients in a released 2.2.x
>>>
>>> I think you missed that MaxClients still works in 2.4 (albeit with a
>>> warning on startup). So I don't think it's such a big deal.
>>
>> Perhaps we should lower the severity from warning to info? Not every
>> admin needs constant reminders while they are running 2.2 and 2.4 from
>> a single config.
>
> My point wasn't the warning, actually, but rather the fact that a config
> that uses MaxRequestWorkers (instead of MaxClients) will abort an instance
> of httpd 2.2.x. Hence, a person upgrading to 2.4.x will get tripped up
> if they try to do so incrementally with shared config files across
> many web servers, unless they happen to notice that this change is
> merely cosmetic and they keep MaxClients instead.
>
> For a trivial improvement like this, we should make it easier on admins
> by backporting the alias to 2.2.x (even if we do not use it on 2.2.x).
>
> ....Roy
Many (most?) admins will be encountering other one-way changes (e.g.,
AcceptMutex,SSLMutex -> Mutex). Using one config for both 2.2.x and
2.4.x is going to be an IfVersion exercise.
I think they'd be better served with an IfVersion cheatsheet at the
bottom of http://httpd.apache.org/docs/trunk/upgrading.html than with
addressing a subset of changes by adding compatibility code to 2.2.x.
Re: MPM-Event, renaming MaxClients, etc.
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 6/20/2011 6:22 PM, Roy T. Fielding wrote:
>
> For a trivial improvement like this, we should make it easier on admins
> by backporting the alias to 2.2.x (even if we do not use it on 2.2.x).
+1
Re: MPM-Event, renaming MaxClients, etc.
Posted by Daniel Ruggeri <DR...@primary.net>.
On 6/20/2011 6:22 PM, Roy T. Fielding wrote:
> My point wasn't the warning, actually, but rather the fact that a config
> that uses MaxRequestWorkers (instead of MaxClients) will abort an instance
> of httpd 2.2.x. Hence, a person upgrading to 2.4.x will get tripped up
> if they try to do so incrementally with shared config files across
> many web servers, unless they happen to notice that this change is
> merely cosmetic and they keep MaxClients instead.
>
> For a trivial improvement like this, we should make it easier on admins
> by backporting the alias to 2.2.x (even if we do not use it on 2.2.x).
>
> ....Roy
+1 Sorry, I didn't catch that - good point.
--
--
Daniel Ruggeri
Re: MPM-Event, renaming MaxClients, etc.
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jun 20, 2011, at 2:48 PM, William A. Rowe Jr. wrote:
> On 6/20/2011 4:36 PM, Stefan Fritsch wrote:
>> On Monday 20 June 2011, Roy T. Fielding wrote:
>>> On Jun 20, 2011, at 12:01 PM, Stefan Fritsch wrote:
>>>> On Monday 20 June 2011, William A. Rowe Jr. wrote:
>>>>> On 6/20/2011 9:07 AM, Greg Ames wrote:
>>>>>> On Sun, Jun 19, 2011 at 8:49 AM, Stefan Fritsch <sf@sfritsch.de
>>>>>> <ma...@sfritsch.de>>
>>>>>>
>>>>>> wrote:
>>>>>> Speaking about config options, I think that MaxClients
>>>>>> should be renamed to MaxWorkers, because it limits the
>>>>>> number of worker threads, not the number of clients. As
>>>>>> with the MaxRequestsPerChild -> MaxConnectionsPerChild
>>>>>> rename, we would still accept the old name with a warning.
>>>>>> Thoughts?
>>>>>>
>>>>>> +1. That's more accurate for sure, and more important when you
>>>>>> loose the 1:1 thread:connection ratio.
>>>>>
>>>>> Can we call this MaxRequestWorkers, now that we have different
>>>>> sorts of workers living in the same process?
>>>>
>>>> Good point. Committed as r1137744
>>>
>>> That kind of last-minute change is going to kill people trying to
>>> upgrade from 2.2 to 2.4 with a shared config. We should make
>>> MaxRequestWorkers an alias for MaxClients in a released 2.2.x
>>
>> I think you missed that MaxClients still works in 2.4 (albeit with a
>> warning on startup). So I don't think it's such a big deal.
>
> Perhaps we should lower the severity from warning to info? Not every
> admin needs constant reminders while they are running 2.2 and 2.4 from
> a single config.
My point wasn't the warning, actually, but rather the fact that a config
that uses MaxRequestWorkers (instead of MaxClients) will abort an instance
of httpd 2.2.x. Hence, a person upgrading to 2.4.x will get tripped up
if they try to do so incrementally with shared config files across
many web servers, unless they happen to notice that this change is
merely cosmetic and they keep MaxClients instead.
For a trivial improvement like this, we should make it easier on admins
by backporting the alias to 2.2.x (even if we do not use it on 2.2.x).
....Roy
Re: MPM-Event, renaming MaxClients, etc.
Posted by Daniel Ruggeri <DR...@primary.net>.
On 6/20/2011 4:48 PM, William A. Rowe Jr. wrote:
> On 6/20/2011 4:36 PM, Stefan Fritsch wrote:
>> On Monday 20 June 2011, Roy T. Fielding wrote:
>>> On Jun 20, 2011, at 12:01 PM, Stefan Fritsch wrote:
>>>> ....
>>> That kind of last-minute change is going to kill people trying to
>>> upgrade from 2.2 to 2.4 with a shared config. We should make
>>> MaxRequestWorkers an alias for MaxClients in a released 2.2.x
>> I think you missed that MaxClients still works in 2.4 (albeit with a
>> warning on startup). So I don't think it's such a big deal.
> Perhaps we should lower the severity from warning to info? Not every
> admin needs constant reminders while they are running 2.2 and 2.4 from
> a single config.
>
+1... warning seems a bit dire for the circumstances.
--
--
Daniel Ruggeri
Re: MPM-Event, renaming MaxClients, etc.
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 6/20/2011 4:36 PM, Stefan Fritsch wrote:
> On Monday 20 June 2011, Roy T. Fielding wrote:
>> On Jun 20, 2011, at 12:01 PM, Stefan Fritsch wrote:
>>> On Monday 20 June 2011, William A. Rowe Jr. wrote:
>>>> On 6/20/2011 9:07 AM, Greg Ames wrote:
>>>>> On Sun, Jun 19, 2011 at 8:49 AM, Stefan Fritsch <sf@sfritsch.de
>>>>> <ma...@sfritsch.de>>
>>>>>
>>>>> wrote:
>>>>> Speaking about config options, I think that MaxClients
>>>>> should be renamed to MaxWorkers, because it limits the
>>>>> number of worker threads, not the number of clients. As
>>>>> with the MaxRequestsPerChild -> MaxConnectionsPerChild
>>>>> rename, we would still accept the old name with a warning.
>>>>> Thoughts?
>>>>>
>>>>> +1. That's more accurate for sure, and more important when you
>>>>> loose the 1:1 thread:connection ratio.
>>>>
>>>> Can we call this MaxRequestWorkers, now that we have different
>>>> sorts of workers living in the same process?
>>>
>>> Good point. Committed as r1137744
>>
>> That kind of last-minute change is going to kill people trying to
>> upgrade from 2.2 to 2.4 with a shared config. We should make
>> MaxRequestWorkers an alias for MaxClients in a released 2.2.x
>
> I think you missed that MaxClients still works in 2.4 (albeit with a
> warning on startup). So I don't think it's such a big deal.
Perhaps we should lower the severity from warning to info? Not every
admin needs constant reminders while they are running 2.2 and 2.4 from
a single config.
Re: MPM-Event, renaming MaxClients, etc.
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Monday 20 June 2011, Roy T. Fielding wrote:
> On Jun 20, 2011, at 12:01 PM, Stefan Fritsch wrote:
> > On Monday 20 June 2011, William A. Rowe Jr. wrote:
> >> On 6/20/2011 9:07 AM, Greg Ames wrote:
> >>> On Sun, Jun 19, 2011 at 8:49 AM, Stefan Fritsch <sf@sfritsch.de
> >>> <ma...@sfritsch.de>>
> >>>
> >>> wrote:
> >>> Speaking about config options, I think that MaxClients
> >>> should be renamed to MaxWorkers, because it limits the
> >>> number of worker threads, not the number of clients. As
> >>> with the MaxRequestsPerChild -> MaxConnectionsPerChild
> >>> rename, we would still accept the old name with a warning.
> >>> Thoughts?
> >>>
> >>> +1. That's more accurate for sure, and more important when you
> >>> loose the 1:1 thread:connection ratio.
> >>
> >> Can we call this MaxRequestWorkers, now that we have different
> >> sorts of workers living in the same process?
> >
> > Good point. Committed as r1137744
>
> That kind of last-minute change is going to kill people trying to
> upgrade from 2.2 to 2.4 with a shared config. We should make
> MaxRequestWorkers an alias for MaxClients in a released 2.2.x
I think you missed that MaxClients still works in 2.4 (albeit with a
warning on startup). So I don't think it's such a big deal.
Re: MPM-Event, renaming MaxClients, etc.
Posted by Issac Goldstand <ma...@beamartyr.net>.
On 21/06/2011 00:30, Roy T. Fielding wrote:
> On Jun 20, 2011, at 12:01 PM, Stefan Fritsch wrote:
>> On Monday 20 June 2011, William A. Rowe Jr. wrote:
>>> On 6/20/2011 9:07 AM, Greg Ames wrote:
>>>> On Sun, Jun 19, 2011 at 8:49 AM, Stefan Fritsch <sf@sfritsch.de
>>>> <ma...@sfritsch.de>>
>>>>
>>>> wrote:
>>>> Speaking about config options, I think that MaxClients should
>>>> be renamed to MaxWorkers, because it limits the number of
>>>> worker threads, not the number of clients. As with the
>>>> MaxRequestsPerChild -> MaxConnectionsPerChild rename, we
>>>> would still accept the old name with a warning. Thoughts?
>>>>
>>>> +1. That's more accurate for sure, and more important when you
>>>> loose the 1:1 thread:connection ratio.
>>> Can we call this MaxRequestWorkers, now that we have different
>>> sorts of workers living in the same process?
>> Good point. Committed as r1137744
> That kind of last-minute change is going to kill people trying to
> upgrade from 2.2 to 2.4 with a shared config. We should make
> MaxRequestWorkers an alias for MaxClients in a released 2.2.x
>
> ....Roy
+1
Re: MPM-Event, renaming MaxClients, etc.
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jun 20, 2011, at 12:01 PM, Stefan Fritsch wrote:
> On Monday 20 June 2011, William A. Rowe Jr. wrote:
>> On 6/20/2011 9:07 AM, Greg Ames wrote:
>>> On Sun, Jun 19, 2011 at 8:49 AM, Stefan Fritsch <sf@sfritsch.de
>>> <ma...@sfritsch.de>>
>>>
>>> wrote:
>>> Speaking about config options, I think that MaxClients should
>>> be renamed to MaxWorkers, because it limits the number of
>>> worker threads, not the number of clients. As with the
>>> MaxRequestsPerChild -> MaxConnectionsPerChild rename, we
>>> would still accept the old name with a warning. Thoughts?
>>>
>>> +1. That's more accurate for sure, and more important when you
>>> loose the 1:1 thread:connection ratio.
>>
>> Can we call this MaxRequestWorkers, now that we have different
>> sorts of workers living in the same process?
>
> Good point. Committed as r1137744
That kind of last-minute change is going to kill people trying to
upgrade from 2.2 to 2.4 with a shared config. We should make
MaxRequestWorkers an alias for MaxClients in a released 2.2.x
....Roy
Re: MPM-Event, renaming MaxClients, etc.
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Monday 20 June 2011, William A. Rowe Jr. wrote:
> On 6/20/2011 9:07 AM, Greg Ames wrote:
> > On Sun, Jun 19, 2011 at 8:49 AM, Stefan Fritsch <sf@sfritsch.de
> > <ma...@sfritsch.de>>
> >
> > wrote:
> > Speaking about config options, I think that MaxClients should
> > be renamed to MaxWorkers, because it limits the number of
> > worker threads, not the number of clients. As with the
> > MaxRequestsPerChild -> MaxConnectionsPerChild rename, we
> > would still accept the old name with a warning. Thoughts?
> >
> > +1. That's more accurate for sure, and more important when you
> > loose the 1:1 thread:connection ratio.
>
> Can we call this MaxRequestWorkers, now that we have different
> sorts of workers living in the same process?
Good point. Committed as r1137744
Re: MPM-Event, renaming MaxClients, etc.
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 6/20/2011 9:07 AM, Greg Ames wrote:
>
> On Sun, Jun 19, 2011 at 8:49 AM, Stefan Fritsch <sf@sfritsch.de <ma...@sfritsch.de>>
> wrote:
>
> Speaking about config options, I think that MaxClients should be
> renamed to MaxWorkers, because it limits the number of worker threads,
> not the number of clients. As with the MaxRequestsPerChild ->
> MaxConnectionsPerChild rename, we would still accept the old name with
> a warning. Thoughts?
>
> +1. That's more accurate for sure, and more important when you loose the 1:1
> thread:connection ratio.
Can we call this MaxRequestWorkers, now that we have different sorts of workers
living in the same process?
Re: MPM-Event, renaming MaxClients, etc.
Posted by Greg Ames <am...@gmail.com>.
On Sun, Jun 19, 2011 at 8:49 AM, Stefan Fritsch <sf...@sfritsch.de> wrote:
>
>
> Speaking about config options, I think that MaxClients should be
> renamed to MaxWorkers, because it limits the number of worker threads,
> not the number of clients. As with the MaxRequestsPerChild ->
> MaxConnectionsPerChild rename, we would still accept the old name with
> a warning. Thoughts?
+1. That's more accurate for sure, and more important when you loose the
1:1 thread:connection ratio.
Greg