Thrift、Protocol Buffers、JSON、EJB、其他的性能比较？答案

【问题标题】：Performance comparison of Thrift, Protocol Buffers, JSON, EJB, other?Thrift、Protocol Buffers、JSON、EJB、其他的性能比较？
【发布时间】：2010-09-22 17:42:03
【问题描述】：

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

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

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

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

【问题讨论】：

谢谢。我也很想在那里看到Fast Infoset（ITU-T Rec. X.891 | ISO/IEC 24824-1）和EXI（W3C）。
从code.google.com/p/thrift-protobuf-compare/wiki/BeyondNumbers看来，JSON 基准测试只是手动将缩写字符串写入输出。
我目前每天都在使用 protobufers，我的经验告诉我，基准测试并没有说明有人必须序列化或反序列化的情况或进程中的内存消耗。一个例子是 OSI 开放模拟接口，它是一个由消息和数组组成的复杂网络。如果您尝试将其序列化并将其与任何其他协议进行比较，情况会有所不同。我想说的是，您必须尝试使用不同的协议构建相同的系统，然后根据您的情况进行比较并做出决定。如果您正在尝试，尤其如此

标签： java python performance protocol-buffers thrift

【解决方案1】：

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

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

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

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

笔记本电脑：https://github.com/vlachenal/webservices-bench/blob/master/results.md
桌面：https://github.com/vlachenal/webservices-bench/blob/master/results-desktop.md

结论：

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

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

【讨论】：

虽然此链接可能会回答问题，但最好在此处包含答案的基本部分并提供链接以供参考。如果链接页面发生更改，仅链接答案可能会失效。 - From Review
好吧对不起我之前的帖子。我添加了我的结论。如果需要更多详细信息，我会添加它们。

【解决方案2】：

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

Thrift 非常高效数据（作为操作的基本类型论据）

Thrifts 传输不如具有中等和大数据（结构和>复杂类型 > 1 KB）。

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

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

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

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

【讨论】：

【解决方案3】：

thrift-protobuf-compare 项目 wiki 上提供了最新比较。它包括许多其他序列化库。

【讨论】：

【解决方案4】：

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

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

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

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

【讨论】：

也许您可以在博客文章中发布结果？我当然有兴趣查看详细信息，尤其是关于 XML 测试的内容。
好的。事物的核心位于 Codehaus 的 Woodstox (woodstox.codehaus.org) 存储库的“StaxBind”模块下；这只是为了方便。没有伍德斯托克斯-特定的。我会尽量把结果发表出来——如果没有人能复制它们，那就太令人沮丧了。

【解决方案5】：

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

【讨论】：

我刚刚添加了一个问题 - 您正在使用协议缓冲区的默认选项，这意味着“优化小代码大小”。这对性能有巨大的影响（但确实会导致更小的代码）。您应该在打开 optimize_for = SPEED 的情况下进行比较。

【解决方案6】：

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

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

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

【讨论】：

性能绝对不是唯一的要求。我们可以处理或可以相当容易地评估的其他要求；性能是我一直在寻找反馈的。
“仅二进制数据”并不意味着它一定是最小的可能占用空间。例如，您可以将 Int32 传输为“仅 4 个字节”，也可以使用一种编码来减少小值的传输大小，但代价是对大值使用更多数据。
根据我的经验，不用担心严格的位打包协议而只需 zlib 流式传输您的数据会更便宜。那些你不需要压缩的位中的 0 压缩得很好（假设你对 bufs 进行了零初始化）。这通常优于手动位打包，并且更容易调试。无论如何，假设 zlib 是一个选项。

【解决方案7】：

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

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

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

【讨论】：

Thrift-protobuf-comparison 项目 (code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking) 将是一个很好的家，如果你做了什么？很高兴看到不同的用例——当前的用例处理非常少的消息，这只是一个领域。
我现在有一个基准测试框架，但它主要旨在对协议缓冲区的不同实现和不同消息进行基准测试。见code.google.com/p/protobuf-csharp-port/wiki/ProtoBench

【解决方案8】：

您可能对此问题感兴趣："Biggest differences of Thrift vs Protocol Buffers?"

【讨论】：