一个开放的Web应用程序框架基准

为下一个应用程序开发项目选择平台可能是一项复杂而繁重的工作。 这也可能非常有趣并且很有趣。 可以采用多种不同的方法：一方面，架构师将参加会议，从Gartner等成熟的技术研究公司购买和研究分析师报告，并将其评估基于分析师的观点。 另一种方法是建立一个跨学科的评估委员会，该委员会将收集组织周围平台需求的愿望清单，并基于共识投票做出决策。 第一种方法非常专制，而第二种方法有时会导致缺乏重点。 对需求和优先顺序的清晰，一致的愿景对于评估的成功至关重要。 由于这些问题，一条中间道路和一种更加务实的方法正变得越来越流行：一群紧密联系的高级螺旋桨使用更经验的方法来分析需求，研究和试验潜在的解决方案堆栈元素，集思广益以产生一份简短的清单使用动手架构练习和气味测试来验证候选人。 尽管动手实验可以带来更好的结果，但是该方法的成本高得令人望而却步，因此通常只能以这种方式评估通过第一阶段筛选的少数解决方案。

平台评估标准取决于项目要求，可能包括：

• 开发人员生产力
• 平台稳定性
• 路线图与预计需求的一致性
• 工具支持
• 信息安全
• 战略伙伴关系
• 开发者生态系统
• 现有软件许可和人力资本投资
• 等等

性能和可伸缩性通常是高度优先考虑的问题。 它们也是可以制定为可量化标准的平台属性之一，尽管这里的主要挑战是如何对用户建模并实施性能测试以准确建模预期的工作负载。 对多个不同平台进行基准测试只能增加基准测试的成本。

一家名为TechEmpower的公司已经启动了一个名为TechEmpower框架基准测试（简称TFB）的项目，旨在比较不同Web框架的性能。 该项目发布了基准测试结果，应用程序开发人员可以在选择框架时用来做出更明智的决策。 FrameworkBenchmarks特别有趣的是，这是以开放方式进行的协作。 与开发相关的讨论在在线论坛上进行，源代码存储库可在GitHub上公开获得。 公开进行测试实施开发对于实现同行评审非常重要，并且可以使实施随着时间的推移而不断发展和改进。 该项目为各种框架实施了性能测试，并且可能会包含您计划使用的框架。 如果没有，您可以创建自己的测试并将其提交以包含在项目代码库中。 您还可以进行测试并在自己的硬件上运行基准测试。

公开发布的测试实现不仅对生成基准数据有用，而且还可以供框架开发人员用来与应用程序开发人员交流与框架性能相关的最佳实践。 它们还允许框架开发人员为优化目的而接收可重现的性能基准测试反馈和数据。

有趣的是，测试实现是由不同的团队和个人设计和构建的，其中某些实现可能比其他实现更严格地进行了优化。 基准衡量框架性能的程度与衡量测试实施的程度一样，在某些情况下，次优的测试实施会导致整体性能不佳。 预计框架火炬手将在优化测试实施方案方面发挥最大作用，因此，在有足够活跃的框架专家的情况下，实施方案应最终收敛到最佳解决方案。

测试类型

用该项目的话来说，所使用的编程语言，框架和数据库的组合被称为“框架排列”或仅仅是排列，并且某些测试类型已在100多种不同的排列中实现。 不同的测试类型包括：

1. JSON序列化
   “测试框架的基础知识，包括保持活动支持，请求路由，请求标头解析，对象实例化，JSON序列化，响应头生成和请求计数吞吐量。”
2. 单数据库查询
   “锻炼框架的对象关系映射器（ORM），随机数生成器，数据库驱动程序和数据库连接池。”
3. 多个数据库查询
   “此测试是测试2的变体，还使用了世界表。 提取多行以更加显着地惩罚数据库驱动程序和连接池。 在测试的最高每次请求查询数（20）下，该测试表明随着数据库活动的增加，所有框架都趋向于每秒零请求。
4. 运势
   “该测试将测试ORM，数据库连接性，动态大小集合，排序，服务器端模板，XSS对策以及字符编码。”
