> >>>Also, an idling client generally does not keep a connection open
> >>>to the Apache server. So if you have 800 people changing webpage
> >>>once a minute, you're really only going to be handling 15
> >>>processes at the same time.
> >>>
> >>This assumes you're not using KeepAlives, in which case an httpd
> >>child will wait around for KeepAliveTimeout seconds before serving
> >>other clients.
> >
> >Hmm, the default is 15 seconds. So if you are expecting lots of
> >short transactions, this could blow out your connection count to
> >200 or so. Depending on the situation I'd be tempted to drop that
> >down since the costs of setting up connections is much lower on a
> >LAN than over the internet (assuming he's running on a LAN).
> >
> >But a valid point notheless...
>
> KEepAlives must be enabled on client and server, Netscape 4 doesn't
> do keep-alives, NS6 I don't know, mosta ll versions of MSIE do keep
> alive if the server allows them.
There is no point to keep alives with a value greater than 1 second
unless all of your clients are over high latency links and _want_ them
on because of the number of images on a site.
This is getting pretty OT, but if you're using persistent database
connections, turning keep alives OFF is an absolute must. The only
reason to turn keep alives on is if you're trying to avoid the
overhead of bringing up and tearing down a TCP connection, which, with
props to most OS implementations, is very quick and efficient (save
HPUX, AIX, and Solaris... errr.. Slowaris). Expense of bringing up a
new TCP connection versus the number of requests that could be served
while _WAITING_ for the client to send its next HTTP request. No
brainer: keep alives, in almost every context/situation, must die a
painful and agonizing death. -sc
PS The only instance where someone could reasonably justify using keep
alives would be for an Intranet site with 50+ images per HTML
page... and even then, that's a non-issue given that browsers cache
the images after the 1st page load.
--
Sean Chittenden