diff xml/en/docs/http/ngx_http_upstream_module.xml @ 966:95c3c3bbf1ce

Text review.
author Egor Nikitin <yegor.nikitin@gmail.com>
date Wed, 14 Aug 2013 12:03:41 +0400
parents f3754c623e6b
children fa19bacf6e1e
line wrap: on
line diff
--- a/xml/en/docs/http/ngx_http_upstream_module.xml	Wed Aug 14 17:21:19 2013 +0400
+++ b/xml/en/docs/http/ngx_http_upstream_module.xml	Wed Aug 14 12:03:41 2013 +0400
@@ -16,8 +16,8 @@
 
 <para>
 The <literal>ngx_http_upstream_module</literal> module
-allows to define groups of servers that can be referenced
-from the <link doc="ngx_http_proxy_module.xml" id="proxy_pass"/>,
+is used to define groups of servers that can be referenced
+by the <link doc="ngx_http_proxy_module.xml" id="proxy_pass"/>,
 <link doc="ngx_http_fastcgi_module.xml" id="fastcgi_pass"/>, and
 <link doc="ngx_http_memcached_module.xml" id="memcached_pass"/> directives.
 </para>
@@ -105,16 +105,16 @@
 </para>
 
 <para>
-By default, requests are distributed between servers using a
+By default, requests are distributed between the servers using a
 weighted round-robin balancing method.
 In the above example, each 7 requests will be distributed as follows:
-5 requests to <literal>backend1.example.com</literal>
-and one request to each of second and third servers.
-If an error occurs when communicating with the server, a request will
+5 requests go to <literal>backend1.example.com</literal>
+and one request to each of the second and third servers.
+If an error occurs during communication with a server, the request will
 be passed to the next server, and so on until all of the functioning
 servers will be tried.
 If a successful response could not be obtained from any of the servers,
-the client will be returned the result of contacting the last server.
+the client will receive the result of the communication with the last server.
 </para>
 
 </directive>
@@ -126,14 +126,14 @@
 <context>upstream</context>
 
 <para>
-Defines an <value>address</value> and other <value>parameters</value>
-of the server.
-An address can be specified as a domain name or IP address,
-and an optional port, or as a UNIX-domain socket path
+Defines the <value>address</value> and other <value>parameters</value>
+of a server.
+The address can be specified as a domain name or IP address,
+with an optional port, or as a UNIX-domain socket path
 specified after the “<literal>unix:</literal>” prefix.
-If port is not specified, the port 80 is used.
-A domain name that resolves to several IP addresses essentially defines
-multiple servers.
+If a port is not specified, the port 80 is used.
+A domain name that resolves to several IP addresses defines
+multiple servers at once.
 </para>
 
 <para>
@@ -142,17 +142,17 @@
 
 <tag-name><literal>weight</literal>=<value>number</value></tag-name>
 <tag-desc>
-sets a weight of the server, by default 1.
+sets the weight of the server, by default, 1.
 </tag-desc>
 
 <tag-name><literal>max_fails</literal>=<value>number</value></tag-name>
 <tag-desc>
-sets a number of unsuccessful attempts to communicate with the server
-during a time set by the <literal>fail_timeout</literal> parameter
-after which it will be considered down for a period of time also set
-by the <literal>fail_timeout</literal> parameter.
+sets the number of unsuccessful attempts to communicate with the server
+that should happen in the duration set by the <literal>fail_timeout</literal>
+parameter to consider the server down for a duration also set by the
+<literal>fail_timeout</literal> parameter.
 By default, the number of unsuccessful attempts is set to 1.
-A value of zero disables accounting of attempts.
+The zero value disables the accounting of attempts.
 What is considered an unsuccessful attempt is defined by the
 <link doc="ngx_http_proxy_module.xml" id="proxy_next_upstream"/>,
 <link doc="ngx_http_fastcgi_module.xml" id="fastcgi_next_upstream"/>, and
@@ -166,17 +166,16 @@
 <list type="bullet">
 
 <listitem>
-a time during which the specified number of unsuccessful attempts to
-communicate with the server should happen for the server to be
-considered down;
+the time during which the specified number of unsuccessful attempts to
+communicate with the server should happen to consider the server down;
 </listitem>
 
 <listitem>
-and a period of time the server will be considered down.
+and the period of time the server will be considered down.
 </listitem>
 
 </list>
-By default, timeout is set to 10 seconds.
+By default, the parameter is set to 10 seconds.
 </tag-desc>
 
 <tag-name><literal>slow_start</literal>=<value>time</value></tag-name>
@@ -257,10 +256,10 @@
 are distributed between servers based on client IP addresses.
 The first three octets of the client IPv4 address, or the entire IPv6 address,
 are used as a hashing key.
-The method ensures that requests of the same client will always be
-passed to the same server except when this server is considered down
-in which case client requests will be passed to another server and
-most probably it will also be the same server.
+The method ensures that requests from the same client will always be
+passed to the same server except when this server is considered down.
+In the latter case client requests will be passed to another server.
+Most probably, it will always be the same server as well.
 <note>
 IPv6 addresses are supported starting from versions 1.3.2 and 1.2.2.
 </note>
@@ -288,7 +287,7 @@
 
 <para>
 <note>
-Until versions 1.3.1 and 1.2.2 it was not possible to specify a weight for
+Until versions 1.3.1 and 1.2.2, it was not possible to specify a weight for
 servers using the <literal>ip_hash</literal> load balancing method.
 </note>
 </para>
