upstream server max_conns

[Homutov Vladimir]

On Tue, Aug 12, 2014 at 02:33:00PM -0700, Yu Zhao wrote:
> Greetings,
>
> I'm looking for a solution to limit number of connections to upstream
> servers because my app engine running on upstream servers performs best
> when requests are serialized per CPU.
>
> The commercial version of Nginx provides upstream server max_conns
> parameter which "limits the maximum number of simultaneous connections to
> the proxied server". It sounds very promising and yet somewhat unclear to
> me.
>
> Let's say I have following configuration:
>
> worker_processes 4;
>
> upstream backend {
>     server backend1.example.com max_conns=8;
>     server backend2.example.com max_conns=8;
>     keepalive 4;
> }
>
> My questions are:
>
> 1) From the parameter's description, I believe it's a global (not per
> worker) option. When it's set to a small value, would one of the workers
> use all 16 connections? If yes, would all queued requests on other workers
> just simply timeout? Or the worker who has all connections would releases
> some of the connections and wake up other workers so they will have a
> chance to process the queued requests? (AFAIK, the only non-block way to
> wake up a worker is to use the channel which currently only exists between
> master and worker.)

The parameter is global if the nginx.org/r/zone is specified in the
upstream configuration. In this case, it means that no more than 8 (in
your example) connections will be open to each backend server.

If you have 8 open connections, the 9th will be rejected, unless the
nginx.org/r/queue is specified. In the latter case, 9th connection will
wait during specified timeout for available server. Any worker has
chances to process requests in its queue.


> 2) When total number of connections reaches max_conns, will new requests be
> queued per upstream server (within a worker) or in a single queue (within a
> worker)?

The requests are queued in each worker.

> In another word, will a upstream server be selected before a
> request is queued or not?
> If yes, what would happen when a upstream server
> becomes unavailable? If not, are round-robin and ip_hash load balance
> algorithms still effective or they just behave like least_conn when there
> are queued requests?

If a server cannot be selected (due to all available servers are busy),
the request may be put into queue. The next attempt to process the
request will pick first available server using the configured balancing
algorithm (if there will be only 1 available server, it will be picked,
if there are more than one, the balancing algorithm will be applied to
choose).

> 3) When keepalive is used, what would happen when total number of keepalive
> connections is equal to total number of max_conns? Will workers hold more
> connections to some upstream servers and less to other upstream servers
> (i.e. connections to upstream servers are not evenly distributed).

The max_conns parameter is independent from the keepalive and only
controls that after accepting N connections server cannot be selected for
processing requests. How keepalive connections are distributed among
workers depends on your load pattern.

>
> Thanks,
> Yu

> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel