Willy, Am 27.11.19 um 22:20 schrieb Willy Tarreau: >> a) Is it 50 in-flight requests over a possibly smaller number of HTTP/2 >> connections? (requests <= 50) > > Yes that's it. Since we've started to support server-side keep-alive > in 1.5, the maxconn setting really sets the limit to the number of in > outstanding requests to a server. Technically speaking it limits the > number of streams attached to a server. In a multiplexed connection, > you will have anywhere between 1 and 50 connections for 50 streams. > > This was absolutely important because for most backends, the cost of > processing a request is way higher than the cost of an idle connection, > so what we really need to limit is the amount of parallel work delivered > to each server. In addition it's the only solution which guarantees the > same distribution for H1/close, H1/keep-alive, http-reuse, H2, etc.
Perfect. That's the answer I was hoping for and what I suspected. As you said, anything else breaks user expectations. Find attached a patch that (hopefully) clarifies the behavior in the documentation. Feel free to rephrase the new paragraph in case I said something incorrect. Best regards Tim Duesterhus Apply with `git am --scissors` to automatically cut the commit message. -- >8 -- Subject: [PATCH] DOC: Clarify behavior of server maxconn in HTTP mode In HTTP mode the number of concurrent requests is limited, not the number of actual connections. --- doc/configuration.txt | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/doc/configuration.txt b/doc/configuration.txt index 2fadc4336..5e56ca93d 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -11646,13 +11646,19 @@ downinter <delay> maxconn <maxconn> The "maxconn" parameter specifies the maximal number of concurrent connections that will be sent to this server. If the number of incoming - concurrent requests goes higher than this value, they will be queued, waiting - for a connection to be released. This parameter is very important as it can + concurrent connections goes higher than this value, they will be queued, waiting + for a slot to be released. This parameter is very important as it can save fragile servers from going down under extreme loads. If a "minconn" parameter is specified, the limit becomes dynamic. The default value is "0" which means unlimited. See also the "minconn" and "maxqueue" parameters, and the backend's "fullconn" keyword. + In HTTP mode this parameter limits the number of concurrent requests instead of + the number of connections. Multiple requests might be multiplexed over a single + TCP connection to the server. As an example if you specify a maxconn of 50 you + might see between 1 and 50 actual server connections, but no more than 50 + concurrent requests. + maxqueue <maxqueue> The "maxqueue" parameter specifies the maximal number of connections which will wait in the queue for this server. If this limit is reached, next -- 2.24.0
