Thrift,Protocol Buffers,JSON,EJB等的性能比较？

Question

我们正在研究传输/协议解决方案,并且即将进行各种性能测试,所以我想如果他们已经这样做了,我会向社区查询:

有没有人为简单的echo服务进行服务器性能测试,以及比较Linux上的EJB3,Thrift和Protocol Buffers的各种消息大小的序列化/反序列化？

主要语言是Java,C/C++,Python和PHP.

更新:我对此仍然很感兴趣,如果有人做了进一步的基准测试,请告诉我.此外,非常有趣的基准测试显示压缩JSON执行与Thrift/Protocol Buffers相似/更好,因此我也将JSON抛入此问题.

Answer 1

最新的比较可以在thrift-protobuf-compare项目维基上找到.它包括许多其他序列化库.

Answer 2

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

Answer 3

您可能对此问题感兴趣:"Thrift与Protocol Buffers的最大差异？"

Answer 4

我测试了PB的性能,包括其他数据格式(xml,json,默认对象序列化,粗麻布,一个专有)以及用于数据绑定任务(读写)的库(jaxb,快速信息集,手写),但是没有包括节俭的格式.具有多个转换器(如xml)的格式的性能具有非常高的变化,从非常慢到非常快.作者的主张与感知表现之间的相关性相当弱.对于制造最大声称的包装尤其如此.

对于它的价值,我发现PB表现有点夸张(通常不是作者,而是其他只知道是谁写的).使用默认设置,它没有超过最快的文本xml替代品.使用优化模式(为什么这不是默认模式？),它速度更快,与最快的JSON包相比.Hessian相当快,文本json也.专有的二进制格式(这里没有名称,它是公司内部)是最慢的.Java对象序列化对于较大的消息来说很快,对于小对象来说则较少(即高操作率的固定操作).PB的消息大小是紧凑的,但是你需要做的所有权衡(数据不是自我描述的:如果丢失了模式,你会丢失数据;当然有索引和值类型,但是你有什么如果你愿意,可以反向工程回到字段名称,

我的观点是,(a)实施通常比规范(数据格式)更重要,(b)端到端,同类最佳(针对不同格式)之间的差异通常不足以决定选择.也就是说,你可能最好选择你最喜欢的格式+ API/lib /框架(或者有最好的工具支持),找到最佳实现,看看它是否足够快.如果(并且只有!)没有,请考虑下一个最佳选择.

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

Answer 5

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

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

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