序列化框架性能对比(kryo、hessian、java、protostuff)

简介:


 


优点


缺点


Kryo


速度快,序列化后体积小


跨语言支持较复杂


Hessian


默认支持跨语言


较慢


Protostuff


速度快,基于protobuf


需静态编译


Protostuff-Runtime


无需静态编译,但序列化前需预先传入schema


不支持无默认构造函数的类,反序列化时需用户自己初始化序列化后的对象,其只负责将该对象进行赋值


Java


使用方便,可序列化所有类


速度慢,占空间

     
     
     

测试环境:

硬件信息:

16 Intel(R) Xeon(R) CPU E5620 @2.40GHz

Red Hat Enterprise Linux Server release 5.4 (Tikanga)

java:  "1.6.0_27" Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06, mixed mode)

JVM options: java -Xmx256m –server

测试数据:(见附件)

ArrayList.class

MediaContent.class

Media.class

Image.class

测试方法:(参考自https://github.com/eishay/jvm-serializers

<!--[if !supportLists]-->1、  <!--[endif]-->在正式测试之前,将测试用例运行10次对JVM进行预热。

<!--[if !supportLists]-->2、  <!--[endif]-->对测试用例的每个方法,运行2000次,取平均值。

<!--[if !supportLists]-->3、  <!--[endif]-->每次测试用例运行500次,取最优结果

测试基准:

ser:           创建一个对象,并将其序列化成byte数组的时间

deser:       将byte数组反序列化成对象的时间

total:        创建一个对象,将其序列化成byte数组再反序列化为对象的总时间

size:          序列化后的数组大小

size+dfl:   序列化后用level6级别的zlib进行压缩后的大小

测试工具:


序列化工具


序列化方式


kryo


使用kryo默认的序列化方式fieldSerializer,

对需要序列化的对象采取默认的操作。开启reference,关闭register


protostuff


使用静态编译生成的Schema进行序列化


protostuff-runtime


使用protostuff-runtime框架生成Schema进行序列化

   

测试结果:

时间:

大小:

总结:

Kryo在类注册且reference关闭的情况下,序列化速度和大小明显 优于hessian和java,接近于protostuff。开启reference后将序列化速度将明显变慢,但仍旧优于hessian。

相关知识:

类注册:将需要序列化的类注册到kryo中,可以提高序列化与反序列化的速度。

Reference:开启这个选项后,相同的对象将被序列化为同一个byte[],默认关闭,如果要支持循环引用,则必须开启

稳定性测试:

测试用例(见附件)

循环引用:Cyclic.java


序列化方式


无默认构造函数


循环引用


对象为null


是否需要预先知道对象所属的类


大对象(4M)


Kryo


支持


需将reference选项打开


支持


不需要,关闭register


支持


Java


支持


支持


支持


不需要


支持


Protostuff


支持


支持


支持


不需要


支持


Protostuff

-runtime


不支持


支持


支持


需要


支持


Hessian


支持


支持


支持


不需要


支持

via http://x-rip.iteye.com/blog/1555293

时间: 2024-08-27 01:46:39

序列化框架性能对比(kryo、hessian、java、protostuff)的相关文章

[java]序列化框架性能对比(kryo、hessian、java、protostuff)

序列化框架性能对比(kryo.hessian.java.protostuff) 简介:   优点 缺点 Kryo 速度快,序列化后体积小 跨语言支持较复杂 Hessian 默认支持跨语言 较慢 Protostuff 速度快,基于protobuf 需静态编译 Protostuff-Runtime 无需静态编译,但序列化前需预先传入schema 不支持无默认构造函数的类,反序列化时需用户自己初始化序列化后的对象,其只负责将该对象进行赋值 Java 使用方便,可序列化所有类 速度慢,占空间      

Java序列化框架性能比较

博客: http://colobu.com jvm-serializers提供了一个很好的比较各种Java序列化的的测试套件. 它罗列了各种序列化框架, 可以自动生成测试报告. 我在AWS c3.xlarge机器上进行了测试,一下是测试报告与解析. 关键的测试数据的统计代码如下: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 public double runWithTimeMeasurement(

几种流行Webservice框架性能对比

1摘要 开发webservice应用程序中离不开框架的支持,当open-open网站列举的就有很多种,这对于开发者如何选择带来一定的疑惑.性能Webservice的关键要素,不同的框架性能上存在较大差异,而当前在官方网站.网络资料中可以方便的找到各自框架的介绍,但是很少有针对不同框架性能测试数据.本文选择了比较流行几个框架: Apache Axis1.Apache Axis2.Codehaus XFire.Apache CXF.Apache Wink.Jboss  RESTEasy.sun JA

前端框架性能对比

运行性能对比: JSP+Servlet > Struts1 > SpringMvc > Struts2+freemarker >> Struts2+OGNL+值栈 但是开发效率上正好相反,要特别注意,SpringMvc和Struts2不相上下

自己动手ab测了个ThinkPHP与CodeIgniter框架性能对比

PHP环境:Apache 2.4.10 + PHP 5.4.36 同样php输出代码 echo 'Hello Qzzm!'; 以下列出分别测试结果 一.CodeIgniter 2.2 This is ApacheBench, Version 2.3 <$Revision: 1604373 $>Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/Licensed to The Apache Softwar

Mego(1) - NET中主流ORM框架性能对比

从刚刚开始接触ORM到现在已有超过八年时间,用过了不少ORM框架也了解了不少ORM框架,看过N种关于ORM框架的相关资料与评论,各种言论让人很难选择.在ORM的众多问题中最突出的问题是关于性能方面的问题,因此我在看了国外的一遍文章(Dapper vs Entity Framework vs ADO.NET Performance Benchmarking)后受到启发,在这个文章的基础上扩展了测试用例分享给大家. 模型准备 数据初始化 测试用例说明 测试结果 结果分析 模型准备 用于测试是模型是基

高性能Java序列化框架Fse发布

目录 高性能Java序列化框架Fse发布 使用场景 使用说明 开源地址 高性能Java序列化框架Fse发布 使用场景 将Java对象序列化为二进制数据进行保存,以及二进制数据反向序列化为Java对象,在很多场景中都有应用.比如将对象序列化后离线存储至其他介质,或者存储于Redis这样的缓存之中. 目前常见的有几种框架可以支撑,比如 Hession ,Kryo,Protobuf,JDK原生等.有一些框架需要提前编写元数据配置文件以支撑跨语言序列化能力,比如 Protobuf .不过如果团队的技术栈

Java常用消息队列原理介绍及性能对比

消息队列使用场景 为什么会需要消息队列(MQ)? 解耦  在项目启动之初来预测将来项目会碰到什么需求,是极其困难的.消息系统在处理过程中间插入了一个隐含的.基于数据的接口层,两边的处理过程都要实现这一接口.这允许你独立的扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束. 冗余  有些情况下,处理数据的过程会失败.除非数据被持久化,否则将造成丢失.消息队列把数据进行持久化直到它们已经被完全处理,通过这一方式规避了数据丢失风险.许多消息队列所采用的"插入-获取-删除"范式中,在把一

Java MVC框架性能比较

- by zvane 现在各种MVC框架很多,各框架的优缺点网络上也有很多的参考文章,但介绍各框架性能方面差别的文章却不多,本人在项目开发中,感觉到采用了struts2框架的项目访问速度,明显不如原来采用了struts1框架的项目快,带着这些疑惑,我对各类MVC框架的做了一个简单的性能分析比较,其结果应该说是基本符合预期的,可供大家参考. 测试环境:CPU:酷睿2 T5750,内存:DDR2-667 2G,Web容器:Tomcat6.0,最大线程数设置为1000,操作系统:WinXP-sp3 测