[
Lists Home |
Date Index |
Thread Index
]
On Wed, 23 Jan 2002, Mike Champion wrote:
> Stealing a page from Tim Bray's hymnal <grin>, I feel compelled to
> ask: Is there solid, empirical, profiling evidence that the TCP
> substrate of HTTP is a significant bottleneck in real web
> applications? Optimizing non-bottlenecks is a well-known
> temptation...
It's not one of the things that has to be a bottleneck - not all problems
decompose into a number of stages with bottlenecks.
Look at it this way; using a Web browser, the status bar usually tells you
as the browser goes from looking up in DNS to attempting connection to the
'sent request, waiting for reply' stage.
It spends very little time in the DNS stage, even though this involves
contacting several servers (not all from the client - client hits
resolver, resolver hits a few servers, then sends response to client).
It spends longer in the 'getting connection' stage, where it's just
performing the TCP overhead to connect to a single server.
If we used HTTP over UDP, then getting responses from a server for small
results would generally be even faster than DNS lookups :-)
This would kick ass for redirects, framesets, small frames, and XML-RPC /
SOAP, and would make no difference for fetching images and downloading
lewd images.
Compare the responsiveness of NFS to the responsiveness of HTTP. I access
my home directory via NFS. I'd hate to do it via HTTP...
But to go back to your real question, I don't think we'll see performance
bottlenecks because of HTTP over TCP. Instead, I think we'll see
functionality bottlenecks instead because people only do coarse grained
stuff without real-time responses...
ABS
--
Alaric B. Snell
http://www.alaric-snell.com/ http://RFC.net/ http://www.warhead.org.uk/
Any sufficiently advanced technology can be emulated in software
|
