January 14, 2014

And Why JSON Does Help Direct Proxy Performance

For direct OSB proxies, passing JSON content instead of XML will improve the overall end-to-end performance due to much smaller serialization and deserialization overhead.

See other posts about OSB & JSON:
How To Build a JSON Pass-Through Proxy in OSB
OSB and JSON Proxies: Gathering Statistics
JSON Proxies: Inspecting & Modifying The Payload

In my previous post I attempted (and failed) to improve the performance of a service with a large response by gzipping its payload.

I failed, and the problem thus remains. What can I do about it?

Get Rid Of XML

XML itself is the root cause.

Despite the OSB proxy I’m using is direct, i.e. it doesn’t do the XML parsing, the backend service must build the response DOM and then serialize it into the on-the-wire format. The calling client then must parse the incoming XML.

Serialization of XML is notoriously slow. Parsing of XML is even slower: a parser must take into account a lot of nuances of XML standard such as namespaces, entities, processing instructions and so on, and so forth.

I cannot expect significant improvements while keeping using XML.

Enters JSON (And Also ProtoBuf, And Thrift, And Many More)

If not XML than what? What data format may compare in its flexibility with XML while at the same time have smaller overhead?

There are plenty. The most common nowadays is JSON, but if you’re really into exploring the boundaries of possible, Google Protocol Buffers, Apache Thrift and some others may offer more opportunities for tuning.

I though went with JSON for my pilot project: JSON was immediately supported by both calling and called systems, and is easy to debug.

Changes Made


Comparing to GZip, the direct proxy requires less changes. All I had to do is to pass through the Content-type header there and back to make sure the backend receives its value as “application/json” and responds with the same data format.

Win: 2 Times Faster

The round-trip time for JSON request and response was about 2x smaller than for XML.

As before, the exchange has a 2K request and a 1M response. Both XML and JSON carry the same data. Overall sizes for XMLa and JSON are very close, despite XML having a larger syntax overhead; this is because most of the payload is data (strings).

Let’s see how the time was spent this time:

Caller In-Flight+OSB Backend JSON XML
Building Request Data Object 6ms 6ms
Serializing Request 2ms 15ms
Sending request 5ms 5ms
Parsing request into Data Object 1ms 5ms
Querying database 54ms 55ms
Bulding response Data Object 48ms 82ms
Serializing response 94ms 237ms
Sending response via OSB 30ms 31ms
Parsing response into Data Object 92ms 166ms
**TOTAL** **332ms** **602ms**

As you can see, JSON beats XML every time one needs to transform data to and from on-the-wire format. Even building the JSON-backing data structure - JSONObject, which is the analogue to XML DOM - is faster.


Using JSON for large payloads may significantly reduce the round-trip time for a client.

Downside is that OSB cannot transform such a payload.

Vladimir Dyuzhev, author of GenericParallel

About Me

My name is Vladimir Dyuzhev, and I'm the author of GenericParallel, an OSB proxy service for making parallel calls effortlessly and MockMotor, a powerful mock service.

I'm building SOA enterprise systems for clients large and small for almost 20 years. Most of that time I've been working with BEA (later Oracle) Weblogic platform, including OSB and other SOA systems.

Feel free to contact me if you have a SOA project to design and implement. See my profile on LinkedIn.

I live in Toronto, Ontario, Canada.  canada   Email me at info@genericparallel.com