net.core.somaxconn to values higher than default is only needed on very-very loaded servers where connection rate is so high/bursty that having 128 (in
BSDs even more: 128
backlog + 64
half-open) concurrent connections is not considered abnormal or when you need to delegate definition of what is normal to people writing application or it's config.
Some administrators use high
net.core.somaxconn to hide problems with their services, so from user's point of view process stall would look like a latency spike instead of connection interrupted/timeout (controlled by
net.ipv4.tcp_abort_on_overflow in Linux).
Real cause is either slow processing of some requests (e.g. some single threaded blocking server) or insufficient number of worker threads/processes in software (e.g. multi- process/threaded blocking software like
PS. Also as
listen(2) manual says -
net.core.somaxconn acts only upper boundary for an application which is free to choose something smaller (usually set in app's config), though some apps just use
listen(fd, -1) which means set backlog to the max.
PPS. Sometimes it's preferable to fail fast and let the load-balancer to do it's job than to make user wait - for that purpose we set
net.core.somaxconn to some high values like 4096, but limit application backlog to something small like
10 and set
net.ipv4.tcp_abort_on_overflow to 1.
PPPS. Many versions of Linux have nasty bug of truncating
somaxcon value to it's 16 lower bits (i.e. casting value to
uint16_t), so raising that value to more than
65535 can be even dangerous. For more information see: http://patchwork.ozlabs.org/patch/255460/