|
>>>>> On Thu, 3 May 2001 01:31:44 +0000 (GMT), Julian Anastasov <ja@xxxxxx>
>>>>> said:
> Hello,
> On 2 May 2001, Andreas J. Koenig wrote:
>> Let's rewrite the above formula:
>>
>> MaxClients / KeepAliveTimeout
> This is more correct but it is too pesimistic, though :)
OK, I exaggerated a little:-)
>> denotes the number of requests that can be satisfied if all clients
>> *send* a keepalive header (I think that's "Connection: keepalive") but
>> *do not actually use* the kept-alive line. If they actually use the
>> kept-alive line, you can serve more, of course.
> The browsers are not such evils :) They close the connection
> after use.
So why does the server not take note? My experience shows that the
apache keeps waiting till keepalivetimeout is reached. No matter if I
test with Netscape or Internet Explorer.
>> This may have a variety of reasons. Try this: start apache with the -X
>> flag, so it will not fork children and set the keepalivetimeout to 60.
>> Then load a page from it with Netscape that contains many images. You
>> will notice that many pictures arive quickly and a few pictures arive
>> after a long, long, long, looooong time.
> Yes, same as when the browser uses one connection.
Erm, no. If you turn KeepAlive Off and repeat the test (with a clean
cache, of course), then the whole experiment takes just a few seconds
and not several minutes.
>>
>> > KeepAlive Off can be useful for banner serving but a short
>> > KeepAlive period has its advantages in some cases with long rtt where
>> > the connection setups costs time and because the modern browsers are
>> > limited to the number of connections they open. Of course, the default
>> > period can be reduced but its value depends on the served content,
>> > whether the client is expected to open many connections for short
>> > period or just one.
>>
>> When the browser parses the incoming HTML stream and sees the first
>> IMG tag it will fire off the first IMG request. It will do likewise
>> for the next IMG tag. At some point it will reach an IMG tag and be
>> able to re-use an open keepalive connection. This is good and does
>> save time. But if a whole second has passed after a keepalive request
>> it becomes very unlikely that this connection will be re-used ever, so
>> 15 seconds is braindead. One or two seconds is OK.
> May be 5, it depends on how fast are the clients to send the
> next request over the same connection. You can see longer times for
> TCP connections with large windows or, for example, when the server
> sends the data but the kernel still transmits the datagrams. At HTTP
> protocol level the server can't receive ack when all data is received
> in the client socket, so you have to add more seconds to the KeepAlive
> interval to account this delay for the transfer. It also depends on the
> object size, on the used socket write space in the kernel and may be
> on other things. So, for clients downloading 16K image with 2K/sec
> you will need 8 seconds keep alive timeout because this time period
> may be starts after succeding write(client_fd, buf, 16384)=16384
> operation in the server, not sure.
These are very interesting thoughts. Good point! But all depends on
what you try to achieve. Sure, if a customer has a congested link, a
long keepalive will help him a little bit, but then the overhead for
opening a new connection is relatively neglectable. We have a lot of
customers sitting at high speed connections, hammering on our servers.
While one customer on a slow link receives a single page, these folks
receive 100.
Anyway, we solved the problem by installing a squid accelerator which
handles the keepalive connections much more intelligently than our
apaches (it runs in a single select loop, so can handle thousands of
connections with a tiny overhead).
For the apache-only configuration, it maybe boils down to estimate the
download time for the average customer. I haven't thought of that
before. Thanks for the insight!
--
andreas
|
