>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.

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.

If you're saying the second argument to listen(2) becomes pointless in
most cases, then yeah, I agree, _provided_ we either change SOMAXCONN
to be UINT_MAX, or change 2nd arg to listen() to be UINT_MAX.  At
least on "busy" apps.  The "average" daemon can still get by fine with
32, or even 5.

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?)