转载

NGINX应用性能优化指南（第四部分）：负载均衡

【编者的话】本文是“NGINX应用性能优化指南”系列文章的第四篇，主要介绍了如何从负载均衡方面实现NGINX应用性能优化。

注：本文最初发布于MaxCDN博客，InfoQ中文站在获得作者授权的基础上对文章进行了翻译。

正文

NGINX允许使用 upstream 指令配置后台。最值得注意的是会话持久化和负载均衡策略。

在会话持久化方面，有三个有用的变量需要考虑：

往返时间；
用于会话持久化的代理TCP CWND；
持久化会话数。

性能考量

RTT非常低则可以在代理和应用服务器之间快速建立连接，并快速提高代理的吞吐量。因此，对于（传统的）集中配置后台，热连接确实可以减少处理未缓存请求的工作。

不过，如果你已经部署了反向代理，将未缓存请求引向远程源服务器（例如海岸到海岸80毫秒），保持连接可以节省大量的连接建立时间——尤其是当你必须提供加密吞吐量的时候。（回想一下，新建一个TLS隧道需要消耗3个RTT进行协商。）

对于远端后台，你可能也会想用 tcp_slow_start_after_idle （在sys.net.ipv4中）。这决定了CWND的大小是否会在连接空闲（一个RTO）后恢复到初始值。通常，在正常情况下，那个行为是启用的，而且是期望的行为。但是，如果你在使用一个专用的点对点连接，那么你会希望禁用它，因为那不太可能遇到拥塞。BDP也不大可能变化。

现在，我知道你在想什么： 我没有一个专用连接，但让我贪心一次，无论如何都试一试！ 但下注时要考虑风险和回报。

在比较当前拥塞窗口大小和你对未来BDP（比如平均吞吐率乘以平均RTT）的推测时，分析真就派上用场了。还有一点值得考虑：对带宽成本的影响，假设数据不全在远端。

另外，如果你的BDP与初始拥塞窗口相比非常大，那么就要重新配置初始CWND。此外，对于在快速LAN（像AWS EC2）上集中部署的后台，可能就不需要检查其中任何一项了。

持久化后台连接

指令 keepalive （会话持久化）设置每个工作进程同上游服务器保持的最大 空闲连接 数。换句话说，当一个工作进程的连接超出了 keepalive 设置的数量，它会开始关闭最近最少使用的空闲连接，直到达到那个数值。可以将它想象成每个工作进程的连接池。

支持后台 keepalive 需要HTTP/1.1，因为，我们需要设置 proxy_http_version 指令，并清除 Connection 头。对于NGINX：

upstream backend {     keepalive 100;     server 192.168.100.250 weight=1 max_fails=2 fail_timeout=10;     server 192.168.100.251 weight=1 max_fails=2 fail_timeout=10;     server 192.168.100.252 weight=1 max_fails=2 fail_timeout=10; } server {     location /http {         proxy_http_version 1.1;         proxy_set_header Connection "";         proxy_pass http://backend;     } }

在设置 keepalive 的值时要记住以下几点：