A copy may accept the connection and stay silent for a long time. This step shows how long nginx waits for it.
nginx waits for a copy's connection and answer according to its own timeouts, both 60s by default:
proxy_connect_timeout— how long to wait for the connection to the copy;proxy_read_timeout— how long to wait for the answer of a connected copy: the pause between chunks of data.
A copy that answers in 30 seconds accepts the connection right away, while nginx waits for its answer for up to 60 seconds — and every client that lands on it waits too. When the timeout runs out, it is a timeout failure: nginx sends the request to the next copy and takes the slow one out for fail_timeout. The timeout is set above the application's usual answer time: one that is too short takes out a healthy copy on a heavy request.
The site now runs on three copies, and only one of them is healthy. Requests with %header{x-upstream} in curl -w and the load balancer's log will show which copy has which problem.
A site on three copies
The site now has three copies: 8081, 8082 and 8083 (/etc/nginx/sites-available/lb). Make every request to http://localhost/ get 200 in less than 5 seconds. Leave the copies alone and keep them in the upstream: developers are fixing them, and once fixed, a copy must get requests again without editing nginx.
Goals · 0 of 2
- Get 200 for every request in less than 5 seconds not done yet
- Keep the three copies in the upstream as they are not done yet