- From: Daniel W. Connolly <connolly@beach.w3.org>
- Date: Thu, 06 Jul 1995 16:16:25 -0400
- To: Chuck Shotton <cshotton@biap.com>
- Cc: Jeffrey Mogul <mogul@pa.dec.com>, Alex Hopmann <hopmann@holonet.net>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
In message <v02120d02ac21d6eccd15@[198.64.246.22]>, Chuck Shotton writes: > >The last thing I want to do with a resource-constrained server is >re-implement the nightmare of hundreds of blinking cursors in otherwise >idle telnet sessions. The HTTP protocol is primarily connectionless >(stateless) for reasons of efficiency from the server's perspective. I >think a persuasive argument can be made for keeping a stream open while all >of the required parts of a single "page" are transmitted. Allowing an >individual to monopolize a scarce resource for longer periods of time, on >the off chance that a human might select another link to your site from the >page he just received, IS irresponsible. Anybody from the MIT TechInfo project around? I read one of their papers one time -- or maybe it was just a random posting that sounded good. Anyway, they had a large body of real data that suggested some nearly optimal time limit for TCP connections in their information system. 20 seconds rings a bell. Clearly, this needs to be a policy set by the information provider. Many of them -- most or all in the near term -- will close the connection immediately after each request. But folks that want to optimize perceived performance will go for longer timeouts. A heuristic like "less than 10 seconds will be a noticeable performance loss for your readers, and more than 50 (or 100) seconds will probably _not_ be a noticeable performance increase" is probably a good thing. Dan
Received on Thursday, 6 July 1995 13:19:04 UTC