From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 21:49:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D6C21065670 for ; Wed, 4 Jan 2012 21:49:52 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2EAAE8FC15 for ; Wed, 4 Jan 2012 21:49:51 +0000 (UTC) Received: by wibhr1 with SMTP id hr1so17556004wib.13 for ; Wed, 04 Jan 2012 13:49:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=WsjSD5SKUsAmk5BtDWRmUH5H9HKqEFfqFzPIcK+Z08k=; b=BBIWFO/GrSYpgNZhIWEalkH9sPPLnVyVhEb7si1mlMM3Wgz5Jkba4PB5KQXPi+pqB4 7QAYsRxujfODM+50QrYwn1q6CQxLc7ySbGXqemAR5QN67Mm1FIYesQQS3tqK2dqFLDIq W7k37M7IN4v+Oc2Lcvn2RgguheqgJuzKGHaRw= MIME-Version: 1.0 Received: by 10.180.106.165 with SMTP id gv5mr125603198wib.18.1325713791066; Wed, 04 Jan 2012 13:49:51 -0800 (PST) Received: by 10.216.178.204 with HTTP; Wed, 4 Jan 2012 13:49:50 -0800 (PST) In-Reply-To: References: <0A9B7C39-DFA9-4C65-BE39-CC72E18DAB87@mac.com> <52A4B11E-592E-458D-BA0F-9B5A349F4B73@mac.com> Date: Wed, 4 Jan 2012 16:49:50 -0500 Message-ID: From: Arnaud Lacombe To: Chuck Swiger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Dan The Man Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 21:49:52 -0000 Hi, On Wed, Jan 4, 2012 at 4:42 PM, Chuck Swiger wrote: > On Jan 4, 2012, at 1:03 PM, Dan The Man wrote: >>> However, I'm not convinced that it is useful to do this. =A0At some poi= nt, you are better off timing out and retrying via exponential backoff than= you are queuing hundreds of thousands of connections in the hopes that the= y will eventually be serviced by something sometime considerably later. >> >> I agree completely, in practical application this makes sense, but why s= hould the OS dictate not being able to temporarily set that setting higher = in order to fully benchmark the application at 100k+ in the listen queue if= the developer so chooses? I think that alone should be a good reason, to m= ake freebsd developer friendly. > > The job of the OS is to manage resources on behalf of the users and proce= sses using the system. > No. The job of the OS is to service the user with the resource available, not constrict the user within some arbitrary predefined wall when there is still plenty of room available. If resource become scarce, then take action. > Some developers feel that VM means that the system should always claim ha= ve more memory available, but always saying "yes" isn't "managing resources= ". =A0I'd rather have the OS return a null pointer and set ENOMEM when some= one tries to malloc() more memory than the system (including swap, VM overc= ommit, etc) has, and I expect developers to code well enough to handle mall= oc() failures. > this is merely a policy issue, not yours to impose. > Setting the listen queue to an arbitrarily high value isn't useful, and d= evelopers would be better advised to pay attention to best practices in the= face of a massive connection backlog. > Stress-testing isn't about "best practice". It is about shaking enough the system to highlight weak point. - Arnaud > Regards, > -- > -Chuck > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= "