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