BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

NGINX应用性能优化指南(第四部分):负载均衡

| 作者 谢丽 关注 11 他的粉丝 发布于 2016年4月20日. 估计阅读时间: 6 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

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

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

正文

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

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

  1. 往返时间;
  2. 用于会话持久化的代理TCP CWND;
  3. 持久化会话数。

性能考量

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的值时要记住以下几点:

  • 那个连接数会从代理和应用服务器的连接上限(参见worker_connections)中分配;
  • 那个值是针对每个工作进程的设置;
  • 你可以已经使用keepalive指令配置了多个upstream块。

除非你已经配置了轮询负载均衡,否则很难预测每个应用服务器上的连接分配。更准确地说,那取决于你的负载均衡策略、每个请求的处置以及请求时间。

当每个工作进程都与同一个后台服务器建立其所有的连接时,(不大可能发生的)最坏场景就会出现。不过,那充分表明负载均衡策略需要重新考虑了。

注意:如果你在应用程序服务器上运行着一个默认NGINX配置,其worker_connections上限会被设置为512.

相关教程:增加CentOS 7上NGINX打开文件的上限

负载均衡策略

NGINX提供了如下负载均衡策略:

  1. 加权轮询;
  2. ip_hash:基于客户端IPv4或IPv6地址的哈希;
  3. hash:基于用户定义键的哈希;
  4. least_conn:最少活动连接数;
  5. least_timeNGINX Plus提供了最少平均响应时间策略。

在性能方面,least_time可能是首选,但是如果你的后台由相同的高性能应用服务器组成,那么这种策略跟你关系就不大了。此外,haship_hash提供了有用的选项。例如,如果应用服务器需要一段时间加载用户资料,将同一个用户发送给相同的后台服务器可能会受益于缓存命中。

客户端的IP地址由$remote_addr变量提供。但是留心客户端IP哈希,因为一个IP地址可能表示来自同一个NAT的多个用户(比如公司办公室或学校)。

查看英文原文:NGINX Application Performance Optimization:Load Balancing


感谢郭蕾对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

感谢分享 by Gao YorK

负载均衡的优化

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT