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


Reply via email to