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

Posted 2023-02-26

【中文标题】Tomcat 7 上的 Spray-servlet 与 JVM 上的 Spray-can jar

【英文标题】：Spray-servlet on Tomcat 7 vs Spray-can jar on JVM

【发布时间】：2013-10-18 01:50:18

【问题描述】：

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

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

我猜 2) 在大多数情况下都比 1) 性能好，即使 1) 使用 servlet 3.0 功能。

我问的原因是我的团队需要权衡性能和应用程序部署/管理（自动扩展、监控等）的易用性，因为 AWS Elastic Beanstalk 的默认 java webapp 配置是运行 Tomcat 的 Linux。

对此的任何意见将不胜感激。干杯

【问题讨论】：

你应该看看这里：blog.xebia.com/2013/08/02/… 和这里spray.io/blog/2013-05-24-benchmarking-spray

@MarceloBezerra 你在这里的评论应该变成答案，所以我可以投票。

好吧...完成了 ;-)

@jordan23 请注意，我已将该博客中的所有文本/内容迁移到答案中，而不仅仅是添加网址/链接好吗？

【参考方案1】：

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

几天前，techempower 的人们发布了他们当前广受好评的 Web 框架基准测试系列的第 5 轮，这是 Spray 参与的第一个。 techempower 基准测试由许多不同的测试场景组成，它们运行 Web 框架/堆栈的各个部分，我们仅提供了一个基于喷雾的实现：“JSON 序列化”测试。此基准测试的其他部分目标框架层（如数据库访问），spray 有意不提供。

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

测试在通过 GB-Ethernet 链接连接的两台相同机器、一台使用 wrk 作为负载生成器生成 HTTP 请求的客户端机器以及运行各自“基准测试”的服务器机器之间运行。为了指示性能如何随底层硬件平台而变化，所有测试都运行两次，一次在两个 EC2“m1.large”实例之间，一次在两个专用 i7-2600K 工作站之间。

分析

在上图中，我们将专用硬件上的性能结果与 EC2 机器上的性能结果进行了比较。我们预计两者之间存在很强的相关性，大多数数据点都围绕趋势线聚集。远离趋势线的“bechmarkees”要么没有像“pack”那样扩大或缩小规模，要么在他们的“弱”方面遭受一些配置问题（例如 i7 上的 cpoll_cppsp 和 onion 或 gemini/servlet 和 spark在 EC2 上）。无论哪种方式，都可能会建议对问题的原因进行一些调查。

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

但是，正如您在图表中看到的那样，对于某些基准测试者来说，这两个结果存在很大差异。对我们来说，这表明在各自的测试运行期间有些事情不太对劲。也许运行 wrk 的客户端遇到了一些其他负载，影响了它生成请求或正确测量延迟的能力。或者我们看到的是 wrk 有点“非正统”的请求延迟采样实现的结果。无论哪种方式，我们对平均值有效性的信心。如果两个结果更接近，请求计数和延迟数据会更高。

外卖

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

对于我们作为 HTTP 堆栈的作者，我们会从稍微不同的角度看待这些基准。我们的主要问题是：与同一平台上的替代方案相比，我们的解决方案表现如何？我们能从他们身上学到什么？我们在哪里仍然有优化的潜力，我们似乎已经留在了桌面上？在编写像 spray 这样的库时，必须做出的各种架构决策对性能有什么影响？

从上图中可以看出，我们可以对喷雾在这个特定基准测试中的表现非常满意。它优于 EC2 上的所有其他基于 JVM 的 HTTP 堆栈，并且在查看延迟数据预测的吞吐量时，即使在专用硬件上也是如此。

这向我们表明，我们在优化 Spray 的 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 )。

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

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

缺少什么？

基准愿望清单

让我们更仔细地看一下 techempower 基准测试的“JSON 序列化测试”实际执行的操作。客户端创建到服务器的 8 到 256 个长期并发 TCP 连接，并通过这些连接触发尽可能多的测试请求。每个请求都到达服务器的 NIC，通过 Linux 内核的网络堆栈冒泡，被基准测试 IO 抽象提取并传递到 HTTP 层（在此进行解析并可能路由），然后由“应用程序逻辑”实际处理”。在此基准测试中，应用程序仅创建一个小型 JSON 对象，将其放入 HTTP 响应中并将其发送回堆栈，然后以相反的方向再次通过所有层。

因此，此基准测试测试基准对象的效果：

与内核交互以“提取”到达套接字的原始数据 管理其内层之间的内部通信（例如 IO HTTP 应用程序）- 解析 HTTP 请求并呈现 HTTP 响应 序列化小的 JSON 对象

它使用带有一组固定 HTTP 标头的小请求通过相当少量的长期连接来完成所有这些工作。此外，它一次完成所有操作，而不会为我们提供有关堆栈各个部分的潜在优势和劣势的线索。

如果我们想更深入地了解 Spray 与基于 JVM 的竞争对手相比表现如何，以及它的优势和劣势在哪里，我们必须设置一系列基准来衡量：

原始 IO 性能： 1 表示 50K 长期并发连接，最小的请求和响应大小 连接设置开销： 不同数量的每个请求连接，最小的请求和响应大小 HTTP 请求解析器性能： 不同数量的请求标头和标头值大小，不同的实体大小 HTTP 响应渲染器性能： 不同数量的响应标头和标头值大小，不同的实体大小 HTTP 分块性能： 具有不同数量和大小的消息块的分块请求和响应 HTTP 流水线性能： 不同数量的请求批量大小 SSL 性能： 1 表示 50K 长连接，最小的请求和响应大小 Websocket 性能 系统级和 JVM 级指标（CPU 利用率、GC-Activity 等）

如果我们有一个能产生这样数字的基准套件，我们会更自在地建立一个基于性能的喷雾及其替代品的适当排名。如果有类似“持续基准测试”的基础设施，它会在简单的 git push 到其存储库时自动生成这些基准测试结果，那不是很好吗？

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