Curl 性能

# curl 性能 来源：https://daniel.haxx.se/blog/2026/08/14/curl-performance-2/ *太长不看：实时版本在：https://curl.se/perf/* “快”到底有多快？是否已经足够好？它现在跑得和以前一样快吗，还是出现了性能回退？到底什么需要快？它有多快？ 这些问题许多项目和产品都会面对，curl 也不例外。然而，性能测试和比较*很困难*，而且布满雷区，容易浪费大量时间。多年来，我们偶尔会提起为 curl 建立一个性能测试套件的想法，但最终又放弃了，因为挑战看起来很棘手，而且也没有人自愿来做这件事。 这周情况变了。 ## 那就开始吧 我最初尝试寻找现有的托管开源项目性能结果的服务，这样我们就可以把结果输入进去，获得出色的可视化和数据管理。但我没有找到这样的服务。 然后我考察了现有的工具，大多数线索都表明 Grafana 是一个流行甚至可能很好用的方案，可以用来构建类似的东西。但是天哪，那真是一台复杂的机器，光是搞清楚从哪里或如何开始就让人感觉不知所措。我决定也先搁置这个方案。 ## 让*我*来做 我决定不去尝试以最佳、最优的方式来做这件事——我不该让“完美”成为“良好”的敌人——我会先做我力所能及的事情，一步一步尽可能往前推进。*有点什么总比什么都没有强*。 性能测试需要相当稳定的系统环境，这样才能在各方面条件一致时，重复运行得到相近的结果。这在大多数云基础设施上基本无法做到，因为那些环境几乎总是与无数其他用户共享。至少在我们使用的廉价或免费层级上是这样。 我们可能需要自己的专用硬件，但我没有先去琢磨从哪里弄和怎么安排，而是选择在自己本地的开发机上跑性能测试。这台机器只有我一个用户，核心很多，跑得也相当快。用来启动这个项目应该足够了。 我写了第一个 shell 脚本，从 git 更新 curl 源代码，然后配置、构建。之后再运行一系列测试，输出一批数据，并把所有输出记录到一个日志文件中。我先从几个简单的测试开始：curl 从 localhost 下载一个 100 GB 的文件能有多快？单次 HTTP 下载需要多少次内存分配、每次分配多大？ 第二个脚本解析之前每次构建产生的所有测试日志文件，并生成摘要和图表。目的是让人类能直观看到各构建之间的性能变化，理想情况下还能自动检测到某些指标的变化超出了可接受的范围。 由于我之前就是个图表爱好者（https://curl.se/dashboard.html），那段经历也让我稍微学会了一点 gnuplot（http://www.gnuplot.info/）。我断定，虽然可能有更好的工具和花哨的 JavaScript 方案*可以*用，但我不熟悉它们，而且现在学习它们是一件我宁愿避免的事。所以我坚持用我熟悉的、能快速出结果的东西。 第三个脚本由 crontab 每二十分钟调用一次，设置一些变量并调用运行脚本。 基础功能跑通之后，我把早期版本给 curl 的朋友们看，并很快为代码建立了一个新的 git 仓库（https://github.com/curl/perf）。 ## 上线了，宝贝 又稍微折腾了一阵后，我很快让我本地生成的性能测试摘要打包，并在每次构建后自动传输到 curl 网站（https://curl.se/per