upstream server max_conns

[Yu Zhao]

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

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

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

Thanks,
Yu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20140812/d4623264/attachment.html>