Re: fast rendering of text, containing images (Was: Persistent ...)

Jeffrey Mogul writes:
[Jeff]
>     > Note that, unlike the Netscape model, which breaks down if you
>     > need more than 4 images to decide how to render the text, this
>     > mechanism scales to arbitrary numbers of images.  It doesn't
>     > allow the browser to render several images simultaneously, but
>     > I think that is a much less useful feature if the alternative
>     > is faster completion for all images!
[Andrew]
>     Under Linux, I use normally 16 connections! Four is the default!
[Jeff]
> Many BSD-based TCP implementations cannot have more than a small
> number of connections in the SYN_RCVD state for any given TCP
> server port.  The default limit is often 8, and many server
> programs make it even worse (by using something like "5" as the
> second argument to the listen() system call).
> 
> If the network is fast enough to deliver your 16 SYN packets in a
> burst, many of those will be delayed by your TCP's initial RTT
> timeout (probably 1 second) because they won't get any response.
> 
> So 16 is not necessarily a good number.  4 usually works, because it is
> less than 5, which is about the smallest SYN_RCVD quota I've seen.
> 
> By the way, this is a design flaw in BSD, but BSD is what many
> people have.  I don't know if other TCP implementations have this
> flaw; I know that some BSD-based systems have fixed it.
The linux man page for listen says:

BUGS
       The  backlog  is currently limited (silently) to 5. [Docu-
       menter's note: is this true for Linux?]

In other man pages (SCO 3.2.2 and DMOS 3.2) I read 10 for this limit,
but that was some (3 to 8) years ago.

Inspecting the linux kernel source I discovered a limit called SOMAXCONN,
which is defined as 128.
I don't know what the limit in cern httpd is, but fortunately I haven't had
problems using it as proxy - even using 32 connections.

I almost always use a proxy on my LAN, and my 14.4k acces line limits
the rate of outgoing connection requests.

Now I will know the cause of problems, if I see problems on other systems.
Thanks.

Surely, the persistent connection extension is a better approach.

Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>

Received on Saturday, 23 September 1995 01:10:43 UTC