keepalivetimeout and 2.2 configs

[Rich Bowen <rb...@rcbowen.com>]

While the 2.2 config files are somewhat in flux, I thought I'd bring up
the topic of KeepAliveTimeout. The default config files have this set to
15 seconds. As far as I remember, it is set that way due to some
possibly-scientific survey that said that "average" web users click ever
15 seconds. Even assuming that that was true at some point, it seems to
me that the main reason for keepalive is for the files (images, css)
associated with a single page, not for retaining a connection between
pages. In that case, I would think that 2, or perhaps 3 seconds, would
be more than sufficient.

On the more practical non-gut-feeling side, I've found consistently that
changing KeepAliveTimeout from 15 to 3 immediately, and drastically,
reduces server load on busy servers, where a significant percentage of
the child processes are in Keepalive mode most of the time.

See http://httpd.apache.org/server-status for an example. Note that
(most of the time) most of the processes are in K. I'm willing to bet
that reducing KeepAliveTimeout to 2 or 3 will drop the number of child
processes significantly, reduce overall server load, and improve server
performance under peak traffic.

Thoughts?

--Rich

Re: keepalivetimeout and 2.2 configs

[Joshua Slive <jo...@slive.ca>]

On Sun, 10 Apr 2005, Rich Bowen wrote:
> See http://httpd.apache.org/server-status for an example. Note that
> (most of the time) most of the processes are in K. I'm willing to bet
> that reducing KeepAliveTimeout to 2 or 3 will drop the number of child
> processes significantly, reduce overall server load, and improve server
> performance under peak traffic.

Oh, and by the way, I don't really agree with this.  KeepAliveTimeout on 
www.apache.org is currently 5.  Reducing it would only help performance if 
we are hitting MaxClients.  And since we don't have a memory problem, if 
we are hitting MaxClients we should be raising MaxClients, not reducing 
KeepAliveTimeout.  Connections in KeepAlive aren't using any resources 
except memory, so messing with this only helps memory-constrained servers 
(which, admittedly, are not uncommon).

Joshua.

Re: keepalivetimeout and 2.2 configs

[Joshua Slive <jo...@slive.ca>]

Nick Kew wrote:
>>- This should be solved in the code-default, not the config-file
>>default. The directive will not exist in the default config file in
>>2.1.next.
> 
> 
> Aaargh!  That *will* upset admins who *know* from experience that
> they *need* to reduce it.

I'm not sure what you think I meant here, but experienced admins can 
still configure this however they want (or they can just use their 
config file from 2.0, which should work with minimal changes).  All I am 
saying is that the directive is not present in the *default* config 
file, and therefore will take on its code-default value.

Joshua.

Re: keepalivetimeout and 2.2 configs

[Nick Kew <ni...@webthing.com>]

Joshua Slive wrote:
> 
> On Sun, 10 Apr 2005, Rich Bowen wrote:
>> On the more practical non-gut-feeling side, I've found consistently that
>> changing KeepAliveTimeout from 15 to 3 immediately, and drastically,
>> reduces server load on busy servers, where a significant percentage of
>> the child processes are in Keepalive mode most of the time.

Yes, that seems to be rather common in busy servers, and applies to
worker as well as prefork.

> - It's always a trade-off between the memory used by the idle worker and
> the performance cost of setting up and tearing down connections.
> Different sites care about those resources to different degrees.

Indeed.  But something like 4 seconds seems to work well in real life.
It is essentially about fetching included contents on a persistent
connection.

> - This is highly mpm-dependent.  For threaded mpms, the cost of an idle
> worker is lower.

But nevertheless critical on some busy servers.

>	  For the new event mpm, the problem goes away entirely,
> and you are better off with a much *higher* timeout.  So pushing event
> up the list of recommended mpms would be the best way to solve this.

Indeed.  This needs to be documented more completely, too.  I've got
something here I can probably contribute if I can find the right place
to insert it in the existing docs.

>	  It
> would be nice if other mpms were a little more flexible about KeepAlive
> policy, like by lowering the timeout when you get near MaxClients.

Indeed.  Configurable Min/Max for Keepalive?

> - This should be solved in the code-default, not the config-file
> default. The directive will not exist in the default config file in
> 2.1.next.

Aaargh!  That *will* upset admins who *know* from experience that
they *need* to reduce it.

> - 2-3 seconds seems too short for modem or high-latency connections. 
> 5-10 seems more in the ballpark.

AFAIK the highest-latency connections in significant numbers in the
wild come from mobile phones, and can be around 4 secs for new (not
keepalive) connections.

But it's definitely something that a server admin wants some
control over.