5. 数据库更新
   “该测试是测试＃3的一种变体，它在运行UPDATE语句或类似语句时，测试了ORM对象的持久性以及数据库驱动程序的性能。 该测试的精神是对可变数量的读写样式数据库操作进行测试。”
6. 纯文本
   “该测试仅是对请求路由基础的练习，旨在证明特别是高性能平台的能力。 响应有效载荷仍然很小，这意味着要使测试环境的千兆以太网饱和，仍然需要良好的性能。”

关于第9轮结果的注意事项

当前，最新的基准测试是第9轮，结果数据发布在项目网页上。 数据无法以机器可读的形式获得，因此无法按列进行分类以分析模式。 但是，可以很容易地将其导入电子表格程序，因此我对数据进行了分析。 仅查看原始数据就可以得出一些有趣的观察结果。 除了比较吞吐量之外，比较框架扩展的程度也很有趣。 量化可伸缩性的一种方法是获取每个框架的最低和最高并发级别（对于测试类型1、2、4和6）的测试实现吞吐量数字，并将它们绘制在二维平面上。 然后可以在这两点之间画一条直线，斜率表征可伸缩性。 规模良好的测试实现方式对于测试类型1、2、4和6的斜率应为正，而对于测试类型3和5的斜率则应为负。

由于可伸缩性等级与吞吐量无关，因此该模型并非完全没有问题，因此，例如，性能不佳的框架最终可能具有较大的可伸缩性等级。 结果，您必须一起查看这些数字。

为了更好地可视化并发级别（“峰值托管”环境数据）的吞吐量，我创建了一个小型Web应用程序，该应用程序可从http://tfb-kippo.rhcloud.com/获得 （该应用程序如有删除，恕不另行通知）。

JSON序列化

JSON序列化测试旨在衡量框架开销。 有人可能会说这有点微基准，但它应该证明该框架在执行诸如请求路由，JSON序列化和响应生成之类的基本任务方面的表现如何。

前10个框架基于以下编程语言：C ++，Java，Lua，Ur和Go。 基于C ++的CPPSP显然是赢家，而接下来的6名参赛者都是基于Java的。 此测试类型中不使用数据库。

吞吐量最高的前7个框架也具有最高的可伸缩性等级。 此后，这两个数字开始Swift下降。 这是一个非常简单的测试，看到如此巨大的结果变化令人惊讶。 TechEmpower在其评论中将某些差异归因于框架在基于NUMA的系统体系结构上的工作方式。

相当多的框架都是基于Java或JVM的，并且即使在该组中也存在很大的变化，因此显然，语言和JVM都不是该组的阻碍因素。

我对Node.js和HHVM排名感到惊讶。 不幸的是，由于过时，因此删除了基于Scala的Spray测试实现以及基于JVM的多语言框架Vert.x实现。 希望在以后的基准测试中看到这些内容。

单数据库查询

此测试类型度量数据库访问吞吐量和并行性。 再次，对于相当琐碎的测试案例，可以观察到惊人的性能扩展。 这似乎表明框架或数据库访问方法的开销对结果有很大贡献。 数据库访问技术（DB驱动程序或ORM）是瓶颈吗？ 还是后端系统之一？ 查看测试运行中的系统活动报告以更详细地分析潜在瓶颈会很有趣。

在看到结果之前，我曾希望数据库后端成为瓶颈，但这似乎并不清楚，因为事实是，性能最高的以及许多性能最低的测试实现都使用了同一数据库。 有趣的是，前六个测试实现使用关系数据库，而第一个基于NoSQL的实现则排名第七。 此测试按ID运行DB读取语句，NoSQL数据库应该非常擅长。

表现最佳的10个框架均基于Java，C ++，Lua和PHP语言，并使用MySQL，PostgreSQL和MongoDB数据库。 基于Java的Gemini以CPPSP位居第二。 两者都使用MySQL DB。 基于Spring的测试实现性能令人失望。

多个数据库查询

如果先前的测试对每个请求执行单个数据库查询，则此测试对每个请求进行可变数量的数据库查询。 再一次，我假设此测试将衡量后端数据库性能而不是框架性能，但是看来框架和数据库访问方法的开销也可以做出很大贡献。

该测试中表现最好的两个执行者是使用MongoDB的基于Dart的实现。

该测试中的前10个框架基于Dart，Java，Clojure，PHP和C＃语言，它们使用MongoDB和MySQL数据库。

运势

这是最复杂的测试，旨在测试从请求路由到业务逻辑执行，数据库访问，模板和响应生成的完整框架堆栈。

排名前10位的框架基于C ++，Java，Ur，Scala，PHP语言以及使用的所有数据库（MySQL，PostgreSQL和MongoDB）。

数据库更新

除了阅读之外，该测试还练习数据库更新。

HHVM在接下来的3个基于Node.js的框架中赢得了这项测试。 与单数据库查询测试类似，在NoSQL实现之前，前13个实现使用关系MySQL DB。 此测试通过ID进行简单的读取和写入数据访问，这再次应成为NoSQL数据库的强项之一。

表现最佳的10个框架均基于PHP，JavaScript，Scala，Java和Go语言，所有框架均使用MySQL数据库。

纯文本

该测试的目的是衡量框架在极端负载条件和大规模客户端并行性下的性能。 由于不涉及后端系统依赖性，因此该测试可测量平台和框架的并发限制。 在客户端并发级别达到最大值之前，此测试中的吞吐量停滞或开始降低性能最高的框架，这似乎表明测试设置中的某个瓶颈受到了瓶颈，大概是硬件，操作系统和/或框架并发。

除了CPPSP的峰值达到1024以外，许多框架的并发水平都达到了256的最佳水平。CPPSP是唯一性能最高的实现，能够随着并发级别从256提高而显着提高其性能，但即使使用CPPSP在并发级别达到4,096个标记之后，吞吐量实际上开始下降。 只有12个测试实现每秒能够超过1 M个请求。 一些著名的平台（例如Spring）的表现令人吃惊。

HHVM测试运行似乎存在严重问题，因为它每秒仅生成数十个响应，并发级别为256和1024。

前10个框架基于C ++，Java，Scala和Lua语言。 此测试中不使用数据库。

基准重复性

在科学界，研究必须是可重复的，才能可信。 同样，基准测试方法和相关情况也应记录在案，以使结果可重复且可信。 有一些细节可以记录在案，以提高可重复性。

基准测试项目的源代码似乎没有被标记。 标记对于使基准可重复至关重要。

基准项目网站上提供了有关硬件和其他测试环境参数的简短描述。 但是，环境设置（硬件+软件）预计会随时间而变化，因此，此信息应每轮记录一次。 同样，Linux发行版的次要发行版或确切的Linux内核版本也没有被确定。

可以发布有关服务器内部运行情况的详细数据，以便外部人员可以更有意义的方式分析基准测试结果。 系统活动报告，例如系统资源使用情况（CPU，内存，IO），可以为可能的可伸缩性问题提供有价值的线索。 此外，应用程序，框架，数据库和其他日志对于测试实施者也可能有用。

由于性能原因，Resin被选为Apache Tomcat和其他servlet容器上的Java应用服务器。 尽管我不反对这种说法，但是没有提及软件版本，并且由于性能属性在发行版之间会随时间变化，因此这种前提是不可重复的。

没有针对基于JVM的测试实现执行记录确切的JVM版本或JVM参数。 如果测试实现不覆盖设置，则使用默认的JVM参数。 由于测试实现在定义上具有非常相似的执行配置文件，因此显式配置和共享一些在服务器端应用程序中通常使用的JVM标志可能是有益的。 同样，由于JVM的人体工程学原理，可以根据基础服务器容量和JVM版本自动选择不同的GC参数。 在每个基准测试回合中记录这些参数将有助于重复性。 也许所有中间件软件版本都可以在测试执行期间记录下来，并且可以提供完整的测试运行日志。

定制测试实现：异步Java + NoSQL DB

