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: http://forum.nginx.org/read.php?2,249089,249089#msg-249089
on 2014-04-07 23:30

on 2014-04-08 11:26

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 Dounin http://nginx.org/
on 2014-04-08 23:42

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: http://forum.nginx.org/read.php?2,249089,249130#msg-249130
on 2014-04-09 13:18

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 Dounin http://nginx.org/