我们如何使用HAProxy实现单机200万SSL连接

《我们如何使用HAProxy实现单机200万SSL连接》要点：
本文介绍了我们如何使用HAProxy实现单机200万SSL连接，希望对您有用。如果有疑问，可以联系我们。

导读：架构师需要精确的了解服务的支撑能力,也希望通过调优来发挥单个节点最大的价值.本文分享了压测及调优 HAProxy 实现 200 万并发 SSL 连接的过程,由高可用架构翻译,转载请注明出处.

先观察上面截图,可以看到两个关键信息：

• 这台机器已经建立了 238 万个 TCP 连接
• 使用内存大约在 48G.

下面将会介绍在单个 HAProxy 机器上实现这种规模访问所需的配置.本文是负载测试 HAProxy 系列文章的最后一篇.有时间的读者建议阅读本系列的前两篇(见文末链接),它将帮助您了解相应的内核调优方法.

在这个配置过程中,我们也使用了很多小组件帮助我们达到目标.

在展开最终 HAProxy 配置之前,我想给大家回顾一下负载测试的历程及想法,心急的读者可以直接跳到文章后段查阅相关 HAProxy 配置.

测试目标

我们要测试的组件是 HAProxy 1.6 版.生产环境是在 4 核 30 G 的机器上运行该软件,当前所有的连接都是非 SSL 的.

测试目标有两方面：

1. 当将整个负载从非 SSL 连接转移到 SSL 连接时,CPU 使用率增加的百分比.CPU 的使用率肯定会增加,这是由于 5 次握手的加长和数据包加密的开销所带来.
2. 其次,希望能够测试单个 HAProxy 每秒请求数和最大并发连接数的上限

目标一主要因为业务方面功能需要通过 SSL 进行通信. 目标二是为了可以在生产环境中部署最少规模的 HAProxy 机器.

组件和配置

• 使用多台客户端机器来执行 HAProxy 压力测试.
• 有各种配置的 HAProxy 1.6 的机器
  • 4核,30G
  • 16核,64G
• 相关后端服务器,用于支持所有并发访问.

HTTP 和 MQTT

我们的整个基础设施支持两种协议：

• HTTP
• MQTT

在我们的技术栈中,没有使用 HTTP 2.0,因此在 HTTP 上没有长连的功能.所以在生产环境中,单个 HAProxy 机器(上行 + 下行)的最大数量的 TCP 连接在(2 * 150k)左右.虽然并发连接数量相当低,但每秒请求的数量却相当高.

另一方面,MQTT 是一种不同的通信方式.它提供高质量的服务参数和持久的连接性.因此,可以在 MQTT 通道上使用双向长连通信.对于支持 MQTT(底层 TCP)连接的 HAProxy,在高峰时段会看到每台机器上大约有 600 – 700k 个 TCP 连接.

我们希望进行负载测试,这将为我们提供基于 HTTP 和 MQTT 连接的精确结果.

有很多工具可以帮助我们轻松地测试 HTTP 服务器,并且提供了高级功能,如结果汇总,将文本转换为图形等.然而,针对 MQTT,我们找不到任何压力测试工具.我们确实有一个自己开发的工具,但是它不够稳定,不足以支持这种负载.

所以我们决定使用客户端测试 HTTP 负载,并在 MQTT 服务器使用相同配置.

初始化设置

考虑到相关内容对于进行类似的压力测试或调优的人来说有帮助,本文提供了很多相关细节,篇幅稍微有些长.

• 我们采用了一台 16 核 30G 机器来运行 HAProxy,考虑到 HAProxy 的 SSL 产生的 CPU 巨大开销,因此没有直接使用目前生产环境.
• 对于服务器端,我们使用了一个简单的 NodeJs 服务器,它在接收到 ping 请求时用 pong 进行回复.
• 对于客户端,我们最终使用 Apache Bench.使用 ab 的原因是因为它是一个大家熟悉和稳定的负载测试工具,它也提供了很好的测试结果汇总,这正是我们所需要的.

ab 工具提供了许多有用的参数用于我们的负载测试,如：

• -c,指定访问服务器的并发请求数.
• -n,顾名思义,指定当前负载运行的请求总数.
• -p,包含 POST 请求的正文(要测试的内容).

如果仔细观察这些参数,您会发现通过调整所有这三个参数可以进行很多排列组合.示例 ab 请求将看起来像这样

ab -S -p post_smaller.txt -T application/json -q -n 100000 -c 3000

http://test.haproxy.in:80/ping

这样的请求的示例结果看起来像这样

我们感兴趣的数字是：

• 99％ 的返回请求的响应延迟时间.
• Time per request：每个请求的时间
• No. of failed requests：失败请求数.
• Requests per second: 每秒请求量

ab 的最大问题是它不提供控制每秒发起请求量,因此我们不得不调整 -c 并发级别以获得所需的每秒钟请求数,并导致很多后文提到的问题和错误.

测试图表

我们不能随机地进行多次测试来获得结果,这不会给我们提供任何有意义的信息.我们必须以某种具体的方式执行这些测试,以便从中获得有意义的结果.来看看这个图.

该图表明,在某一点之前,如果不断增加请求数量,延迟将几乎保持不变.然而,达到某个临界点,延迟将开始呈指数级增长.这就是该机器的临界点.

Ganglia

在提供一些测试结果之前,我想提一下 Ganglia.

Ganglia 是用于高性能计算系统(如集群和网格)的可扩展分布式监控系统.

看看截图,了解 Ganglia 是什么,以及它提供的关于底层机器的信息.

（编辑：ASP站长网）