性能与容量规划
典型 CPU 使用率数据显示，在 TCP 或 HTTP 关闭模式下，HAProxy 占用约 15% 的处理时间，内核占用约 85%；在 HTTP 持久连接模式下，HAProxy 占用约 30%，内核占用约 70%。这表明操作系统及其调优对整体性能有显著影响。
不同用户的应用场景差异很大，有的关注带宽，有的关注请求速率，有的关注连接并发数，有的关注 SSL 性能。本节将提供一些容量规划的参考依据。
请注意，每次操作都会带来开销，因此每个独立操作都会在其余操作的基础上增加额外开销，这种开销在某些情况下可能微不足道，而在其他情况下则可能成为主要影响因素。
在处理来自连接的请求时，我们可以说：
转发数据的开销低于解析请求或响应头；
解析请求或响应头的开销小于建立并关闭与服务器的连接；
建立和关闭一个连接的开销小于一次 TLS 恢复操作；
一次 TLS 会话恢复操作的开销低于一次完整的 TLS 握手及密钥计算；
空闲连接消耗的 CPU 资源少于缓冲区中持有数据的连接；
一个 TLS 上下文所消耗的内存比包含数据的连接还要多；
因此，在实际应用中，处理负载字节的成本低于处理头字节，所以通过大对象（单位体积请求数较少）实现高网络带宽比通过小对象（单位体积请求数较多）更容易。这解释了为何最大带宽始终以大对象进行测量，而请求速率或连接速率则以小对象进行测量。
某些操作在多个 CPU 上分布的多个进程间可实现良好扩展，而另一些则扩展效果不佳。网络带宽的扩展能力有限，因为对于大对象而言，CPU 通常并非瓶颈，主要瓶颈在于网络带宽以及连接网络接口的数据总线。由于本地端口表操作涉及少量锁，连接速率在多进程间扩展效果不佳。持久连接上的请求速率扩展效果极佳，因其几乎不占用内存和网络带宽，也无需访问加锁结构。TLS 密钥计算扩展效果极佳，因其完全由 CPU 承载。TLS 会话恢复扩展效果中等，但在约 4 个进程时达到极限，此时访问共享表的开销抵消了因增加处理能力而预期获得的微小收益。
在经过充分调优的系统上，可预期的性能指标范围如下。应将其视为数量级参考，实际性能可能因处理器、IRQ 设置、内存类型、网络接口类型、操作系统调优等因素而出现显著波动。
以下数据来自一台运行在 3.7 GHz 的 Core i7 处理器，配备双端口 10 Gbps 网卡，运行 Linux 内核 3.10、HAProxy 1.6 和 OpenSSL 1.0.2 的系统。HAProxy 以单进程模式运行于单个专用 CPU 核心，另有两个核心专门用于网络中断处理：
20 Gbps 的最大网络带宽（明文传输），适用于 256 kB 及以上对象，41 kB 及以上对象为 10 Gbps；
使用 AES256-GCM 密码套件传输大对象时，TLS 流量可达 4.6 Gbps；
每秒从客户端到服务器的 83000 个 TCP 连接；
每秒 82000 个客户端到服务器的 HTTP 连接；
每秒 97000 个 HTTP 请求，服务器关闭模式（与客户端保持持久连接，与服务器关闭连接）；
每秒 243000 个 HTTP 请求，处于端到端持久连接模式；
每秒过滤 300000 个 TCP 连接（抗 DDoS）；
每秒 160000 个 HTTPS 请求，运行于持久 TLS 连接的持久连接模式下；
使用会话恢复的 TLS 连接时，每秒可处理 13100 个 HTTPS 请求；
每秒 1300 个 HTTPS 连接，使用 RSA2048 重新协商的 TLS 连接；
每 GB 内存可支持 20000 个并发饱和连接，包含系统缓冲区所需的内存；通过精细调优可获得更优结果，但此配置易于实现。
每 GB 内存可支持约 8000 个并发 TLS 连接（仅客户端侧），包含系统缓冲区所需的内存；
每 GB 内存可支持约 5000 个并发端到端 TLS 连接（双向），包括系统缓冲区所需的内存；
一项较新的基准测试显示，在 AWS 的 64 核 ARM Graviton2 处理器上运行启用了多线程的 HAProxy 2.4，实现了每秒 200 万次 HTTPS 请求、响应时间低于毫秒级，以及 100 Gbps 的流量处理能力：
因此，一个值得牢记的实用原则是：在 TLS 持久连接与 TLS 会话恢复之间，以及在 TLS 会话恢复与 TLS 重新协商之间，请求速率会降低约 10 倍；而在 HTTP 持久连接与 HTTP 关闭之间，请求速率仅降低约 3 倍。另一个值得牢记的实用原则是：具备 AES 指令集的高频核心每核可实现约 20 Gbps 的 AES-GCM 加解密性能。
另一个良好的经验法则是，同一台服务器上，HAProxy 可以达到的饱和程度为：
约 5 至 10 个静态文件服务器或缓存代理；
约 100 个防病毒代理；
以及根据所用技术，约 100 至 1000 台应用服务器。