Subject: Re: New sysctl "net.listen_backlog"?
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Marc Slemko <email@example.com>
Date: 09/14/1998 18:03:41
On Mon, 14 Sep 1998, Jonathan Stone wrote:
> >Compile Apache on a kernel with SOMAXCONN set to 128. Set the sysctl to
> >511. Apache will pass backlog param of 511 just fine and everything
> >should work just fine. The only except is if you have your libc checking
> >SOMAXCONN, but that would just be broken.
> Nope. Apache will pass whatever is compiled into its listen() call.
> It'll only pass 511 if that's what was compiled in. Do you know what
> the Apache source code has right this instant? My guess would be
> something like
> listen (somefd, SOMAXCONN)
> which is evaluated at compile-time, not from the sysctl variable.
Yes, I know because I wrote that code. <g>
It does not use SOMAXCONN. Using SOMAXCONN is broken because it should be
runtime configurable in the kernel for a good kernel, yet SOMAXCONN can't
Apache defaults to 511, and it is runtime configurable with the
> If you're assuming that "demanding" serve apps will check how big
> somaxconn currently is, ask for a back-log that big, I don't buy that:
> they can just always ask for UINT_MAX and get the exact same effect.
No, I'm not saying they will check (especially since there is no portable
way to check) but I am saying that they can specify a big enough number
for their purpose or let their user configure it.
> It's using code which does
> listen(fd, SOMAXCONN) /* where SOMAXCONN is 128 */
> everywhere which is the problem: there's no per-app selectivity in the
> size of hte backlog at all, then. But that's precisely what Perry is
> arguing for, AFAICT. (Perry: what'm I missing?)
Sounds fine to me. If it can deal with some default, then let it. You
can't have SOMAXCONN be correct, so if something insists on using it, it
will get some value.
Yea, you can argue that value should be a huge value, then it should be
limited by a different value setting the default, but I don't find that
necessary. Just because you want a system where some apps need a huge
(define "large" as 128 and say that is fine for the typical app) backlog,
you don't want all apps to suddenly have a huge backlog when it may break
them; having them keep using the large backlog no matter what the sysctl
is set to is a good thing.