Re: MPM-Event, renaming MaxClients, etc.
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 s...@sfritsch.de mailto:s...@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.
On Mon, Jun 20, 2011 at 7:22 PM, Roy T. Fielding field...@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 s...@sfritsch.de mailto:s...@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.
On Tue, 21 Jun 2011, Jeff Trawick wrote: On Mon, Jun 20, 2011 at 7:22 PM, Roy T. Fielding field...@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.
On Sun, Jun 19, 2011 at 8:49 AM, Stefan Fritsch s...@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
Re: MPM-Event, renaming MaxClients, etc.
On 6/20/2011 9:07 AM, Greg Ames wrote: On Sun, Jun 19, 2011 at 8:49 AM, Stefan Fritsch s...@sfritsch.de mailto:s...@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.
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 s...@sfritsch.de mailto:s...@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.
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 s...@sfritsch.de mailto:s...@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.
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 s...@sfritsch.de mailto:s...@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.
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 s...@sfritsch.de mailto:s...@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.
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.
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.
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 s...@sfritsch.de mailto:s...@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.
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.
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
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
