Why GZip Doesn't Help Direct Proxy's Performance

For direct OSB proxies, passing XML content as GZip will not improve the end-to-end performance due to extra time required for gzipping and un-gzipping.

There is a service I have to deal with which is a constant headache.

The service returns a huge, 1Mbyte or more, XML with all kinds of information.

The web application that calls the service experiences a very noticeable delay, which affects the user experience. Web developers measured that the average delay time for them is about 500ms, and the delay grows proportionally to the response size.

The size is obviously the culprit, and I gotta do something about it!

GZip The Response! It Must Help!

Internet has solved the same problem long time ago. When the web page is big, server compresses the payload with gzip which often reduces the size by factor of 10.

Since SOAP runs on top of HTTP, the gzip solution is available to it as well. I just need to make OSB to pass-through the gzipped content without trying to decompress it. In fact, it does so by default, but it strips the “Content-Type: gzip” header. Missing header breaks the caller, but this is easy to fix though.

Here’s what I did:

• I made sure I do not touch the payload, even for logging, so OSB will not try to parse the gzipped stream

• I sent “Accept-Encoding: gzip” header to the backend service

• I passed all headers from the backend service back to the caller(**)

Since the backend service supports gzip, it should serve me the gzipped content now. And it did!

Yay! The response size was 50 times smaller than original. I was expecting at least 10 times improvement in the call time.

And… Nothing

The performance test indeed has shown an improvement … of about 1%. Huh?

Looking Outside Of OSB Box

Now it was obvious my mental model of where the time is spent was wrong.

I painstakingly measured all the steps the calling application and the backend had to do to communicate. They did quite a lot of work outside of simple sending the data!

Sender had to build DOM of the message first, then serialize it into XML string, and only then write it into the wire.

Receiver had to parse the XML string into DOM.

When GZip was used, sender had to compress the XML string before sending it, and the recipient had to decompress it before parsing.

Here’s how the request/response cycle looked before implementing GZip:

Note that largest time hog is not the network, but building, serializing and parsing XML! Using gzip does not affect these steps, and so has little effect on the overall delay:

Gzip indeed cut the transfer time some 6 times, but the backend had to spend some time to compress the payload, and the caller had to spent a bit more time to decompress it, which killed almost all the savings.

The most troublemaking steps though - XML processing - left unaffected.

Conclusion

The size was indeed the root cause, but its effect was outside of OSB. The optimization efforts should have been focused on making the data size smaller.