有没有人在以下两种组合中对他/她的应用程序的性能进行了基准测试？
我猜 2) 在大多数情况下都比 1) 性能好，即使 1) 使用 servlet 3.0 特性。
我问的原因是我的团队需要权衡性能和应用程序部署/管理（自动扩展、监控等）的易用性，因为 AWS Elastic Beanstalk 的默认 java webapp 配置是运行 Tomcat 的 Linux。
对此的任何意见将不胜感激。干杯
你应该看看这里： 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 毫秒平均延迟，64连接应该会导致大约 64K avg. req/s）。理想情况下，这些预计结果应与实际报告的结果大致匹配（禁止任何舍入问题）。
但是，正如您在图表中看到的那样，对于某些基准测试者而言，这两个结果存在很大差异。对我们来说，这表明在各自的测试运行期间有些事情不太对劲。也许运行 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 响应中并将它发送回堆栈，在那里它再次以相反的方向传递所有层。
因此，这个基准测试了基准测试者的表现如何：
它使用带有一组固定 HTTP 标头的小请求通过相当少量的长期连接来完成所有这些工作。此外，它一次完成所有操作，而没有给我们关于堆栈各个部分的潜在优势和劣势的线索。
如果我们想更深入地了解 Spray 与基于 JVM 的竞争对手相比如何表现以及它的优势和劣势在哪里，我们必须设置一系列基准来衡量：
如果我们有一个基准套件产生这样的数字，我们会在建立一个适当的基于性能的喷雾及其替代品排名时感到更加自在。如果有类似“持续基准测试”的基础设施，它会在简单的 git push 到其存储库时自动生成这些基准测试结果，那不是很好吗？
哦，好吧...我猜我们不断增长的待办事项列表刚刚收到了一个标记为重要的项目... :)