转自：https://www.oschina.net/news/96951/framework-benchmarks-round-16

在 TechEmpower Framework Benchmarks 项目 5 周年之际发布了新一轮测试报告: Round 16. 这一轮对于那些稀饭大数字的人具有相当吸引力. 我们这里说的可不仅仅是每秒吞吐量(有些数字已经大过天了), 还有运行的测试数目(~1830), 测试的框架组合 (~464), 涉及的编程语言 (26), 还有运行一轮所需要的时间 (67 小时, 或者说 2410 亿毫秒). 欢迎各位前来围观我们的测试报告以及其中漫威式的数字吧.

最近几个月可谓这个项目最富有激情的阶段. 这段时间我们的社区贡献了许多非常棒的测试实现, 展现了(友善的)性能比拼带来的趣味. 回头我们会继续阐述这点. 这次将是一个稍长一点的 TFB 正式结果宣布, 因为有很多东西我们想和大家一起分享, 所以请耐心读下去吧.

刀客满天飞… 刀客飞… 刀客行?

在 15 轮结束之后, 我们大胆挑战了一个超级任务: 将大约 460 个测试实现从自家酿造的沙箱配置迁移到 Docker 容器中. 这个的确花了我们不少时间, 不过很值得, 整个项目因此受益匪浅.

尤为重要的是因为采用了 Docker, 测试的可重复性和测量的一致性比其以前有明显提升. 从我们的持续测试结果反馈发现, 每次完整测试之间的变动非常小了.

而我们基本检测发现因为 Docker 化带来的性能影响基本上可以忽略不计, 即便有, 也是均匀施加与所有测试上面.

讲真, 我们这个项目对 Docker 来说是一个完美匹配, 或者 Docker 对于我们的项目来讲是个完美匹配. 唯一的遗憾是当初我怎么没有碰到你. 还有就是 Docker 的动词形式是?

刀客满天飞(Dockerificationization.)

新硬件平台

三月份的时候我们已经宣布了本轮将在新的硬件平台上运行, 我们称之为"Citrine", 拥有 Dell  R440 服务器. 每个都配备了一颗 Xeon Gold 5120 芯, 和一个 10GB 的 cisco 以太网交换机.

因为硬件设备的更换以及 Docker 的引入, 我们没有生成 R15 和 R16 的变更报告. 因为数据太不相同了,基本上没有可比性.简单地说 R16 的成绩比 R15 会好很多.

在某些测试中由于吞吐量太庞大了, 我们遇到了"网络饱和"问题. 还记得 Round 8 吗? 那次也是同样的问题, 但当时我们实在 1GB 的网络上饱和, 这次是 10GB 啊. 我们下次会搞定这个问题的.

(感谢 Server Central 为前几轮测试提供硬件!)

Plaintext 和 JSON 测试结果的聚集现象

在 Round 16 之前的持续测试中我们已经发现 Plaintext 和 JSON 测试的结果聚集到了 10G 网络的理论上限. 这意味着一些框架和平台在允许 HTTP pipelining 的情况下让我们的 10G 网络被 140 字节的响应塞满了, 而我们用的还是一些并不昂贵的商用服务器!

瓶颈现在到了网络层, 我们正在计划解决这个问题. 目前的想法是用使用光纤和我们 Cisco 交换机上的 QSFP28 接口对我们的网络扩容.

希望能在 Round 17 的时候看到更多关于这个计划的情况

持续性能测试

在 Round 16 之前我们引入了持续性能测试, 我们的 持续性能测试平台 在这几个月愈加完善, 和我们的"刀客行" 一起构建了一个近乎完美的系统, 每隔 67 小时就能让我们看到新一轮测试结果.

我们想 mark 的几点:

• 我们并不想搞什么完美的测试结果. 这里的完美是指测试代码的稳定性和实现细节, 而我们在此并不特意关注这些. 我们的关注点在于参与者是否能持续提高他们框架的性能以及是否能吸引更多的参与者贡献新的测试. 我们也希望展现今天 Web 开发的多样性. 关注所谓完美将让我们偏离我们的既定方向.

• (现在)一次完整的性能测试过程需要 67 小时. 这个时间会随测试实现的增删而浮动

• 我们总会增添更多的测试实现, 因此总测试时间会相应延长. 另一方面,我们正在考虑增加单个测试项目的运行时间. 这也将导致总测试时间线性增长

• 我们已经注意到社区在引用持续性能测试结果. 处于我们 (TechEmpower) 自身的需要, 我们还是会继续定期并发布官方测试报告, 如同本次的 Round 16. 我们也可以利用这个机会写点博客吸引下眼球不是? 我们希望各位看官继续关注我们的官方测试报告,踩捧随意,只要搞得热闹就行

• 总的来说, 持续测试结果是为框架作者和测试代码贡献者提供的. 而官方报告则是持续测试结果的低频度采集, 为所有对 Web 框架性能数据感兴趣的人提供指导性数据

关于社交媒体

我们为TechEmpower Framework Benchmarks project 创建了一个 twitter 帐号: @TFBenchmarks. 别忘了艾特我们.

Round 16 期间我们一直使用社交媒体与社区互动, 并和一些框架的社区合作搞了性能优化活动. Rust 的框架以黑马的姿态强势闯入 C, C++, Go, Java 和 C# 的阵营, 成为拥有顶级性能的服务端选手

谈到 C#, 这个来自牛气哄哄的微软的框架在最近几轮性能比拼中狂闪黑马光环. 小子, ASP.NET Core 可不是你老爹时代的 ASP.NET 了.

性能在我心

五年前我们发起这个项目的时候没有某个特殊目的. 而是一些交织在一起的动机促使了这个项目的诞生: 对蜗速般 Web 应用的无语; 一种希望看到跨平台性能高端量化数据的渴望; 对性能优化结果预测的证实(或证伪), 或者说揭示性能的奥秘. 而最重要的是我们可能通过此项目来说服人们更多关注性能而让所有的 web 应用开发者获益.

一开始我们对项目的期望并不是很高, 而持续不断的鼓励让我们感受到项目正在直接或间接发挥出重要的影响, 我们为此非常振奋.

当被问及这个项目的时候, 我 (Brian) 总是会说平台和框架是性能的提升最好的地方,这样能惠及所有使用该平台或框架的应用开发. 当你的平台/框架的性能天花板提升之后, 应用开发就获得额外的空间, 这对他们来讲这是一种天赐, 让他们更加自由的发挥. 与此同时他们可以将性能的担忧放到后面, 某些情况下甚至永远也无需虑及性能. 而那些工作在低速平台的应用开发者则无此幸运, 受限与平台的性能, 他们常常被迫在应用中引入一些架构级武器, 比如消息队列, 工作队列, 集群等, 为应用开发带来额外的复杂度.

当看到开发者升级到最新的平台/框架享受到性能提升的时候, 我们也同样开心. 

我希望此项目所有的参与者能一起分享这种欢乐. 对其他关注软件速度的朋友也是一样

Round 17 我们来了!

最后

Round 16 结果:

• Run 6bb9ecf9-5be0-4cb4-b52b-16ea1a3b105b - 云端结果 - 由 Azure 云提供测试环境.

• Run aad43f39-48a2-460c-a363-99cd543a772a - 来自我们的 Citrine 服务器结果.