由于我最近致力于通过异步处理（基于Jersey 2的实现）和Apache Cassandra NoSQL数据库来实现基于JAX-RS 2 API的RESTful服务，我很好奇这种组合在竞争中的表现，因此，我开始进行编码我自己的测试实现。 但是，在这种情况下，我决定删除JAX-RS，以消除可能对性能产生负面影响的所有非必要抽象层。

开始进行测试开发的最大障碍之一是，当我开始我的项目时，还没有一种方法可以测试较小部分的运行平台安装脚本，而您必须运行完整的安装，这非常耗时。很久。 幸运的是，从那时起，框架的安装过程就分开了，因此可以仅安装要为其开发测试的框架。 另外，最近该项目增加了对Vagrant全自动开发环境设置的支持，这是一个很大的帮助。 Travis CI集成是另一个出色的补充，它使测试实施开发人员可以进一步确保其代码在沙盒外也按预期工作。 不幸的是，Travis构建会花费很长时间，因此您可能需要禁用一些未在积极进行的测试。 Travis CI环境与开发人员和实际基准测试环境也有所不同，因此您可能会遇到Travis构建中在开发环境中不会发生的问题，反之亦然。 Travis构建失败有时可能非常晦涩难懂，并且很难进行故障排除。

实际的测试实现代码很容易在真实的基准测试环境之外进行隔离开发和测试，但是，如果要添加对新平台组件（如数据库或测试平台安装脚本）的支持，则在具有以下条件的环境中最简单实际基准测试环境的近似副本。 在这种情况下，添加对新数据库的支持涉及创建新的数据库架构，测试数据生成以及自动执行数据库安装和配置。

事实证明，实现实际的测试排列很有趣，但也很费力。 当用ab和wrk对我的测试实现进行基准测试时，我偶尔会看到奇怪的错误响应，尤其是在更高的负载下。 TFB在Resin Web容器中执行基于Java的性能实现，经过一阵困惑之后，我决定在其他Web容器（即Tomcat和Jetty）中测试代码。 原来，我撞到1级树脂的bug（ 5776 ）和2个Tomcat的错误（ 56736 ， 56739与Servlet支持异步处理相关）。

在体系结构上，已经使用传统的同步Servlet API实现了测试类型1和6，而其余测试实现则通过Servlet 3异步处理支持来利用非阻塞请求处理。 测试实现将其数据存储在Apache Cassandra 2 NoSQL数据库中，该数据库可使用DataStax Java驱动程序进行访问。 为了最小化资源消耗，在数据访问层中还使用了异步处理。 JSON数据由Jackson JSON库处理。 在Java版本早于版本8的情况下，异步处理需要以匿名类的形式传递回调，从语法上讲有时可能有点高礼节。 Java 8 Lambda表达式消除了一些日常开销，但是不幸的是，TFB尚未完全支持最新的Java版本。 我以前使用过JAX-RS 2异步处理API，但没有使用Servlet 3异步API。 我在测试实现过程中注意到的一件事是，Servlet 3异步API提供的用于生成对客户端的错误响应的机制比其JAX-RS异步对等机制低得多，更不直观且更麻烦。

测试实现代码已合并到FrameworkBenchmarks代码库中，因此应在下一轮进行基准测试。 可以在这里找到代码： https : //github.com/TechEmpower/FrameworkBenchmarks/tree/master/frameworks/Java/servlet3-cass

结论

TechEmpower的Framework Benchmarks对Web框架开发人员和用户社区做出了非常宝贵的贡献。 它具有极大的潜力，可以促进框架开发人员与框架用户之间的友好竞争，从而提高流行框架的性能并采用框架性能最佳实践。 与往常一样，还有改进的空间。 从框架用户和测试实施者的角度来看，一些领域包括：使基准测试和结果更具可重复性，发布原始基准数据以用于分析目的，并致力于使测试开发和添加新的框架组件变得更加容易。

出色的TFB团队+贡献者–等不及要看第10轮基准数据！

翻译自: https://www.javacodegeeks.com/2014/09/an-open-web-application-framework-benchmark.html