- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Tue, 20 Dec 94 16:15:10 PST
- To: John Franks <john@math.nwu.edu>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, mogul@pa.dec.com
I have some some serious reservations about this. Perhaps someone
more knowledgeable about TCP/IP can alleviate them. Won't this
maintain the connection during the entire time that a client takes to
download and layout and display a document containing containing
mulitple images? This could represent a substantial amount of time
over a slow link. For a heavily loaded server, say like HotWired,
keeping the connection open during the entire time a user enters her
password and multiple images in a document are downloaded over a 14.4
link could add up to quite a bit of time. I would think that the
maximum number of allowed connections would be exceded quite often.
There would probably be a large number of timeouts each one representing
almost 10 seconds of unused connect time.
Other people have already responded, pointing out the basic
misunderstanding here about TCP connection state records.
I just wanted to address the "maximum number of connections" issue.
Even with persistent-connection HTTP, you never need to support
any more simultaneous connections than with vanilla HTTP. However,
the more connections you have available, the better the performance.
One caveat: my simulations assumed that the request rate would
remain constant even if the UPP improved (because responses would
be received faster, using persistent connections). This could
actually lead to a slightly higher request rate. On the other hand,
I would assume it would cause a higher request rate from exactly
those clients that have open connections, so it would not actually
increase the number of processes needed to respond to those requests.
-Jeff
Received on Tuesday, 20 December 1994 16:25:13 UTC