@@ -303,22 +302,21 @@
 <appeared-in>1.1.4</appeared-in>
 
 <para>
-Activates cache of connections to upstream servers.
+Activates the cache for connections to upstream servers.
 </para>
 
 <para>
 The <value>connections</value> parameter sets the maximum number of
-idle keepalive connections to upstream servers that are retained in
-the cache per one worker process.
+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.
 <note>
-It should be particularly noted that <literal>keepalive</literal> directive
-does not limit the total number of connections that nginx worker process
-can open to upstream servers.
-The <value>connections</value> parameter should be set low enough
-to allow upstream servers to process additional new incoming
-connections as well.
+It should be particularly noted that the <literal>keepalive</literal> directive
+does not limit the total number of connections to upstream servers
+that an nginx worker process can open.
+The <value>connections</value> parameter should be set to a number small enough
+to let upstream servers process new incoming connections as well.
 </note>
 </para>
 
@@ -372,7 +370,7 @@
 <note>
 Alternatively, HTTP/1.0 persistent connections can be used by passing the
 <header>Connection: Keep-Alive</header> header field to an upstream server,
-though this is not recommended.
+though this method is not recommended.
 </note>
 </para>
 
@@ -402,7 +400,7 @@
 <para>
 <note>
 When using load balancer methods other than the default
-round-robin, it is necessary to activate them before
+round-robin method, it is necessary to activate them before
 the <literal>keepalive</literal> directive.
 </note>
 
@@ -583,10 +581,10 @@
 <tag-desc>status is neither 301 nor 302</tag-desc>
 
 <tag-name><literal>status 200-399;</literal></tag-name>
-<tag-desc>status is in the 200..399 range</tag-desc>
+<tag-desc>status is in the range from 200 to 399</tag-desc>
 
 <tag-name><literal>status ! 400-599;</literal></tag-name>
-<tag-desc>status is not in the 400..599 range</tag-desc>
+<tag-desc>status is not in the range from 400 to 599</tag-desc>
 
 <tag-name><literal>status 301-303 307;</literal></tag-name>
 <tag-desc>status is either 301, 302, 303, or 307</tag-desc>
@@ -1005,23 +1003,23 @@
 
 <tag-name><var>$upstream_addr</var></tag-name>
 <tag-desc>
-keeps an IP address and port of the server,
-or a path to the UNIX-domain socket.
+keeps the IP address and port of the server,
+or the path to the UNIX-domain socket.
 If several servers were contacted during request processing,
 their addresses are separated by commas, e.g.
 “<literal>192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock</literal>”.
-If an internal redirect from one server group to another happened
-using
+If an internal redirect from one server group to another happens,
+initiated by
 <header>X-Accel-Redirect</header> or
-<link doc="ngx_http_core_module.xml" id="error_page"/>
-then these server groups are separated by colons, e.g.
+<link doc="ngx_http_core_module.xml" id="error_page"/>,
+then the server addresses from different groups are separated by colons, e.g.
 “<literal>192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock : 192.168.10.1:80, 192.168.10.2:80</literal>”.
 </tag-desc>
 
 <tag-name><var>$upstream_cache_status</var></tag-name>
 <tag-desc>
-keeps status of accessing a response cache (0.8.3).
-The status can be one of “<literal>MISS</literal>”, 
+keeps the status of accessing a response cache (0.8.3).
+The status can be either “<literal>MISS</literal>”, 
 “<literal>BYPASS</literal>”, “<literal>EXPIRED</literal>”,
 “<literal>STALE</literal>”, “<literal>UPDATING</literal>” or
 “<literal>HIT</literal>”.
@@ -1029,34 +1027,34 @@
 
 <tag-name><var>$upstream_response_length</var></tag-name>
 <tag-desc>
-keeps lengths of responses obtained from upstream servers (0.7.27);
+keeps the lengths of responses obtained from the upstream servers (0.7.27);
 lengths are kept in bytes.
-Several responses are separated by commas and colons
-like in the <var>$upstream_addr</var> variable.
+Several response lengths are separated by commas and colons
+like addresses in the <var>$upstream_addr</var> variable.
 </tag-desc>
 
 <tag-name><var>$upstream_response_time</var></tag-name>
 <tag-desc>
 keeps times of responses obtained from upstream servers;
 times are kept in seconds with a milliseconds resolution.
-Several responses are separated by commas and colons
-like in the <var>$upstream_addr</var> variable.
+Several response times are separated by commas and colons
+like addresses in the <var>$upstream_addr</var> variable.
 </tag-desc>
 
 <tag-name><var>$upstream_status</var></tag-name>
 <tag-desc>
 keeps codes of responses obtained from upstream servers.
-Several responses are separated by commas and colons
-like in the <var>$upstream_addr</var> variable.
+Several response codes are separated by commas and colons
+like addresses in the <var>$upstream_addr</var> variable.
 </tag-desc>
 
 <tag-name><var>$upstream_http_...</var></tag-name>
 <tag-desc>
 keep server response header fields.
 For example, the <header>Server</header> response header field
-is made available through the <var>$upstream_http_server</var> variable.
+is available through the <var>$upstream_http_server</var> variable.
 The rules of converting header field names to variable names are the same
-as for variables starting with the
+as for the variables that start with the
 “<link doc="ngx_http_core_module.xml" id="variables">$http_</link>” prefix.
 Only the last server’s response header fields are saved.
 </tag-desc>