[PATCH] Upstream keepalive: keepalive_pool_key directive.

Maxim Dounin mdounin at mdounin.ru
Sat Aug 31 18:35:37 UTC 2019


Hello!

On Fri, Aug 30, 2019 at 12:43:40PM -0700, Thibault Charbonnier wrote:

> # HG changeset patch
> # User Thibault Charbonnier <thibaultcha at me.com>
> # Date 1567193727 25200
> #      Fri Aug 30 12:35:27 2019 -0700
> # Node ID 40abd582aafbd22c2435afed5fd3311333ca99bd
> # Parent  a31ec2b79f9f208fecbc92020d12edb2a5207480
> Upstream keepalive: keepalive_pool_key directive.
> 
> This directive gives control to the user as to how they wish upstream
> connection pools be created and used.
> 
> By default, each upstream block maintains a unique connection pool per
> IP/port tuple specified via the `server` directive.
> 
> With this change, if the `keepalive_pool_key` directive is specified in
> an upstream block, the connection pools will be further segmented
> according to the IP/port/pool_key combination. Each connection pool will
> still have up to as many connections as specified in the `keepalive`
> directive.
> 
> * When `keepalive_pool_key` evaluates to an empty string, the pool_key
>   behavior is disabled (as if only `keepalive` was specified).
> * When the pool_key behavior is in effect, SSL session reuse will be
>   disabled out of the box (as if `proxy_ssl_session_reuse off;` was
>   specified).
> * Two new variables `$keepalive_pool_key` and `$keepalive_pool_key_raw`
>   can be accessed to read the value of the current pool_key (if set).
>   The former will compile the value, while the later will return it as
>   specified by the user.
> 
> This solves existing limitations of the upstream block such as
> detailed in the following tickets:
> 
> * https://trac.nginx.org/nginx/ticket/1340
> * https://trac.nginx.org/nginx/ticket/1593
> 
> For example, let's consider a use-case similar to #1340, in which
> different SNIs are intended to open different connections:
> 
>     upstream upstream.domain.com {
>         server 1.1.1.1:443;
> 
>         keepalive 60;
>         keepalive_pool_key $upstream_sni;
>     }

[...]

No, thank you.  The issues as observed in the tickets linked 
should be resolved by using distinct upstream blocks instead.

-- 
Maxim Dounin
http://mdounin.ru/


More information about the nginx-devel mailing list