Would this excerpt from RFC2616 (section 8.2) be relevent? Perhaps some routers and other infrastructure assume this as design criteria:
" Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion. " On Tue, Oct 23, 2012 at 7:28 AM, Monty Brandenberg <mo...@lindenlab.com>wrote: > On 10/23/2012 6:10 AM, Henri Beauchamp wrote: > > > And in fact, llappcorehttp.cpp only touches CP_CONNECTION_LIMIT, so > > CP_PER_HOST_CONNECTION_LIMIT is kept at its default (8) whatever the > > TextureFetchConcurrency debug setting value, meaning the viewer never > > opens more than 8 simultaneous connections per HTTP server. > > > > I therefore think that, as it is used right now TextureFetchConcurrency > > is not really useful (there's already a hard-coded limit of 40 in > > lltexturefetch.cpp for the max number of simultaenously queued texture > > fetching requests: perhaps this number should be affected by > > TextureFetchConcurrency instead ?), and in fact, the CP_CONNECTION_LIMIT > > will need to be much greater than 8 or 12, once the new HTTP core is used > > for connecting to other servers than just texture servers (mesh, > > capabilities, etc). > > On the other hand, I agree that CP_PER_HOST_CONNECTION_LIMIT should be > > kept below a reasonnable maximum value (8 sounds good for pipelining > > requests, but non-pipelining ones could probably allow up to 32 which > > is the default for per-host connections in most HTTP servers). > > Actually, GP_CONNECTION_LIMIT (global) and CP_PER_HOST_CONNECTION_LIMIT > (per-class, per-host) aren't implemented yet so only CP_CONNECTION_LIMIT > (and TextureFetchConcurrency) have effect. _httpinternal.h has the > general to-do list for next phases. This is one area that should get > some attention but a single control is all that's necessary for this > release. > > As for the 40 request high water mark. That's part of a trade-off > between several competing factors: > 1. Deep pipelining to keep work available to low-level code (favors > large numbers). > 2. Responsiveness to changes in prioritization without having to > serialize and pass new priority values down to lowest layers (favors > small numbers). > 3. Eventual balancing with other users of the same class to guarantee > fairness and liveness. For textures, this will almost certainly include > meshes and possibly other caps-based requests that don't use SSL. > > > Unless the router is buggy, it shouldn't be impacted by the number of > > open sockets (at least not under 60K sockets)... Some protocols, such > > as torrent can use hundreds or even thousands of sockets at once. > > As Oz points out, routers are all affected by this and other factors. > And I'd go so far to say that any router that implements NAT is > guaranteed to be broken by design. But they're all broken in unique > and interesting ways. Some are sensitive to connection concurrency. > Others to connections created over a time interval. To counts of > dest_addr:src_addr pairs, to counts of (dst_addr:dst_port:src_addr: > src_port:ident) tuples. To DNS activity interspersed with handshakes. > And then the failure modes are many. I once tried to build a simple > control system to respond to failures but one family of routers > takes five minutes to respond to a change in environment. Can't build > a universally valid feedback system for this purpose with that kind > of delay in the response. > > To quote Roy Batty: I've seen things you people wouldn't believe. > > Here's a chart I keep forwarding: > http://www.smallnetbuilder.com/lanwan/router-charts/bar/77-max-simul-conn > Not officially endorsed by Linden, etc., but a useful measure of > one metric that is likely to predict problems. At the bottom of > that chart you'll find members of router families that are both > very common and very often a source of problems in SL. > > > The true limit is server side. > > No, not really. It is *a* limit and one I'm deeply involved with. > But there are people who are having difficulty getting to the > servers and haven't even been able to enjoy its limits. > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges >
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
