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.
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.
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:
|Building Request Data Object||6ms||6ms|
|Parsing request into Data Object||1ms||5ms|
|Bulding response Data Object||48ms||82ms|
|Sending response via OSB||30ms||31ms|
|Parsing response into Data Object||92ms||166ms|
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.
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. Email me at email@example.com