I get the opportunity to talk with many customers developing and deploying Web services. There are a ton of cool things going on in real production scenarios that continue to amaze me. But, invariably, the topic of XML and it's sheer size work their way into the conversation. As you probably know, XML's strength (self-describing data) is also it's Achilles heel of sorts (i.e XML messages are big and bulky). But, the advantages of two dissimilar apps talking over the wire via HTTP far outweigh the drawbacks of fat traffic.

So, the discussion turns to HOW a company can deal with this challenge. A good solution is compression. It can make a huge difference. Here's some interesting data from the XML-Dev list where a developer ran a quick test to see how “compressible“ XML is...

From developer Steve DeRose on XML-Dev list:
"I created a file with the numbers from one to a million, delimited in different ways. zero.dat has just a linefeed between numbers; comma.dat just has a comma and a linefeed; tag01 has a start and end-tag with the one-character element type "d" (and the linefeed); tag02 has element type "da", on up to tag20 which has a 20-character-long element type. 5-line Ruby program available on
request."
 
The linefeed-only file reduces to 2130082 / 6888888 = 31% of its original size
the 20-char tagged file reduces to 2596261 / 51888843  = 5% of its
original size

And even though the 20-char tagged file was over 7.5 times bigger than the linefeed-only file when uncompressed, once they're compressed it is only about 1.2 times bigger -- a mere 22% increase despite every number having 2 tags with 20-character tag names, instead of nothing but a line break.“

With our BIG-IP v9 product, we've introduced compression that effectively shrinks traffic to increase performance AND selectively adapt to endpoint needs. Pretty cool.

If you're deploying Web services and you want to increase performance from endpoint to endpoint, you might want to check it out.