On 31/07/2012 9:13 AM, Henri Beauchamp wrote: > On Mon, 30 Jul 2012 13:08:18 -0400, Oz Linden (Scott Lawrence) wrote: > >> HTTP itself recommends that clients not maintain more than 2 connections >> to the same service [1]. I don't know exactly what limit we will decide >> is reasonable (I expect that 2 will be ok, but don't know whether or not >> some larger number will be also). > I bet 2 persistent connections will not be as performant as 16 (or even > only 8) transient ones... Especially for oversea users, when links go > through a load of routers before the viewer can actually communicate with > LL's servers (and I have seen numerous times buggy/badly configured routers > dropping "persistent" connections).
The pipelining of requests *should* contribute a great deal to per-connection performance - there are outliers where that won't happen (stuck/stalled connections, broken connections, and so forth), but in the main properly-implemented pipelining, smartly managed by the viewer, should provide quite a boost under the most common use-cases, IMO. > Not to mention the underusage of the additional CPU cores for image decode > and caching threads (that will have to wait each time and will, at best, > process 2 images before the next 'bunch' (if 2 is already a 'bunch') > arrives). I'm not sure that's actually much of a concern. The number of textures actually *ready* for decoding at any tick of the clock when they can be scheduled is generally quite small (just one or two), even under the old UDP system - more cores for texture decoding tasks primarily benefit the slower systems where the decoding starts to eat up significant chunks of user-scale time - or if you're really sucking down oodles of data at speeds many of us overseas users can't actually pull. (I think it is generally safe to assume a median data transfer rate of 400Kbps - this is everyone's cue to jump up and tell me that the number is vastly over/under any sane view of reality) So, confining the number of persistent connections to an arbitrary X (say 2 or 3) doesn't *seem* to me like it would make that much of a difference in practical terms to many users. It will to *some*, absolutely, who could doubtless get a *heap* more performance from X+1 or X+2 pipelines. There will always be those cases, IMO. _______________________________________________ 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