httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: Apache 1.2b7-dev performance
Date Sun, 09 Feb 1997 20:45:08 GMT
On Sun, 9 Feb 1997, Ben Laurie wrote:

> Hang on, this is getting more and more tenuous. You're saying that we should
> use lingering close because under some circumstances a broken client (don't
> forget there is a clean way to close a keepalive under HTTP/1.1) _may_ get an

What exactly is that clean way?  'Connection: close' is not enough in this
case both because the server can't send it on a timeout and because it
will not necessarily make it to the client at the right time for the
client to figure out it should stop sending requests. 

> error, and _may_ consequently display an error. And then, oh my god, the user
> would have to click a link for a second time. And for this, we are supposed to
> take a 20% or worse performance hit, and force everyone to reboot every two
> days, and make every major Unix vendor patch their TCP/IP stack?

You are exaggerating a wee bit.

> If all that is required to fix this is a client that retries silently, I'd say
> we should let them fix the clients. Even if they don't it isn't the end of the
> world.

Retries silently _without_ using persistent connections.  You are saying
that because it is _possible_ for the client to be written so it works
around the problem by not using persistent connections the client must do
that or it is broken?  Sorry, can't agree.

Note that the client MUST not automatically retry on things such as POSTs
so the user will get an error no matter what the client does.

You may not find it a big deal for some percentage of connections to fail
due to a known problem that has a fix, but I do especially considering
that it may become a very significant percent of connections depending on
client implementations.

The reason why all this is "may" and "could" is because there are no
common client implementations to test with . 

View raw message