70

我们正在研究传输/协议解决方案，并且即将进行各种性能测试，所以我想我会与社区核实他们是否已经这样做了：

有没有人对简单的回显服务进行服务器性能测试，以及比较 Linux 上的 EJB3、Thrift 和协议缓冲区的各种消息大小的序列化/反序列化？

主要语言将是 Java、C/C++、Python 和 PHP。

更新：我仍然对此非常感兴趣，如果有人做过任何进一步的基准测试，请告诉我。此外，非常有趣的基准测试显示压缩 JSON 的性能与 Thrift/Protocol Buffers 相似/更好，所以我也将 JSON 扔进了这个问题。

4

8 回答 8

56

最新比较可在thrift-protobuf-compare项目 wiki 上找到。它包括许多其他序列化库。

于 2009-03-23T22:48:30.130 回答
16

我正在一个名为 thrift-protobuf-compare 的开源项目中编写一些代码，比较 protobuf 和 thrift。目前它涵盖的序列化方面很少，但我打算涵盖更多。结果（对于Thrift和Protobuf）在我的博客中进行了讨论，当我到达时我会添加更多内容。您可以查看代码以比较 API、描述语言和生成的代码。我很乐意为实现更全面的比较做出贡献。

于 2008-11-18T00:13:01.637 回答
8

您可能对这个问题感兴趣：“Thrift 与 Protocol Buffers 的最大区别？”

于 2008-11-17T19:52:38.293 回答
8

我使用许多其他数据格式（xml、json、默认对象序列化、hessian、一种专有格式）和用于数据绑定任务（读取和写入）的库（jaxb、快速信息集、手写）测试了 PB 的性能，但不包括节俭的格式。具有多个转换器的格式（如 xml）的性能差异很大，从非常慢到非常快。作者的主张与感知绩效之间的相关性相当弱。尤其是对于那些提出最疯狂要求的包裹。

对于它的价值，我发现 PB 的性能被夸大了（通常不是它的作者，而是其他只知道谁写的人）。在默认设置下，它并没有击败最快的文本 xml 替代方案。使用优化模式（为什么这不是默认的？），它有点快，可以与最快的 JSON 包相媲美。Hessian 相当快，文本 json 也是。专有的二进制格式（这里没有名字，它是公司内部的）是最慢的。Java 对象序列化对于较大的消息来说速度很快，而对于小对象则不那么快（即，每次操作的高固定开销）。使用 PB 消息大小很紧凑，但考虑到您必须做的所有权衡（数据不是自我描述的：如果丢失模式，就会丢失数据；当然有索引和值类型，但从你所拥有的如果需要，可以对字段名称进行逆向工程），

我的观点是（a）实现通常比规范（数据格式）更重要，（b）端到端，最佳品种（不同格式）之间的差异通常不足以决定选择。也就是说，你最好选择你最喜欢使用的格式+API/lib/framework（或者有最好的工具支持），找到最好的实现，看看它是否足够快。如果（且仅当！）不是，请考虑下一个最佳选择。

附言。不确定这里的 EJB3 是什么。也许只是简单的 Java 序列化？

于 2009-03-09T22:46:07.167 回答
5

如果原始净性能是目标，那么没有什么比 IIOP 更好（参见 RMI/IIOP）。尽可能小的占用空间——只有二进制数据，根本没有标记。序列化/反序列化也非常快。

由于它是 IIOP（即 CORBA），几乎所有语言都有绑定。

但我认为性能不是唯一的要求，对吧？

于 2008-11-17T22:25:23.240 回答
4

在我的 PB 的“待办事项”列表顶部附近的一件事是移植 Google 的内部协议缓冲区性能基准 - 这主要是采用机密消息格式并将它们变成完全平淡无奇的格式，然后为数据。

完成后，我想您可以在 Thrift 中构建相同的消息，然后比较性能。

换句话说，我还没有给你的数据——但希望在接下来的几周内......

于 2008-11-17T19:56:14.727 回答
3

为了支持 Vladimir 关于 IIOP 的观点，这里有一个有趣的性能测试，它应该提供一些关于 google 基准的额外信息，因为它比较了 Thrift 和 CORBA。（Performance_TIDorb_vs_Thrift_morfeo.pdf // 链接不再有效）引用该研究：

  • Thrift 对小数据非常有效（基本类型作为操作参数）
  • Thrifts 传输不如具有中型和大型数据（结构和>复杂类型> 1 KB）的 CORBA 高效。

另一个与性能无关的奇怪限制是 Thrift 仅限于返回几个值作为结构 - 尽管这与性能一样，可能肯定可以改进。

有趣的是，Thrift IDL 与 CORBA IDL 非常匹配，很好。我没有使用过 Thrift，它看起来很有趣，尤其是对于较小的消息，并且设计目标之一是减少繁琐的安装，因此这些是 Thrift 的其他优点。也就是说，CORBA 名声不好，有很多优秀的实现，例如omniORB，它具有Python 绑定，易于安装和使用。

已编辑：Thrift 和 CORBA 链接不再有效，但我确实从 CERN 找到了另一篇有用的论文。他们评估了 CORBA 系统的替代品，并且在评估 Thrift时，他们最终选择了 ZeroMQ。虽然 Thrift 在他们的性能测试中表现最快，在 9000 msg/sec 与 8000（ZeroMQ）和 7000+ RDA（基于 CORBA），但由于其他问题，他们选择不进一步测试 Thrift：

它仍然是一个不成熟的产品，具有错误的实现

于 2011-04-05T20:04:16.077 回答
2

我为我的工作研究了 spring-boot、mappers（手动、Dozer 和 MapStruct）、Thrift、REST、SOAP 和 Protocol Buffers 集成。

服务器端：https ://github.com/vlachenal/webservices-bench

客户端：https ://github.com/vlachenal/webservices-bench-client

它还没有完成，已经在我的个人电脑上运行（我必须要求服务器来完成测试）......但结果可以参考：

作为结论：

  • Thrift 提供最佳性能且易于使用
  • 具有 JSON 内容类型的 RESTful Web 服务非常接近 Thrift 的性能，是“可以使用的浏览器”并且非常优雅（从我的角度来看）
  • SOAP 的性能很差，但提供了最好的数据控制
  • Protocol Buffers 具有良好的性能......直到 3 个同时调用......我不知道为什么。它很难使用：我放弃（现在）让它与 MapStruct 一起工作，我不尝试与 Dozer 一起使用。

项目可以通过拉取请求（修复或其他结果）来完成。

于 2017-11-04T12:56:15.417 回答