I’m somewhat unclear about how the keepalive functionality works within
the
upstream module. My nginx install currently handles several hundred
domains
all of which point to different origin servers. I would imagine I can
improve performance by enabling keepalive, however the documentation
says
"The connections parameter sets the maximum number of idle keepalive
connections to upstream servers that are preserved in the cache of each
worker process. When this number is exceeded, the least recently used
connections are closed. "
Does that mean that if I have 10 domains and then set keepalive to 32,
that
there will potentially be up to 320 open connections from my server to
the
backend servers per worker at any given point or would the worker share
all
upstreams and only open a total of 32 regardless of how many upstream
blocks
were on the website? Also, does the number of keepalive connections have
anything to do with the number of cores on a box?
Also, is there any downside to having a large number of upstreams in the
http block? I know for “map” block there’s no performance degradation
since
they’re only evaluated on demand, but I don’t see any kind of
documentation
regarding how upstreams are handled.
Thanks!
Posted at Nginx Forum:
Hello!
On Mon, Apr 07, 2014 at 05:29:15PM -0400, abstein2 wrote:
there will potentially be up to 320 open connections from my server to the
backend servers per worker at any given point or would the worker share all
upstreams and only open a total of 32 regardless of how many upstream blocks
were on the website? Also, does the number of keepalive connections have
anything to do with the number of cores on a box?
Each upstream block has it’s own connection cache. There is no
“generic” connection cache to be used with all upstream blocks.
Also, is there any downside to having a large number of upstreams in the
http block? I know for “map” block there’s no performance degradation since
they’re only evaluated on demand, but I don’t see any kind of documentation
regarding how upstreams are handled.
Unless you use variables to dynamically select an upstream server, it
is resolved while parsing configuration and there is no performance
degradation at runtime regardless of the number of upstream blocks you
have.
–
Maxim D.
http://nginx.org/
Maxim,
Thanks so much for clarifying. Just to make sure I’m understanding
correctly, if I had something like this pseudo-code
upstream upstream1 { }
upstream upstream2 { }
upstream upstream3 { }
upstream upstream4 { }
upstream upstream5 { }
server { server_name server1.com; proxy_pass http://upstream1; }
server { server_name server2.com; proxy_pass http://upstream2; }
server { server_name server3.com; proxy_pass http://upstream3; }
server { server_name server4.com; proxy_pass http://upstream4; }
server { server_name server5.com; proxy_pass http://upstream5; }
There would only be performance degradation if the setup was:
server {
server_name server6.com;
set $PROXY_TO ‘upstream5’;
proxy_pass http://$PROXY_TO;
}
Is that correct? And, if there was degradation, would it be limited to
hosts
that server block was trying to serve or would it impact overall
performance?
Thanks!
Posted at Nginx Forum:
Hello!
On Tue, Apr 08, 2014 at 05:41:17PM -0400, abstein2 wrote:
set $PROXY_TO ‘upstream5’;
proxy_pass http://$PROXY_TO;
}
Is that correct?
Yes. The “degradation” is due to upstream{} blocks are in stored
an array, and looking up an upstream uses linear array traversal.
That is, cost of looking an upstream sever in the “proxy_pass
http://$proxy_to” is O(n), where n - number of upstream{} blocks
in the configuration.
I don’t think the difference will be measurable even with
thousands of upstream{} blocks though.
And, if there was degradation, would it be limited to hosts
that server block was trying to serve or would it impact overall
performance?
See above, it is only related to upstream{} block lookup in
“proxy_pass http://$proxy_to” and doesn’t affect requests where
this proxy_pass isn’t used.
–
Maxim D.
http://nginx.org/