[note: followup set to m.d.platform, since this seem to be of wide
interest, not just networking, and is not really right for .firefox.
Patrick's original post, which I recommend people read, is in
m.d.a.firefox and m.d.platforms.mobile]
Patrick McManus wrote:
2] Uses up wasted bandwidth. If the bandwidth were always fully consumed
at the TCP level by a single stream then parallelization would just be
rearranging the order in which the bytes were received between the
streams - it wouldn't speed anything up in the aggregate. But due to
congestion control, latencies involved in higher level protocols,
different routes with different bottlenecks, and occasional service
delays on both the client and server one stream is very unlikely to
saturate the available bandwidth. This is especially true of a young
stream or ones dealing in small objects. Multiple streams help sop up
that inefficiency. But its a very crude tool because fairly soon all the
bandwidth is being used and just rearranged between streams and the
problems mentioned in the "too many" section start to creep in.
Right. The situation here is in particular the total number of
connections we allow (not per-server). Parallelizing loads over
multiple servers obviously helps if each server for some reason has a
thinner pipe to the client than the client's available bandwidth, but
none of the servers share the connection bottleneck with each other.
I'm sort of wondering how common a situation this is.
Are there other situations in which the "spread the content over 30
servers" approach is a good one for a web page? It feels like a hack to
work around our poor usage of the limited number of per-server
persistent connections we use (e.g. lack of pipelining, etc), right?
I think there are great network gains to be had by separating high
latency operations from the block transfers and then more tightly
managing the block transfers according to some sense of priority.
This seems very plausible. What sort of API would we want here? We
have the (underused) nsISupportsPriority, but it's not very rich in
terms of what it can express, right? What would be useful things to
communicate to the network layer about the likely properties of a given
load? (Note: they'd have to be "likely", because for just about every
rule I can think of with this stuff there are exceptions. Nothing is
_really_ preventing someone from creating a <script> that returns an
infinite amount of data.)
The cost of doing this is maintaining a tighter integration between
networking and content rendering awareness. But given that those are
both fundamental responsibilities of the platform, it seems worthwhile.
Agreed, though if we can do this without networking needing to know
about content details like "script" (as in, content would describe
what's special about scripts in terms networking understands), that
would be ideal.
-Boris
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
