python - HAProxy 是如何达到它的速度的？

Question

HAProxy 在进行负载均衡时如何避免请求时间开销？

我测试了 HAProxy 并为了好玩将它与用 Twisted (Python) 编写的简单端口转发器进行了比较。在我的初步测试中，通过 HAProxy 负载均衡器发出 HTTP 请求 与发出 相比，请求时间不会增加 开销[1] >HTTP 请求 直接到后端服务器。而我自己的 python 脚本在响应时间中增加了 ~3x 开销。

现在我的脚本是用 Python 和 HAProxy 用 C 编写的，所以先验地，HAProxy 有一个避免 Python 代码经历的调用开销(从 Python 代码到 syscalls)的优点。但这是否可以解释性能上的巨大差异，或者 HAProxy 是否利用一些操作系统技巧来进一步提高性能？我尝试分析我的 Python 代码，但它没有显示 Python 代码中的任何热点，所以我猜测它大部分时间都在 系统调用中 未在分析中考虑。

[1]:如 ab 所报告，有 100 个并发连接和 10,000 个总请求。 HAProxy 的平均时间是 37 毫秒，而我的 Python 脚本是 128 毫秒。

设置

设置是一个 TCP 负载均衡器，带有两个后端 nodejs 服务器，只提供静态文本。本来想测试TCP负载均衡，测试协议(protocol)就变成了HTTP。三台机器都是来自Digital Ocean的虚拟主机，单线程，512MB Ram，1核。 The Python script can be seen here和我的 haproxy.cfg can be found here

Answer 1

原来 HAProxy网站已经涵盖了这个领域(我的错误是忽略了它)。答案基本上是很多低级优化。直接从 HAProxy 网站复制:

HAProxy 涉及操作系统架构中常见的几种技术，以实现绝对最大性能:

• 单进程、事件驱动的模型大大降低了上下文切换的成本和内存使用量。在一毫秒内处理数百个任务是可能的，每个 session 的内存使用量大约为几千字节，而 Apache 类模型中消耗的内存更多为每个进程兆字节。

• O(1) 系统上的事件检查器(Linux 和 FreeBSD)允许瞬时检测任何事件成千上万之间的任何联系。

• 尽可能在读写之间不进行任何数据复制的单缓冲。这节省了大量的 CPU 周期和有用的内存带宽。通常，瓶颈是 CPU 和网络接口(interface)之间的 I/O 总线。在 10 Gbps 时，内存带宽也会成为瓶颈。

• 在 Linux 下使用 splice() 系统调用可以实现零拷贝转发，并从 Linux< 开始实现真正的零拷贝 3.5。这允许小型低于 3 瓦的设备(例如 Seagate Dockstar)以 gigabit/s 的速度转发 HTTP 流量。

• MRU 内存分配器使用固定大小的内存池进行即时内存分配，有利于热缓存区域而不是冷缓存区域。这大大减少了创建新 session 所需的时间。

• 工作因子，例如一次多个accept()，以及在多线程中运行时限制每次迭代的accept() 数量的能力进程模式，使负载均匀分布在进程之间。

• 基于树的存储，大量使用我开发多年的 Elastic Binary 树。这用于保持计时器有序、保持运行队列有序、管理循环和最少连接队列，成本仅为 O(log(N))。

  <

• 优化的 HTTP header 分析: header 在运行中被解析和解释，并且解析被优化以避免重新读取任何先前读取的内存区域。当到达缓冲区末尾且 header 不完整时使用检查点，以便在读取更多数据时解析不会从头开始。在 Pentium-M 1.7 GHz 上解析平均 HTTP 请求通常需要 2 微秒。

• 仔细减少昂贵的系统调用的数量。大多数工作默认在用户空间完成，例如时间读取、缓冲区聚合、文件描述符启用/禁用。