# HG changeset patch # User Ruslan Ermilov # Date 1392975559 -14400 # Node ID 5f41c6582a4b9a931982361a8a86c19c79503092 # Parent 6c021feec587c0badabfff688f93dd4d6d23a60c [mq]: p diff --git a/xml/en/GNUmakefile b/xml/en/GNUmakefile --- a/xml/en/GNUmakefile +++ b/xml/en/GNUmakefile @@ -9,6 +9,7 @@ DOCS = \ dirindex \ http/request_processing \ http/server_names \ + http/load_balancing \ http/configuring_https_servers \ debugging_log \ http/converting_rewrite_rules \ diff --git a/xml/en/docs/http/load_balancing.xml b/xml/en/docs/http/load_balancing.xml new file mode 100644 --- /dev/null +++ b/xml/en/docs/http/load_balancing.xml @@ -0,0 +1,305 @@ + + + + + + +
+ +
+ + +Load balancing across multiple application instances is a commonly used +technique for optimizing resource utilization, maximizing throughput, +reducing latency, and ensuring fault-tolerant configurations. + + + +It is possible to use nginx as a very efficient HTTP load balancer to +distribute traffic to several application servers and to improve +performance, scalability and reliability of web applications with nginx. + + +
+ + +
+ + +The following load balancing mechanisms (or methods) are supported in +nginx: + + + +round-robin — requests to the application servers are distributed +in a round-robin fashion, + + + +least-connected — next request is assigned to the server with the +least number of active connections, + + + +ip-hash — a hash-function is used to determine what server should +be selected for the next request (based on the client’s IP address). + + + + + +
+ + +
+ + +The simplest configuration for load balancing with nginx may look +like the following: + +http { + upstream myapp1 { + server srv1.example.com; + server srv2.example.com; + server srv3.example.com; + } + + server { + listen 80; + + location / { + proxy_pass http://myapp1; + } + } +} + + + + +In the example above, there are 3 instances of the same application +running on srv1-srv3. +When the load balancing method is not specifically configured, +it defaults to round-robin. +All requests are + +proxied to the server group myapp1, and nginx applies HTTP load +balancing to distribute the requests. + + + +Reverse proxy implementation in nginx includes load balancing for HTTP, +HTTPS, FastCGI, uwsgi, SCGI, and memcached. + + + +To configure load balancing for HTTPS instead of HTTP, just use “https” +as the protocol. + + + +When setting up load balancing for FastCGI, uwsgi or memcached, use +, +uwsgi_pass and + +directives respectively. + + +
+ + +
+ + +Another load balancing discipline is least-connected. +Least-connected allows controlling the load on application +instances more fairly in a situation when some of the requests +take longer to complete. + + + +With the least-connected load balancing, nginx will try not to overload a +busy application server with excessive requests, distributing the new +requests to a less busy server instead. + + + +Least-connected load balancing in nginx is activated when the + +least_conn directive is used as part of the server group configuration: + + upstream myapp1 { + least_conn; + server srv1.example.com; + server srv2.example.com; + server srv3.example.com; + } + + + +
+ + +
+ + +Please note that with round-robin or least-connected load +balancing, each subsequent client’s request can be potentially +distributed to a different server. +There is no guarantee that the same client will be always +directed to the same server. + + + +If there is the need to tie a client to a particular application server — +in other words, make the client’s session “sticky” or “persistent” in +terms of always trying to select a particular server — the ip-hash load +balancing mechanism can be used. + + + +With ip-hash, the client’s IP address is used as a hashing key to +determine what server in a server group should be selected for the +client’s requests. +This method ensures that the requests from the same client +will always be directed to the same server +except when this server is unavailable. + + + +To configure ip-hash load balancing, just add the + +directive to the server (upstream) group configuration: + +upstream myapp1 { + ip_hash; + server srv1.example.com; + server srv2.example.com; + server srv3.example.com; +} + + + +
+ + +
+ + +It is also possible to influence nginx load balancing algorithms even +further by using server weights. + + + +In the examples above, the server weights are not configured which means +that all specified servers are treated as equally qualified for a +particular load balancing method. + + + +With the round-robin in particular it also means a more or less equal +distribution of requests across the servers — provided there are enough +requests, and when the requests are processed in a uniform manner and +completed fast enough. + + + +When the +weight +parameter is specified for a server, the weight is accounted as part +of the load balancing decision. + + upstream myapp1 { + server srv1.example.com weight=3; + server srv2.example.com; + server srv3.example.com; + } + + + + +With this configuration, every 5 new requests will be distributed across +the application instances as the following: 3 requests will be directed +to srv1, one request will go to srv2, and another one — to srv3. + + + +It is similarly possible to use weights with the least-connected and +ip-hash load balancing in the recent versions of nginx. + + +
+ + +
+ + +Reverse proxy implementation in nginx includes in-band (or passive) +server health checks. +If the response from a particular server fails with an error, +nginx will mark this server as failed, and will try to +avoid selecting this server for subsequent inbound requests for a while. + + + +The +max_fails +directive sets the number of consecutive unsuccessful attempts to +communicate with the server that should happen during +fail_timeout. +By default, +max_fails +is set to 1. +When it is set to 0, health checks are disabled for this server. +The +fail_timeout +parameter also defines how long the server will be marked as failed. +After +fail_timeout +interval following the server failure, nginx will start to gracefully +probe the server with the live client’s requests. +If the probes have been successful, the server is marked as a live one. + + +
+ + +
+ + +In addition, there are more directives and parameters that control server +load balancing in nginx, e.g. +, +backup, +down, and +. +For more information please check our reference documentation. + + + +Last but not least, + +advanced load balancing, + +application health checks, + +activity monitoring and + +on-the-fly reconfiguration of server groups are available +as part of our paid NGINX Plus subscriptions. + + +
+ +
diff --git a/xml/en/docs/index.xml b/xml/en/docs/index.xml --- a/xml/en/docs/index.xml +++ b/xml/en/docs/index.xml @@ -8,7 +8,7 @@
@@ -62,6 +62,10 @@ + + + +