-- 
Nick Kew

Re: keepalivetimeout and 2.2 configs

[Joshua Slive <jo...@slive.ca>]

On Sun, 10 Apr 2005, Rich Bowen wrote:

> While the 2.2 config files are somewhat in flux, I thought I'd bring up
> the topic of KeepAliveTimeout. The default config files have this set to
> 15 seconds. As far as I remember, it is set that way due to some
> possibly-scientific survey that said that "average" web users click ever
> 15 seconds. Even assuming that that was true at some point, it seems to
> me that the main reason for keepalive is for the files (images, css)
> associated with a single page, not for retaining a connection between
> pages. In that case, I would think that 2, or perhaps 3 seconds, would
> be more than sufficient.
>
> On the more practical non-gut-feeling side, I've found consistently that
> changing KeepAliveTimeout from 15 to 3 immediately, and drastically,
> reduces server load on busy servers, where a significant percentage of
> the child processes are in Keepalive mode most of the time.
>
> See http://httpd.apache.org/server-status for an example. Note that
> (most of the time) most of the processes are in K. I'm willing to bet
> that reducing KeepAliveTimeout to 2 or 3 will drop the number of child
> processes significantly, reduce overall server load, and improve server
> performance under peak traffic.

I tend to agree that 15 is too high for prefork, but a couple notes:

- It's always a trade-off between the memory used by the idle worker and 
the performance cost of setting up and tearing down connections. 
Different sites care about those resources to different degrees.

- This is highly mpm-dependent.  For threaded mpms, the cost of an idle 
worker is lower.  For the new event mpm, the problem goes away entirely, 
and you are better off with a much *higher* timeout.  So pushing event up 
the list of recommended mpms would be the best way to solve this.  It 
would be nice if other mpms were a little more flexible about KeepAlive 
policy, like by lowering the timeout when you get near MaxClients.

- If you make KeepAlive less available, you encourage client authors to 
setup more connections to the server, which will cost way more.

- This should be solved in the code-default, not the config-file default. 
The directive will not exist in the default config file in 2.1.next.

- 2-3 seconds seems too short for modem or high-latency connections.  5-10 
seems more in the ballpark.

Joshua.

Re: keepalivetimeout and 2.2 configs

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 07:20 AM 4/11/2005, Bill Stoddard wrote:
>Rich Bowen wrote:
>>While the 2.2 config files are somewhat in flux, I thought I'd bring up
>>the topic of KeepAliveTimeout. The default config files have this set to
>>15 seconds. As far as I remember, it is set that way due to some
>>possibly-scientific survey that said that "average" web users click ever
>>15 seconds. Even assuming that that was true at some point, it seems to
>>me that the main reason for keepalive is for the files (images, css)
>>associated with a single page, not for retaining a connection between
>>pages.

++1 on your interpretation, Rich.  We aren't waiting on the same user
to click around (and waste a socket) - we are trying to stream all
the info from a single hit that we can on the fewest pipes.

>> In that case, I would think that 2, or perhaps 3 seconds, would
>>be more than sufficient.
>>Thoughts?
>>--Rich
>
>Joshua picked the important nits.. I am generally +1 on setting default KA timeout from 15 to 5.

+1 for 5 seconds, here.  Should handily deal with even slower page
loads and composition.

Re: keepalivetimeout and 2.2 configs

[Bill Stoddard <bi...@wstoddard.com>]

Rich Bowen wrote:
> While the 2.2 config files are somewhat in flux, I thought I'd bring up
> the topic of KeepAliveTimeout. The default config files have this set to
> 15 seconds. As far as I remember, it is set that way due to some
> possibly-scientific survey that said that "average" web users click ever
> 15 seconds. Even assuming that that was true at some point, it seems to
> me that the main reason for keepalive is for the files (images, css)
> associated with a single page, not for retaining a connection between
> pages. In that case, I would think that 2, or perhaps 3 seconds, would
> be more than sufficient.
> 
> On the more practical non-gut-feeling side, I've found consistently that
> changing KeepAliveTimeout from 15 to 3 immediately, and drastically,
> reduces server load on busy servers, where a significant percentage of
> the child processes are in Keepalive mode most of the time.
> 
> See http://httpd.apache.org/server-status for an example. Note that
> (most of the time) most of the processes are in K. I'm willing to bet
> that reducing KeepAliveTimeout to 2 or 3 will drop the number of child
> processes significantly, reduce overall server load, and improve server
> performance under peak traffic.
> 
> Thoughts?
> 
> --Rich

Joshua picked the important nits.. I am generally +1 on setting default KA timeout from 15 to 5.

Bill