[opensource-dev] New HTTP Library & Project Viewer

[Henri Beauchamp]

I would agree with you if all decent HTTP servers (Apache, but not
only), didn't have their own throttling algorithms are weren't able
to just drop the excess of connections when they run out of sockets.
But they do have such throttling mechanisms, so it's no issue at all
and in fact, 32 is the max number of connection per IP an Apache
server would accept by default (the admin can of course change this
setting: it's not uncommon to encounter websites configured for up
to 64 connections per IP).

FYI, early HTTP fetches code was allowing up to 32 connections already,
then it was lowered to 8, then raised back up to 16, and I since lost
track of what maximum is currently hardcoded in LL's viewer...

That's why I made it a configurable setting: if you start seeing
timeouts or "busy" replies from the server in your viewer log, then
you can still lower the setting. The default in the Cool VL Viewer
is 16, but I have always used 32 myself and never came accross any
issue, including in over-crowded sims (and I can enjoy a very fast
rezzing experience): of course, you could argue that this is because
everyone else in the sim is limited to 8 connections... And you
could be right (hard to say: only LL could...).

As for keeping only two persistent connections, this can seem a
good idea, but on the viewer side it means that the free cores
(on a quad core CPU, only one is always used at 100% for rendering,
the three others are only (partially) used while decoding textures
and for other threads, suchs as fetching/caching) are just sitting
there, doing nothing as they wait for a texture to be downloaded
from your only two "pipes"... and what happens when a connection
stalls and timeouts ?... You loose half your bandwitdh (instead
of only 1/32th) !...

I would therefore recommend a higher number of persistent
connections (16 sounds good and 8 an absolute minimum); alas such
connections are precisely very limited (usually 4 per IP) in
standard HTTP server configurations (they are considered costy,
precisely because they are persistent while the traffic is only
sporadic on normal web servers).
This means that the grid's (SL and OpenSIM) texture HTTP servers
would have to be configured specially to allow a higher limit per
IP...

On Sun, 29 Jul 2012 15:59:38 +0200, Carlo Wood wrote:

> On Sun, 29 Jul 2012 10:07:18 +0200
> Henri Beauchamp <sldev at free.fr> wrote:
> 
> > On Sun, 29 Jul 2012 05:23:15 +0200, Carlo Wood wrote:
> > 
> > > On Fri, 27 Jul 2012 16:59:18 -0400
> > > holydoughnuts <holydoughnuts at gmail.com> wrote:
> > > 
> > > The implementation that I wrote for Singularity (not yet in the
> > > the official release) is more on the side of "blazing fast" :p.
> > > The bottleneck is entirely server-side, but I've seen download
> > > speeds of 1 MB/s non-stop till all textures were there.
> > 
> > With just a few tweakings to the texture fetcher (and in particular
> > a setting that permits up to 32 concurrent HTTP fetches), I get much
> > more than 1MB/s in the Cool VL Viewer... In fact, I'm more in the
> > 10MB/s+ range while rezzing in heavily textured areas and the rezzing
> > time is pretty low... This has been so for many months (well over
> > a year actually) already.
> 
> I agree that that would be an advantage for the user; but it's not
> clear to me if it is allowed (or will be in the near future) to
> have 32 concurrent fetches.
> 
> The rationale that it SHOULD be allowed is that the user will
> download those textures anyway; so, you might as well allow
> them to get it quickly, in a short time: this has no influence
> on the average number of open file descriptors on the server.
> 
> I understand that LL is afraid that once viewers can keep sockets
> open (for reuse) that the servers run out of filedescriptors. Of course,
> this is all to true. Therefore I propose to set a limit on the
> maximum number of UNUSED filedescriptors. However, there should be
> no limit or a much higher limit, on the number of connections that
> are actually in use. The question is then: when is a filedescriptor
> "unused"? Well, I'd say that for the sake of re-use, it can be
> considered unused if there hasn't been a new request for it for
> -say- a second.  It's probably best to define multiple stages,
> that is:
> * Allow a maximum of 32 connections.
> * Allow up to 32 connections that are unused for 1 second.
> * Allow up to 8 connections that are unused for 10 seconds.
> * Allow up to 2 connections that are unused for 1 minute.
> * Allow 1 connection to be unused for 20 minutes (or whenever
> one leaves a region and it can be determined that this server
> won't be needed or used anymore).
> 
> Of course this means that upon teleport to a new region with
> many unknown textures, the viewer will make 32 new SSH connections,
> but that is MUCH less than one new connection PER TEXTURE, as we
> have now. Then all those connections are reused until all textures
> have been downloaded (a few seconds).
> 
> Other strategies are possible, like NOT immediately creating a
> new connection as long as the maximum of 32 connections haven't
> been used up yet, but waiting with that until there's a queue
> of requests building up.
> 
> Bottom line is, I'm afraid that Linden Lab is going to take the
> (too) simplistic route as they often have done in the past, and
> do something very silly like:
> * Allow a maximum of 2 connections, and allow to keep them
>   open indefinitely.
> 
> I hope you see the difference :p
> I argue that something like that makes no sense and would hurt
> the user because they'd have to wait unnecessary long before
> everything downloads.
>