Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Kryo serialization library: is it used in production?

Kryo is a very new and interesting Java serialization library, and one of the fastest in the thrift-protobuf benchmark. If you've used Kryo, has it already reached enough maturity to try it out in production code?

Update (10/27/2010): We're using Kryo, though not yet in production. See my answer below for details.

Update (3/9/2011): Updating to the latest Jackson and Kryo libraries shows that Jackson's binary Smile serialization is pretty competitive.

like image 584
Jim Ferrans Avatar asked Apr 27 '10 21:04

Jim Ferrans


People also ask

What is Kryo serialization?

Kryo is a fast and efficient binary object graph serialization framework for Java. The goals of the project are high speed, low size, and an easy to use API. The project is useful any time objects need to be persisted, whether to a file, database, or over the network.

Why is serialization faster than KRYO serialization?

Kryo is significantly faster and more compact than Java serialization (often as much as 10x), but does not support all Serializable types and requires you to register the classes you'll use in the program in advance for best performance. So it is not used by default because: Not every java. io.


1 Answers

I'll try to answer my own question (Kyro is still very new!).

We have a set of about 120 different web services implemented using the Restlet framework. These are consumed by web service clients generally built on top of a Restlet-based client library. The representations sent back and forth between server and client include XML (using the XStream serialization library), JSON (Using Jackson), XHTML, Java Object Serialization, and as of yesterday, Kryo. So we're in a position to do some solid side-by-side comparisons.

Kryo 1.0.1 seems reasonably stable. Once I actually read up on how to use the API, the only real problem I found was that the default java.util.Date serializer seemed to warp dates a few months into the past. I just had to provide my own override:

kryo.register(Date.class,    new SimpleSerializer<Date>() {    @Override public void write (ByteBuffer b, Date d) { b.putLong(d.getTime()); }    @Override public Date read (ByteBuffer b) { return new Date(b.getLong()); }   }); 

But that was the only possible issue I've found so far. We have a set of JavaBeans that have String, Float, Integer, Long, Date, Boolean and List fields.

Here are some rough benchmarks. First, I did 100,000 serializations and deserializations of an object hierarchy that describes one TV program (ie, made 100,000 deep copies of it). The speeds were:

XStream XML:                 360/sec Java Object Serialization: 1,570/sec Jackson JSON:              5,000/sec Kryo:                      8,100/sec 

Next, I also serialized a catalog of 2,000 TV program descriptions and counted bytes:

XStream XML:         6,837,851 bytes Jackson JSON:        3,656,654 bytes Kryo:                1,124,048 bytes 

I also found that registering serializers was very important:

kryo.register(List.class); kryo.register(ArrayList.class); // ... kryo.register(Program.class); kryo.register(Catalog.class); // ... 

If I didn't do that, the serializations were almost double the size, and the speed was maybe 40% slower.

We also ran complete end-to-end tests of several web services using each of these four serialization methods, and they also showed that Kryo was running faster than the others.

So in summary, Kryo seems reasonably robust. I'm going to keep support for it in our code base and as we gain experience with it I hope to use it in more places. Kudos to the Kryo team!

Update (3/9/2011): I finally got around to @StaxMan's suggestion to try Jackson 1.6's binary "Smile" serializer. Using Jackson 1.6 and Kryo 1.04, I did 100,000 deep copies (serialization/deserialiations) of a somewhat different TV program object hierarchy:

XStream XML:     429/sec    5,189 bytes Jackson JSON:  4,474/sec    2,657 bytes Kryo:          4,539/sec    1,066 bytes   Jackson Smile: 5,040/sec    1,689 bytes 

This test didn't mesh with a macro-level test, where I tried different serializers in a REST web service that delivers many of these objects. There the overall system throughput supports @StaxMan's intuition about performance:

Jackson JSON:     92 requests/sec Jackson Smile     97 requests/sec Kryo:            108 requests/sec 
like image 186
Jim Ferrans Avatar answered Sep 21 '22 08:09

Jim Ferrans