[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [patch] TUX 2.4.2-P3 (fwd)

From: Jeffrey Mogul <mogul@pa.dec.com>

> The bottom line (in my opinion) is that the *server's* timeout should
> not be the primary mechanism for deciding when to close a connection.
> Instead, the server should strive to keep as many connections open as
> possible (within resource constraints: vanilla Apache is badly
> structured for keeping lots of connections open), and then close
> connections *as necessary* based on how long they have been idle. This
> approach adapts to the conditions of the current situation, whereas a
> fixed timeout cannot.

hm, but it might be better from a quality of implementation and
predictibility point of view to close after a fixed timeout of inactivity.
It appears to be a bit chaotic to start zapping idle connections whenever
there is resource shortage on the server. Especially if the resource
shortage is unrelated to webserving.

the other problem is how to define 'resource shortage'. What is more
important, letting client connection idle around longer, or to grow the
pagecache? There is no natural answer to this question i think, which
again calls for the easy solution: fixed timeouts.

timeouts also correlate with the URL space, eg. servers could also do
per-served-document measurement of 'likelyhood of the client requesting
another document over the same connection'. Eg. the last page of a
multi-page article is more likely to be the 'last' page requested by that
given client. This would be a form of branch-prediction - but this is
probably overkill :-)

> My memory about 408 isn't very good, but I don't think this is related
> to the persistent-connection stuff at all. [...]

indeed - the 408 reply was a brown paperbag thinko. The correct behavior
is to simply close idle connections - they are idle after all, so sending
any message can only be a waste of network bandwidth.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []