Tomcat 7上的Spray-servlet与JVM上的Spray-can jar

Question

有没有人根据以下两种组合对他/她的应用程序的性能进行基准测试？

1. 使用spray-servlet构建并部署在JVM 7上的Tomcat 7上
2. 使用喷雾罐构建并在JVM 7上部署为jar

我认为2)在大多数情况下表现优于1),即使1)使用servlet 3.0功能.

我之所以要问的是,我的团队需要权衡性能和应用程序部署/管理(自动扩展,监控等)的简易性,因为AWS Elastic Beanstalk的默认java webapp配置是运行Tomcat的Linux.

对此的任何意见将非常感激.干杯

Answer 1

您应该看看这里：\n http://spray.io/blog/2013-05-24-benchmarking-spray/

\n\n

几天前，techempower 的人员发布了他们当前广受好评的 Web 框架基准测试系列的第 5 轮，这是 Spray 参与的第一个基准测试。techempower 基准测试由许多不同的测试场景组成，这些测试场景练习 Web 框架/堆栈的各个部分，我们仅为其中一个提供了基于喷雾的实现：\xe2\x80\x9cJSON 序列化\xe2\x80\x9d 测试。该基准测试目标框架层的其他部分（例如数据库访问）是 Spray 故意不提供的。

\n\n

以下是第 5 轮 JSON 测试的已发布结果，以替代可视化形式呈现（但显示完全相同的数据）：

\n\n

\n\n

该测试在通过 GB 以太网链路连接的两台相同计算机之间运行，一台客户端计算机使用 wrk 作为负载生成器生成 HTTP 请求，另一台服务器计算机运行相应的 \xe2\x80\x9cbenchmarkee\xe2\x80\x9d。为了表明性能如何随底层硬件平台变化，所有测试都运行两次，一次在两个 EC2 \xe2\x80\x9cm1.large\xe2\x80\x9d 实例之间运行，一次在两个专用 i7-2600K 工作站之间运行。

\n\n

分析

\n\n

在上图中，我们将专用硬件上的性能结果与 EC2 机器上的性能结果进行了比较。我们预计两者之间存在很强的相关性，大多数数据点都围绕趋势线聚集。远离趋势线的 \xe2\x80\x9cbechmarkees\xe2\x80\x9d 要么不按比例放大或缩小，要么像 \xe2\x80\x9cpack\xe2\x80\x9d 一样放大或缩小，或者遭受\xe2\x80\x9cweak\xe2\x80\x9d 端存在一些配置问题（例如 i7 或 Gemini/servlet 上的 cpoll_cppsp 和 onion 以及 EC2 上的 Spark）。无论哪种方式，都可能建议对问题的原因进行一些调查。

\n\n

除了在 30 秒运行结束时绘制 wrk 报告的平均请求数/秒数之外，我们还根据 wrk 报告的平均请求延迟（例如 64 秒内平均 1 毫秒的延迟）对请求计数进行了替代预测。连接数应约为 64K 平均请求/秒）。理想情况下，这些预测结果应大致匹配实际报告的结果（排除任何舍入问题）。

\n\n

然而，正如您在图表中看到的，对于某些基准测试者来说，这两个结果存在很大差异。对我们来说，这表明在相应的测试运行期间有些事情不太正确。也许运行 wrk 的客户端经历了一些其他负载，影响了其生成请求或正确测量延迟的能力。或者我们看到 wrk\xe2\x80\x99s 的结果有点 \xe2\x80\x9cunorthodox\xe2\x80\x9d 请求延迟采样实现。不管怎样，我们对平均值的有效性充满信心。如果两个结果更加一致，则请求计数和延迟数据将会更高。

\n\n

外卖

\n\n

该基准测试的特殊价值源于 techempower 团队成功包含的大量不同框架/库/工具集。第 5 轮提供了由近 70 个（！）基准测试者组成的非常多样化的小组的结果，这些基准测试者用 17 种不同的语言编写。因此，它很好地表明了不同解决方案可以预期的粗略性能特征。例如，您是否期望 Ruby on Rails 应用程序的运行速度比基于 JVM 的良好替代方案慢 10-20 倍？大多数人都会假设性能差异，但其实际程度可能会令人惊讶并且肯定很有趣，不仅对于当前面临技术决策的人来说。

\n\n

对于我们作为 HTTP 堆栈的作者来说，我们会从稍微不同的角度来看待此类基准测试。我们面临的主要问题是：与同一平台上的替代方案相比，我们的解决方案表现如何？我们可以从他们身上学到什么？我们似乎还没有考虑到哪些方面还有优化的潜力？在编写像 Spray 这样的库时，必须做出的各种架构决策对性能有什么影响？

\n\n

从上图中可以看出，我们对在这个特定基准测试中的 Spray\xe2\x80\x99s 性能非常满意。它优于 EC2 上所有其他基于 JVM 的 HTTP 堆栈，并且在查看延迟数据预测的吞吐量时，甚至在专用硬件上也是如此。

\n\n

这表明我们优化 Spray\xe2\x80\x99s HTTP 实现的工作正在取得回报。此基准测试中使用的版本是最近的 Spray 1.1 nightly build，其中包括计划为即将到来的 1.0/1.1/1.2 三重版本（Akka 2.0 为 1.0、Akka 2.1 为 1.1、Akka 2.2 为 1.2）的大多数（但不是全部）性能优化）。

\n\n

但是，这个基准测试是否证明 Spray 是 JVM 上最快的 HTTP 堆栈？

\n\n

不幸的是它没有\xe2\x80\x99t。这个测试练习了各种 HTTP 实现的所有逻辑的一小部分，以便能够正确地对它们进行排名。它给出了一个指示，但仅此而已。

\n\n

缺少什么\xe2\x80\x99s？

\n\n

基准化愿望清单

\n\n

让\xe2\x80\x99s 更仔细地看看 techempower 基准测试的 \xe2\x80\x9cJSON 序列化测试\xe2\x80\x9d 实际执行的操作。客户端创建 8 到 256 个到服务器的长期并发 TCP 连接，并在这些连接上激发尽可能多的测试请求。每个请求都会到达服务器\xe2\x80\x99s NIC，通过 Linux 内核\xe2\x80\x99s 网络堆栈向上冒泡，被基准测试者 IO 抽象接收并传递到 HTTP 层（在该层进行解析和处理）在实际由\xe2\x80\x9c应用程序逻辑\xe2\x80\x9d处理之前可能已路由）。在此基准测试的情况下，应用程序仅创建一个小的 JSON 对象，将其放入 HTTP 响应中并将其发送回堆栈，在堆栈中它再次以相反的方向传递所有层。

\n\n

因此，该基准测试测试了基准测试者的表现：

\n\n

\n
• 与内核交互 \xe2\x80\x9cpulling\xe2\x80\x9d 到达套接字的原始数据
\n
• 管理其内层之间的内部通信（例如 IO <-> HTTP <-> 应用程序）-
\n
• 解析 HTTP 请求并呈现 HTTP 响应
\n
• 序列化小 JSON 对象
\n

\n\n

它使用带有一组固定 HTTP 标头的小请求以及相当少量的长期连接来完成所有这些操作。而且，它一次性完成所有工作，却没有给我们关于堆栈各个部分的潜在优点和缺点的线索。

\n\n

如果我们想更深入地了解 Spray 与基于 JVM 的竞争对手相比的性能以及其优缺点，我们\xe2\x80\x99d 必须设置一系列基准来衡量：

\n\n

\n
• 原始 IO 性能：\n1 表示 50K 长期并发连接、最小请求和响应大小
\n
• 连接设置开销：\n每个请求的连接数不同、最小请求和响应大小
\n
• HTTP 请求解析器性能：\n请求标头数量和标头值大小不同、实体大小不同
\n
• HTTP 响应呈现器性能：\n响应标头数量和标头值大小不同、实体大小不同
\n
• HTTP 分块性能：\nchunked 请求和响应具有不同数量和大小的消息块
\n
• HTTP 管道性能:\n不同数量的请求批量大小
\n
• SSL 性能：\n1 表示 50K 长期连接、最小请求和响应大小
\n
• Websocket性能
\n
• 系统和 JVM 级指标（CPU 利用率、GC 活动等）
\n

\n\n

如果我们有一个基准套件产生这样的数字，我们\xe2\x80\x99d在建立喷雾及其替代品的适当的基于性能的排名方面会感到更加自在。如果有像 \xe2\x80\x9c 连续基准测试\xe2\x80\x9d 基础设施这样的东西，在简单的 git 推送到其存储库时会自动生成这些基准测试结果，那岂不是很棒？

\n\n

哦，好吧...我想我们不断增长的待办事项列表刚刚又收到了一项标记为重要的项目...:)

\n