web框架性能基准_Web框架基准测试-第10轮

web框架性能基准

TechEmpower Web框架基准测试是我去年在博客上发布的一个协作性，开放式Web框架基准测试项目（请参阅开放式Web应用程序框架基准测试 ）。 自上次撰写以来，已经进行了新的基准测试，其中包含许多新的测试实现。 其中，第10轮基准测试运行包括对Cassandra NoSQL数据库的支持，以及利用Servlet 3异步处理的基于Java的新测试实现。

我对TFB第10轮结果做了一些非科学的分析，以下是一些有关Peak环境（“最佳”并发级别结果）的观察结果。 根据第10轮和第9轮的文档，Peak托管硬件规格相同，因此结果应可直接比较。

JSON序列化测试

lwan在JSON序列化测试中大大超越了之前的第一名，在第9轮获胜者的吞吐量上增长了一倍以上。 上一轮的获胜者cpoll_cppsp的吞吐量也提高了近70万个请求/秒。 来自第9轮的6名选手进入了第10轮的前10名，他们所有人都有能力提高自己的表现。 OpenResty成功将其第9轮的吞吐量提高了一倍以上。

我的新进入者servlet3-cass在该类别中排名第五，这使其成为性能第二好的Java实现，仅次于Netty。 基于此，我可以得出结论，在此测试中，Servlet容器的开销目前似乎并不构成重大瓶颈。 有趣的是，尽管实现非常相似，但是servlet和servlet3-cass性能之间大约有400 req / s的差异。 两者都已在Servlet API上实现，在Resin Servlet容器上运行，并使用Jackson进行JSON处理。 两者之间的唯一区别似乎是Jackson JSON库版本号。

前十大测试实现基于以下编程语言：C，C ++，Java和Lua。 在排名前10位的公司中，有5位是基于Java的，而Ur和Go则从上一轮排名的前10位中退出。

单一数据库查询测试

自第9轮以来，在该测试类别中，排名第一的表演者的吞吐量仅略有提高。 基于C ++的测试实现在前4位中占据主导地位，而Lua，Ur和Java也在前10位中。只有基于关系数据库的测试实现才进入前10位，而忽略了MongoDB和Cassandra。

对于该测试，某些测试实现似乎在结果表中具有多个条目（例如cpoll_cppsp-postgres，undertow和activeweb）。 我猜这是因为测试多次运行，但是我希望每个框架在最佳结果表中仅列出一次。 此外，在这些情况下，确切的测试方法是什么？ 框架在什么条件下可以多次尝试？ 自第9轮以来，某些测试实现似乎经历了性能下降。OpenResty是这样的示例。 进一步分析原因很有趣。 降级是由例如测试实施的更改，基础架构设置或测试方法的更改引起的吗？

我对数据库测试中servlet3-cass测试实现的性能感到有些失望。 不幸的是，没有用于测试运行的资源使用或配置文件数据，而且由于我本人无法访问真实的性能测试环境，因此很难进一步分析潜在的瓶颈。

因为Servlet3-cass通过JSON测试能够达到单个数据库查询吞吐量的14倍，所以我认为在数据库测试中不会遇到固有的应用服务器框架瓶颈。 相比之下，使用MySQL数据库的基于Java和Servlet API的测试实现能够实现近两倍的吞吐量。 这两个测试实现之间有两个值得注意的实现差异：a）不同的数据存储区，b）使用不同的servlet API（同步与异步）。

由于Cassandra通常非常快地通过键读取和写入数据，因此应该没有比基于MySQL的实现更糟糕的内在原因。 我需要更详细地分析一些方面：1）Cassandra服务器配置2）Resin servlet容器异步处理支持和/或配置3）检查Resin异步处理和Cassandra驱动程序的线程池大小是否针对测试服务器硬件并发级别进行了优化。 在测试实现期间，我遇到了Servlet容器异步处理支持中的两个错误（包括Resin + Tomcat。两个团队都为修复它们而致以荣誉！），这证明了异步处理不仅对于应用程序而且是一个棘手的问题，而且应用服务器开发人员。 为了评估异步处理的某些方面是否会对性能产生负面影响，使用传统的同步Servlet API进行测试将很有趣。

多个数据库查询测试

此测试中最好的两个实现（开始和流式传输）能够保持第9轮的位置，同时将吞吐量提高30％以上。 前十大测试实现基于Dart，Java，C ++和Clojure。

基于MongoDB的实现在该测试中赢得了三项胜利，其后的4种实现均基于PostgreSQL。

命运测试

与上一轮相比，有五个新的测试实现使其进入了前十名。 前10个实现是用C ++，Ur和Java实现的。 同样，在第9轮数据表中，欠锯齿和欠锯齿边缘似乎都包含了3次，这对于最佳结果表来说似乎有些奇怪。

数据库更新测试

在第9轮中排名前3位的基于Node.js的实现已被基于C ++的实现所超越。 预期此测试类型将代替原始处理效率，而主要强调后端数据存储，数据存储驱动程序和框架的并行性，因此C ++作为一种语言不应具有固有的优势。 该测试中排名前10位的实现语言是：C ++，JavaScript，Scala，Dart和Perl。

多年前完成了许多Perl编程，我很着迷于看到基于旧脚本主力的实现将其排在前10位。

在此测试中，前5个实现的性能下降了约10％。

在第9轮中，排名前10的实现全部基于MySQL，而在第10轮中，基于PostgreSQL三个实现进入前10名。

明文测试

基于C ++，C，Java和Scala的测试实现占据了该类别中的前10名。 尽管排名第一的位置仅出现了适度的提升，但ulib超越了榜首。 四个新进入者进入了前10名。与前一轮相比，Netty的吞吐量增长了40％以上。

开发过程

TechEmpower团队再次为FrameworkBenchmarks项目投入了巨大的精力，并在此方面做得很好！ 尽管如此，与所有内容一样，总有改进的空间，并且从临时测试实施贡献者的角度来看，应考虑以下问题：

• 更可预测的发布时间表。 我意识到TE团队需要优先考虑实际的客户项目，而不是无偿工作。 但是，许多测试实施者的处境相似，因此制定可预测的发布计划将有助于贡献者安排工作。 似乎至少部分延迟是由范围蠕变引起的，因此更严格的发布策略也可以帮助使发布计划更可预测。
• 发布阶段更改通知。 并非所有贡献者都可以关注TFB Google小组讨论。 具有通知机制以通知发布时间表阶段更改可能对许多贡献者有所帮助。 这可能很简单，例如可以订阅Github刊物，也可以是单独的Google网上论坛来发布公告。
• 在预览运行（功能测试运行）期间启用测试实现日志记录。 我发现在预览运行期间很难解决与基础架构部署自动化相关的错误。 允许服务器端记录预览运行可能对测试实施人员对其代码进行故障排除很有帮助。
• 提供预览运行的资源消耗统计信息。 测试实施者当前获得的唯一性能指标是每个测试的吞吐量数字和并发级别。 就优化反馈而言，这给实现者带来的帮助很少。
• 提供对应用程序服务器，数据库服务器等日志的访问。 其他基础结构日志将有助于识别与功能和性能相关的问题。
• 与性能相关的数据收集甚至可以通过在预览运行期间使用性能分析工具运行测试实现来进一步进行。

基准结果可视化工具已更新

我已经更新了我创建的TFB项目结果可视化工具，也可以渲染第10轮结果。 和以前一样，可以在以下位置找到该工具： http : //tfb-kippo.rhcloud.com/

一个新的基于Scala + ElasticSearch的测试实现

项目团队一直在努力工作，他们已经发布了第11轮结果的暂定发布时间表，旨在于2015年6月底发布。自第10轮以来，我还为ElasticSearch搜索服务器提供了支持作为基于Scala / Spray的测试实现。 两者都已合并到项目存储库中，因此在发布第11轮数据时，结果应该可用。

• 可以在以下位置找到用于新测试实现的代码： https : //github.com/TechEmpower/FrameworkBenchmarks/tree/master/frameworks/Scala/spray-es

同样，出色的TFB开发团队和贡献者–继续努力！

期待看到第11轮结果！

翻译自: https://www.javacodegeeks.com/2015/06/web-framework-benchmarks-round-10.html

web框架性能基准