如何按官方最佳实践对 Envoy 做基准测试并避免常见测量错误【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy如果你需要量化 Envoy 在你自己环境中的 QPS、延迟或资源开销官方文档给出的第一个事实是网络代理不存在一个标准 QPS/延迟/吞吐开销可以直接引用。项目本身目前不发布任何官方基准数据官方 FAQHow 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_DETECTIONfalse关闭设置为 0 时仍然运行一个 worker 线程。如果你的对比对象另一个代理运行在固定 8 个 worker 上你就应该把 Envoy 的--concurrency显式设为 8而不是依赖自动检测。第三步消除配置中的测量噪声官方清单列出了若干会系统性扭曲测量结果的项目以下各项的关闭/调大操作都有文档支撑关闭或等效调高熔断熔断是基准测试中的常见问题Envoy 默认熔断阈值偏低会导致连接和请求排队。官方 FAQ: Is there a way to disable circuit breaking? 说明不存在完全关闭熔断的开关但可以把阈值设为很高的值来等效禁用例如1000000000circuit_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 清单避免已知的基准设计错误。负载工具选择官方建议考虑 NighthawkEnvoy 官方项目作为负载生成器与测量工具并说明会持续在该工具中完善基准测试与延迟测量的最佳实践。它适合配合本文的测量路径使用但不是唯一选项——使用其他工具时上面第三、四步的每一项核查仍然适用。结果的使用边界你得到的数字只能描述这套配置、这个环境、这个版本下的表现换掉过滤链、TLS 设置、连接数或负载生成器行为结果都可能需要重测。官方不提供任何官方基准数字任何引用第三方数字的对比都不受本项目背书。测量结论若要用于横向对比前提是本节各步骤中对比双方一致的项并发数、过滤链功能、TLS、HTTP/2 参数、连接复用策略全部满足。延伸阅读基准测试最佳实践 FAQ、熔断禁用 FAQ、CLI 参考--concurrency。【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考