如何按官方最佳实践对 Envoy 做基准测试并避免常见测量错误-编程实验室

如何按官方最佳实践对 Envoy 做基准测试并避免常见测量错误

【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy

如果你需要量化 Envoy 在你自己环境中的 QPS、延迟或资源开销，官方文档给出的第一个事实是：网络代理不存在一个"标准 QPS/延迟/吞吐开销"可以直接引用。项目本身目前不发布任何官方基准数据，官方 FAQ（How fast is Envoy）明确建议用户在"与自己生产环境相近的配置"下自行基准测试；而 What are best practices for benchmarking Envoy? 则给出了官方的测量方法清单。这篇文章把这些实践整理成一条可执行的测量路径：先让被测版本和线程配置可比，再消除配置里的噪声源，最后通过统计项和负载生成器行为核查结果是否可信。

第一步：选择可比的被测版本

测量开始前，Envoy 二进制本身的选择直接决定结果能否用于和别的系统对比：

使用 release 版本二进制。如果自行用 Bazel 构建，构建命令行必须带-c opt。
使用官方 point release 时，选用最新的 point release。官方说明：以 Envoy 的开发节奏，用旧版本来陈述其性能是不合理的。
如果基于 main 分支构建，需要自行确认基准测试工作前后是否有性能回归或改进落地，并尽量靠近 HEAD。

同时，你的测试配置应尽可能接近你计划在生产中使用的配置（来自官方 FAQ 对"没有官方基准"的补充说明），否则结果只反映测试配置，不反映实际部署。

第二步：让 worker 线程配置与其他被测系统对齐

官方要求--concurrencyCLI 选项要么不设置，要么设置为与其他网络代理相同的核数/线程数。不设置时，CLI 文档说明默认行为是：

Linux 上取硬件线程数、CPU 亲和性（cpuset）大小和 cgroup CPU limit 三者中的最小值；
其他平台上取硬件线程数；
这意味着在容器里，Envoy 默认会遵守 Kubernetesresources.limits.cpu或 Docker--cpus的限额；该 cgroup 检测可通过环境变量ENVOY_CGROUP_CPU_DETECTION=false关闭；
设置为 0 时仍然运行一个 worker 线程。

如果你的对比对象（另一个代理）运行在固定 8 个 worker 上，你就应该把 Envoy 的--concurrency显式设为 8，而不是依赖自动检测。

第三步：消除配置中的测量噪声

官方清单列出了若干会系统性扭曲测量结果的项目，以下各项的"关闭/调大"操作都有文档支撑：

关闭（或等效调高）熔断

熔断是基准测试中的常见问题：Envoy 默认熔断阈值偏低，会导致连接和请求排队。官方 FAQ: Is there a way to disable circuit breaking? 说明不存在完全关闭熔断的开关，但可以把阈值设为很高的值来等效禁用，例如1000000000：

circuit_breakers: thresholds: - priority: DEFAULT max_connections: 1000000000 max_pending_requests: 1000000000 max_requests: 1000000000 max_retries: 1000000000 - priority: HIGH max_connections: 1000000000 max_pending_requests: 1000000000 max_requests: 1000000000 max_retries: 1000000000

官方同时提示 Envoy 支持路由级的优先级路由，如有需要可按优先级调整对应阈值。

关闭 request ID 生成

把 HTTP Connection Manager 的generate_request_id置为关闭。

关闭 router 的动态统计

关闭 Router 过滤器的dynamic_stats。如果你测的是"经过 Envoy 相对直连的开销"，可考虑用StatsMatcher的reject_all拒绝全部统计，让 Envoy 尽量不产生统计开销。

保持网络与 HTTP 过滤链可比

过滤链应当反映你正在对比的系统中可对应的功能——不要在 Envoy 侧启用了对比系统不具备的过滤器，或反过来。

TLS 与 HTTP/2 参数保持一致

如果测试涉及 TLS，设置要贴近真实场景，且对比双方使用一致的 cipher；会话复用（session reuse）可能对结果影响显著，可通过 listener SSL 统计（以listener.<address>.ssl.为根）跟踪。
HTTP/2 配置（尤其是影响流控和流并发的选项）在对比中必须一致，官方建议优化时考虑 BDP 和链路延迟。

审查 bootstrap / xDS 配置

官方要求对配置保持批判态度：理想情况下每一行配置都有其存在的理由，并且对当前基准测试是必要的。多余的监听器、集群、过滤器都会进入测量路径。

第四步：跑压测前核查三个最容易出错的地方

以下是官方清单中与负载生成器和线程模型直接相关的、最容易被忽视的测量错误：

1. 连接在 worker 线程上的分布

Envoy 会把一个连接上的所有 stream 分配到同一个 worker 线程。官方的示例：机器有 72 个逻辑核和 72 个 worker 线程，但压测工具只发出一个 HTTP/2 连接时，实际只有 1 个 worker 线程在活动——测出来的"低性能"其实是单线程结果。低连接数 + 完美 keep-alive 的基准尤其容易踩中这一点，压测前应先确认负载生成的连接会如何落到 Envoy 的 worker 上。

2. 请求释放时机

部分负载生成器发出的请求时机天然抖动大或呈批处理形态（jittery / batchy）。官方提示这可能成为某些测试中未预期到的主导因素。压测前应确认请求释放节奏符合测试意图。

3. 连接复用策略

负载生成器如何复用连接（MRU、随机、LRU 等）会影响工作在各 worker 线程间的分布，官方将其列为重要因素。换一种复用策略，同一配置的测量结果可能不同，对比时双方应使用一致策略。

4. 小延迟测量的噪声下限

如果要测量小于 1ms 的延迟，测量工具和环境必须具备相应灵敏度，噪声下限要足够低，否则测出的不是 Envoy 的延迟。

第五步：结果验证——用 listener 和 cluster 统计核对实验

官方验证方法是：在 listener 和 cluster 统计中核对 stream 数、连接数和错误数是否符合实验预期（listener 统计项含义见 listener 统计文档）。如果统计里的连接数与压测工具声称的连接数对不上，或出现非预期错误计数，说明测量路径与实验设计不一致，先查第四步的分布和配置问题，再看 QPS/延迟数字。

此外，官方建议两类"事后核查"手段：

在基准运行期间用perf采集 Envoy 的性能画像（例如生成火焰图），确认 Envoy 的时间花在预期的被测核心工作上，而不是无关的旁支工作上；
关注官方 FAQ 引用的延迟测量最佳实践：不要在最大负载下测延迟（官方认为这通常没有意义、也不反映真实系统表现），应在 QPS-延迟曲线的拐点（knee）以下测量，并优先选用开环（open loop）而非闭环（closed loop）负载生成器；同时注意官方引用的 "benchmarking crimes" 清单，避免已知的基准设计错误。