Re: mystery NCSA httpdproblems on gnn.com

Chin Chee-Kai (cheekai@ncb.gov.sg)
Sun, 29 Jan 1995 05:58:36 +0100


> From: "Jon P. Knight" <J.P.Knight@lut.ac.uk>
> [...]
> 3) Look in the httpd source and find any calls to listen(). These usually
> specify a queue length of 5 TCP connections to listen for. I upped it to
> 20.
>
> Anyway, I did 1) and 3) and it seemed to fix our problem.
>
> Jon

The listen() system call in SunOS4.1.3 and IRIX4.0.5F silently maxes
the queue length parameter sent by the caller to 5, i.e. the system
neither generates an error nor increases its internal accept() queue
length to more than 5, if you specify anything higher than 5. So
I'm curious how upping the listen() parameter to 20 could help,
unless you hack the kernel and recompile it with larger queue buffers
to handle 20 simultaneous connection requests to the same socket,
like someone mentioned earlier (sorry I don't keep logs and can't
recall your name).

Still, even if the system really supports 20 allowable queue size, and
supposing 22 simultaneous connection-request packets come in together,
then since processing a connection by httpd is likely to take much
longer than registering the connection-request on the queue, the
22nd connection-request is likely to run into an out-of-queue-buffer
situation and gets dropped. (the first conn-request gets serviced,
then the next 20 conn-requests get stuffed onto the queue, and the
22nd conn-request gets dropped). Meanwhile, the browser which sent
the 22nd conn-request packet waits forever thinking that the packet
is winding through an exceptionally long path.

So, increasing the kernel's queue buffer to a sufficiently large size
is probably one way to tackle the problem. But say if the size is
upped to 20, and a teacher instructs a class of 30+ students to
"click on this server now", I suspect about 7 or 8 students will
still watch the earth spinning when others have got their files.

The above is assuming the conn-request packets don't go through
routers, which are additional sources from which packets could be
dropped.

I suspect coming versions of browsers might want to take into account
potentially heavily loaded servers (but otherwise still reachable
network-wise) which may constantly have queues close to its
maximum queue size, and should preempt its own connection request
and attempt to retry the connection again (repeat for, say, 3 times
before giving up).

Just my 2 cents.

Chee-Kai Chin