I agree with the response that you need to do some statistics
gathering to try to accurately isolate the cause of your problems.
I *don't* agree with the other suggestion that was made to UP the
keepalive to 15-20 seconds (the default that apache comes with is 5,
IIRC).
Here's why: Assuming that you have one server serving both modperl
and image requests, those keepalives are tieing up a large, heavy
server, doing nothing but waiting for a new potential request.
("Right on" to the suggestion to try to get those image requests
directed to a separate web server which can be separately tuned...)
I actually have a snippet from a writeup I did for a client who was
experiencing high server loads about a year ago, here's what I wrote
then:
-------------------------
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
In my experience, the performance killer here is KeepAliveTimeout.
This defines the number of seconds that a server child will wait for
a client to send additional requests over an already-open connection
before closing the socket and making itself available to service
other clients' requests - this default value is way too high.
Where keep alives work well is in situations where an bunch of
requests are likely to occur one after another - such as what's
typical when fetching an HTML page containing dozens or more image
files served from the same server. Keeping the connection open and
serving the HTML page and many of its images without tearing down
and re-establishing the connection makes sense here.
On a heavily loaded server however, having a server hang around
idle, tieing up resources for this long waiting for a new request is
wasteful. It's much less of a drain to get that process back into
the pool of available child servers as quickly as possible, allowing
it to service other requests. This is especially true when you
realize that the typical browser tries to optimize its transfers by
opening up to four separate TCP connections to the server when
loading a page's components, thereby tieing up four child servers.
Thinking of the typical client request, where an HTML page is
fetched and its referenced images are then also requested, it makes
sense to me that these requests are going to come very quickly. It
certainly seems reasonable to expect that subsequent component
requests will occur in under a second, and that if more than a
second elapses without a request, then it's likely that all of the
components have been read and the user is likely now reading the
page.
This being said, I like to set KeepaliveTimeout to its lowest value
- '1'. In my not-very-scientific tests, this seems to be the best
value to balance the latency experienced by any one client with the
overall performance of the server.
-------------------------
Lowering the keepalive did the trick for these people.
Disclaimer: I don't have any carefully gathered evidence that this
idea (setting keepalive to '1') will do what I postulate it should
above. But back when I had access to a large website, with lots of
bandwidth, we did some empirical tests that certainly seemed to
confirm this idea -- setting a smaller keepalive resulted in better
'ab' numbers. I *did* though send a message to the Apache group, and
got a response from Mark Slemko which pointed towards this as a
possible issue.
A couple of other suggestions: Set Timeout to a lower value (maybe
30?) and decrease MaxClients using the techniques described in Stas'
guide.
Also, I agree that given the network latency of your site, you might
be better off setting the keepalives to a higher value than
what I recommend in the above (maybe 2?)
I'd love hear others' thoughts on this -- ideas for tuning web
servers is a fun topic, afaic...!
<Steve>
On Thu, 11 Oct 2001, Rafiq Ismail wrote:
> I know this is a bit off topic, but I could use some immediate advise on
> server config?
>
>
> Got a server which is getting hit really bad.
> Have to keep it up. I've got:
>
>
> P Timeout 300
>
> # Keepalive, better on this server...
> KeepAlive On
> MaxKeepAliveRequests 100
> KeepAliveTimeout 5
>
> # performance services
> MinSpareServers 5
> MaxSpareServers 50
> StartServers 20
> StartServers 20
> MaxClients 250
>
>
> Pings look like:
>
> 64 bytes from x.x.x.x: icmp_seq=0 ttl=244 time=1069.3 ms
> 64 bytes from x.x.x.x: icmp_seq=1 ttl=244 time=984.8 ms
> 64 bytes from x.x.x.x: icmp_seq=2 ttl=244 time=1138.9 ms
> 64 bytes from x.x.x.x: icmp_seq=3 ttl=244 time=1567.1 ms
> 64 bytes from x.x.x.x: icmp_seq=4 ttl=244 time=1622.3 ms
> 64 bytes from x.x.x.x: icmp_seq=5 ttl=244 time=1382.8 ms
> 64 bytes from x.x.x.x: icmp_seq=6 ttl=244 time=1145.5 ms
> 64 bytes from x.x.x.x: icmp_seq=7 ttl=244 time=1065.6 ms
> 64 bytes from x.x.x.x: icmp_seq=8 ttl=244 time=1133.6 ms
>
>
>
> There are some really graphic intensive pages here, however I'm not sure
> if Keep alive is good when there's lots of contention for pages. Should
> I:
> i) disable keep alive?
>
> ii) reduce the keep alive time out ?
>
> iii) up my number for max spare servers? Since i've not maxed out
> on load or memory, perhaps more idle servers will reduce the contention
> for apache children? My intutition is that since the server is obviously
> in trouble, resource wise, perhaps increasing the number of daemons will
> relieve the load. Not sure. It's a big box. Any ideas?
>
> iv) Something else?
>
>
> I'd appreciate some suggestions.
>
> Thanks,
>
> R.
>
>
>
>
>
>
>
>
>
>
--
Steve Reppucci [EMAIL PROTECTED] |
Logical Choice Software http://logsoft.com/ |
=-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
