This content has been marked as final. Show 3 replies
Sorry for the slow reply -- I wanted to take some time to try this out rather than give an incomplete response.
It's not built into AIR, but if you're using Flex/ActionScript for your application you can use a gzip library to decompress a gzipped SOAP response (or any other gzipped response from a server -- it doesn't have to be SOAP). Danny Patterson gives an example of how to do that here:
I've been prototyping a way to make a subclass of the Flex WebService class that has this built in, so if I can get that working it would be as easy as using the Flex WebService component.
I did some tests of this technique, just to see for myself if the bandwidth savings is worth the additional processing overhead of decompressing the gzip data. (The good news is that the decompression part is built into AIR -- just not the specific gzip format -- so the most processor-intensive part of the gzip decompression happens in native code.)
Here is what I found:
I tested this using the http://validator.nu/ HTML validator web service to validate the HTML source of http://www.google.com/. This isn't a SOAP web service, but it does deliver an XML response that's fairly large, so it's similar to SOAP.
The size of the payload (the actual HTTP response body) was 5321 bytes compressed, 45487 bytes uncompressed. I ran ten trials of each variant. All of this was done in my home, where I have a max 6Mbit DSL connection. In the uncompressed case I measured the time starting immediately after sending the HTTP request and ending as soon as the response was received. In the compressed case I started the time immediately after sending the HTTP request and ended it after receiving the response, decompressing it and assigning the compressed content to a ByteArray (so the compressed case times include decompression, not just download). The average times for ten trials were:
Uncompressed (text) response: 1878.6 ms
Compressed (gzip) response: 983.1
Obviously these will vary a lot depending on the payload size, the structure of the compressed data, the speed of the network, the speed of the computer, etc. But in this particular case there's obviously a benefit to using gzipped data.
I'll probably write up the test I ran, including the source, and post it on my blog. I'll post another reply here once I've done that.
Thanks for the reply Paul. Much appreciated.
HTTP GZIP compression is really a big gap in the functionality of AIR however.
It's just essential - it's really not practical to build apps that rely on web services/SOAP without over the wire GZIP compression.
It's really something that should be built into the platform, not something we should have to deal with in the application.