From owner-freebsd-questions  Tue Sep 12 18:37:33 1995
Return-Path: questions-owner
Received: (from majordom@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id SAA22693
          for questions-outgoing; Tue, 12 Sep 1995 18:37:33 -0700
Received: from Root.COM (implode.Root.COM [198.145.90.17])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA22685
          for <questions@freebsd.org>; Tue, 12 Sep 1995 18:37:31 -0700
Received: from corbin.Root.COM (corbin [198.145.90.34]) by Root.COM (8.6.12/8.6.5) with ESMTP id SAA10294; Tue, 12 Sep 1995 18:36:21 -0700
Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id SAA00441; Tue, 12 Sep 1995 18:38:35 -0700
Message-Id: <199509130138.SAA00441@corbin.Root.COM>
To: Aaron Gifford <agifford@infowest.com>
cc: questions@freebsd.org
Subject: Re: SOMAXCONN question 
In-reply-to: Your message of "Tue, 12 Sep 95 19:15:49 -0601."
             <199509130116.TAA02403@InfoWest.COM> 
From: David Greenman <davidg@Root.COM>
Reply-To: davidg@Root.COM
Date: Tue, 12 Sep 1995 18:38:34 -0700
Sender: questions-owner@freebsd.org
Precedence: bulk

>I was wondering what would happen if I bumped up the value of SOMAXCONN
>from 5 to 15 in <sys/socket.h> and in /usr/src/sys/sys/socket.h and then
>recompiled my kernel...  Would it break something?  Also, would it fix
>a problem I've noticed on my web server...  when someone begins to connect
>over a SLOW or bad link, sometimes `netstat -an | grep SYN_RCVD` shows
>that person's multiple connections remaining in the SYN_RCVD state for
>quite a while, which appears to make it impossible for anyone else to
>connect to the web server until some slots clear.  Not being much of
>a socket hacker and not knowing the kernel, I assumed that the listen(sock,max)
>queue was full, and that SOMAXCONN was a limiting factor.

   It should fix your problem. It's interesting that you should send this
email - this very subject was the topic between myself and several people
yesterday. ...for instance, I can tell you that www.intel.com now has
SOMAXCONN set to 120 (as of yesterday)...although I think this is much higher
than is actually needed. I suspect that a number in the 10-20 range should be
adequate. Last night I was going to add a counter to count the number of
connection requests that were dropped because of the queue limit, but got
sidetracked...
   BTW, you'll likely have to recompile your web server, too, if it has a
small value specified in the listen() call (it's apparantly common to specify
SOMAXCONN, which of course would be 5 when it was compiled).

-DG