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:

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.

Conclusion

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

Downside is that OSB cannot transform such a payload.