Thrift，协议缓冲区，JSON，EJB等的性能比较？

Question 1

我们正在研究传输/协议解决方案，并且即将进行各种性能测试，因此我认为我应该与社区联系，以了解他们是否已经这样做：

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

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

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

Question 2

Thrift-protobuf-compare项目Wiki中提供了此处的最新比较。它包括许多其他序列化库。

Question 3

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

Question 4

您可能对以下问题感兴趣：“节余与协议缓冲区的最大区别？”

Question 5

我用其他多种数据格式（xml，json，默认对象序列化，粗麻布，一种专有的格式）和用于数据绑定任务（读写）的库（jaxb，快速信息集，手写体）测试了PB的性能，但未包含节俭的格式。具有多个转换器（如xml）的格式的性能差异很大，从非常慢到非常快。作者的主张与感知的表现之间的相关性很弱。特别是对于声称是最疯狂的包装。

对于它的价值，我发现PB的性能有点过分夸大（通常不是它的作者，而是其他只知道谁写的人）。使用默认设置，它没有击败最快的文本xml替代方法。使用优化模式（为什么不是默认模式？），它速度更快，与最快的JSON包相当。粗麻布的速度相当快，文本json也是如此。专有的二进制格式（此处未命名，它是公司内部的）是最慢的。对于较大的消息，Java对象的序列化速度很快，而对于较小的对象，Java对象的序列化速度较快（例如，每个操作的noverhead固定值较高）。使用PB消息时，消息的大小是紧凑的，但是要进行所有折衷处理（数据不是自描述性的：如果丢失架构，则会丢失数据；当然还有索引和值类型，但取决于您拥有的内容）如果需要，可以反向工程回字段名称），

我的观点是（a）实施通常比规范（数据格式）更为重要，（b）端到端，同类最佳（针对不同格式）之间的差异通常不足以指示选择。也就是说，最好选择最喜欢使用的format + API / lib / framework（或具有最佳的工具支持），找到最佳的实现，然后看看它是否足够快地工作。如果（且仅当！）不是，则考虑下一个最佳选择。

ps。不知道这里是什么EJB3。也许仅仅是Java序列化？

Question 6

如果将原始净性能作为目标，那么IIOP将无可匹敌（请参阅RMI / IIOP）。最小的占用空间-仅二进制数据，完全没有标记。序列化/反序列化也非常快。

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

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

Question 7

我的PB待办事项列表顶部附近的一件事是移植Google内部的Protocol Buffer性能基准测试-这主要是采取机密消息格式并将其转换为完全冷淡的情况，然后对数据。

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

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

Question 8

为了支持弗拉基米尔关于IIOP的观点，这是一个有趣的性能测试，该测试应提供Google基准之上的一些其他信息，因为它比较了Thrift和CORBA。（Performance_TIDorb_vs_Thrift_morfeo.pdf //链接不再有效）引用研究报告：

节俭对于小数据（基本类型作为操作参数）非常有效

节俭传输的效率不及具有大中数据（结构和复杂类型> 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：

它仍然是一个有问题的实现的不成熟产品

Question 9

我已经完成了有关弹簧引导，映射器（手动，Dozer和MapStruct），Thrift，REST，SOAP和协议缓冲区集成的研究。

服务器端： 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

结论：

节俭提供最佳性能，并且易于使用
带有JSON内容类型的RESTful Web服务非常接近Thrift性能，“浏览器可以使用”并且非常优雅（从我的角度来看）
SOAP的性能很差，但是提供了最佳的数据控制
协议缓冲区具有良好的性能...直到同时进行3次调用...我不知道为什么。使用起来非常困难：我暂时（暂时）放弃使其与MapStruct一起使用，而我不尝试与Dozer一起使用。

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