Using JSON in a low latency environment

Overview

In this post I am including the performance of our JSON parser.  Given a choice I suggest YAML for a host of reasons, however if you have to use JSON, how does the performance compare?

The message

The message is simple and contains a number of data typoes.
"price":1234,"longInt":1234567890,"smallInt":123,"flag":true,
"text":"Hello World!","side":"Sell" 
The actual message doesn't have a new line in it

The performance

This is the time to write and then read the message.

These timings are in micro-seconds (0.001 milli-seconds)


Wire Format
Bytes
99.9 %tile
99.99 %tile
99.999 %tile
worst
JSONWire
100*
3.11
5.56
10.6
36.9
Jackson
100
4.95
8.3
1,400
1,500
Jackson + C-Bytes
100*
2.87
10.1
1,300
1,400
BSON
96
19.8
1,430 
1,400
1,600
BSON + C-Bytes
96*
7.47
15.1
1,400
11,600
BOON Json
100
20.7
32.5
11,000
69,000

"C-Bytes" means using Chronicle Bytes to provide a recycled buffer.

"*" means this data was written to/read from direct memory wouldnt' need additional copying to use with NIO.

The code is the same as in this post and this post, the only difference is the use of JSONWire.

Conclusion

JSONWire may be a very good choice for performance, especially where consistent low latency through ultra low garbage production is required.

Related Links

What does the code for Chronicle Wire to generate JSON and YAML look like?
Why use YAML instead of JSON over the network?



Comments

  1. Rüdiger Möller16 August 2015 at 22:50

    Looks interesting :). I might want to try to use C-Wire as an additional codec for fst serialization. Currently i can use binary, unsafe-binary and json (using jackson for raw parsing). As in this use case databinding is provided by fst serialization it would require a low level parser API (not jsonobject).

    Peeking at the jackson benchmark it might not be fair, as far i can see the bench allocates a bytearrayoutputstream and then allocates+copies the byte array again using .toByteArray() for each benchmark run. In practice one would reuse an existing ByteArrayStream, also subclass it in order to provide public access to the underlying byte array without the need to alloc+copy again ^^.

    ReplyDelete
    Replies
    1. Peter Lawrey17 August 2015 at 07:49

      Using a recycled buffer really helped the BSON parser/generator but produced mixed results for Jackson.

      Delete
    2. Rüdiger Möller19 August 2015 at 16:14

      it should improve latency profile at least. afair bson requires "backwriting" of object length (length field is first but can be computed only after the object has been written), so its quite a cache missy format...

      Delete
  2. Unknown17 August 2015 at 19:58

    Regarding Jackson: I don't know if tests uses databind or streaming; but if databind, there is method `writeValueAsBytes()` which should be quite efficient. The only thing it can not reuse is the exactly sized output buffer, but other internal things are reused.

    ReplyDelete
    Replies
    1. Peter Lawrey18 August 2015 at 05:45

      In the "Jackson with C-Bytes" test I used a recycled buffer. The assumption is that you need to transfer data to/from native memory to interact with TCP or Files and this test does so.

      Delete
    2. Unknown15 December 2015 at 00:45

      One other thing that would be interesting would be to know whether tp99.999 was mostly/only due to GC (except for JSONWire that remained unaffected), or something else. From numbers I would venture a guess it was simply due to young gen collections, but it'd be nice to know for sure.

      Delete
  3. Gray14 September 2015 at 03:49

    Hey Peter. Thanks for this. I can't find JSONWire using a Google search. Is that a Chronicle package? Can you link to all of the packages used? Also I'm a confused about the 99.9... numbers. Does that mean that, for example, JSONWire's worse 99.9% is an average of 3.11microseconds? A bit more description of the values and maybe a sentence more in the conclusion would improve the piece. For example, Jackson's JSON seems to be better at 3 9s. Certainly the worst is a lot worse but I'm not sure otherwise of the ramifications. Thanks.

    ReplyDelete

Post a Comment

Popular posts from this blog

Java is Very Fast, If You Don’t Create Many Objects

Image
  You still have to watch how many objects you create. This article looks at a benchmark passing events over TCP/IP at 4 billion events per minute using the net.openhft.chronicle.wire.channel package in Chronicle Wire and why we still avoid object allocations..  One of the key optimisations is creating almost no garbage. Allocation is a very cheap operation and collection of very short-lived objects is also very cheap. Does this really make a difference? What difference does one small object per event (44 bytes) make to the performance in a throughput test where GC pauses are amortised? While allocation is as efficient as possible, it doesn’t avoid the memory pressure on the L1/L2 caches of your CPUs and when many cores are busy, they are contending for memory in the shared L3 cache.  Results Benchmark on a Ryzen 5950X with Ubuntu 22.10. JVM Vendor, Version No objects Throughput, Average Latency* One object per event Throughput, Average Latency* Azul Zulu 1.8.0_322 60.6 ...
Read more

System wide unique nanosecond timestamps

A Unique Identifier can be very useful for tracing. Those ids are even more useful when they contain a high-resolution timestamp.  Not only do they record the time of an event, but if unique can help trace events as they pass through the system. Such unique timestamps however can be expensive depending on how they are implemented.   This post explores a lightweight means of producing a unique, monotonically increasing system-wide nano-second resolution timestamp available in our open-source library. Uses for Unique Identifiers Unique identifiers can be useful to associate with a piece of information so that information can be referred to later unambiguously. This could be an event, a request, an order id, or a customer id. They can naturally be used as a primary key in a database or key/value store to retrieve that information later. One of the challenges of generating these identifiers is avoiding creating duplicates while not having an increasing cost.  You could ...
Read more

What does Chronicle Software do?

Image
Overview Chronicle Software is about simplifying fast data.  It is a suite of libraries to make it easier to write, monitor and tune data processing systems where performance and scalability are concerned. But its free, how do you make money, through support? We offer premium support . However, we often hear from users for the first time about a year after they have it in production.  Most users find they can support the software themselves.  It is only after a year or so, they have questions or concerns about where to take the product next.  In many cases, it is to a problem we have already solved and they just need to upgrade their software or use a new module we have added. As we don't know who is using most of our software, we can't advise them on how best to use our software and what updates or enhancements they would benefit from. We need users to contact us and ask questions.  We have a free forum , and we respond to 50% of questions in 2 hours...
Read more