Lighttpd

max_connections controls the max number of open socket connections. If max_connections is reached, future connections from clients will wait in the kernel listen backlog. If the backlog is full, then the client request will be rejected at the TCP layer. The size of the listen backlog is now configurable. See discussion in #1825 and #2116, and see https://github.com/lighttpd/lighttpd1.4/pull/50.

However, these open socket connections might not be active if many are waiting for client or backends to respond.

It seems like you would like a low-watermark, which when breached, results in connections being accepted, immediately responded to with 503, and then closed. The patch you provided might be incomplete since lighttpd will keep the connection open and will read from the client (for a few seconds) and will discard what is read until the client closes the connection. This is done so that the client has a better chance of receiving the 503 Service Unavailable instead of a TCP RST. The effect of your patch is simply that above a certain number of connections, the server will not allow any additional "active" servicing of connections, since lighttpd will be reading and discarding data from these connections, and handling connection close from well-behaved clients (not malicious clients). On the other hand, if you're trying to limit the number of "active" connections, this patch does not measure the load on the server very well. kernels today (10 years after you filed this ticket) can manage hundreds of thousands of open connections if configured to do so.

As an alternative, if you have a very busy site, you might configure a load balancing proxy, such as HAProxy, in front of multiple web servers, and then tune the listen backlog size in lighttpd to a low enough value so that each server can handle that number of active connections. HAProxy will handle a TCP RST if the listen backlog queue is full, and haproxy can handle manage a timeout if waiting too long for the backend web server to accept the connection and respond. This sort of solution is much more robust than simply sending 503 when the total number of active and inactive open connections reaches an arbitrary number.