views:

83

answers:

3

We've got a Flex/Java application using BlazeDS and we're investigating reducing the size of the payloads being passed between our server and the client.

Since AMF is a binary format and supposed to be fairly compact, is there any benefit to turning on GZip compression? Has anyone else done this before and did you see any significant gains from using compression?

UPDATE

I just performed a simple test to determine what kind of compression ratios we might expect if we were to enable gzipping. I just captured the AMF payloads in some files and just gzipped them using the Linux command line version. I didn't specify the level of compression, just the default i.e. 'normal'. It appears that on average there is a 9% reduction in the payload size, with some payloads getting as much as 61%. Can anyone see a flaw in this method and what level of compression can be used in HTTP gzipping?

+3  A: 

It depends on the data. If you have lots of highly structured data, then typically it uses only a fraction of the bits of actual information. Then compression will make sense.

e.g. a record with a category field which is one of 6 possibilities might take 32-bit if it is encoded as a GUID, but you can represent it with 3 bits. Compression will see these patterns as very frequent and reduce them.

Similar for non repeating strings.

AMF has some optimizations for small integers and repeating strings, but not really compression. See this discusion.

Do some benchmarks and decide.

Peter Tillemans
+5  A: 

We have recently switched some client-server communication from SOAP to AMF, and we also compared impact of compression. We focused on one particular service which returns some big responses. These were our results, returning the same data (serialized with xfire+aegis for SOAP, and BlazeDS for AMF):

  • SOAP: uncompressed: 1000KB gzipped: 100KB (90% reduced)
  • AMF: uncompressed: 200KB gzipped: 30KB (85% reduced)

Our conclusion is gzipping is definitely worth it. The binary AMF can be compressed almost as good as XML (SOAP). Of course your mileage may vary depending on the kind of data you are returning.

Wouter Coekaerts
On which size does the performance penalty of compression/decompression outweigh the reduced network traffic?
splash
@splash: I don't think it depends on the size. For bigger requests, the disadvantage (more CPU time) and the advantage (smaller reponses) scale together. It does depend on how much CPU and bandwidth your server and clients have to *spare* (so it depends on how much you have available, and how CPU and bandwidth-intensive the application is).
Wouter Coekaerts
It would also be helpful to read the AMF spec in order to understand where it works and where not. For example the strings are not compressed at all in AMF, on the other hand if you have a bunch of integers you will not see a significant improvement.
Cornel Creanga
+1  A: 

You can experiment with how turning GZIP on and off changes transfer sizes using my Census RIA Benchmark. But as others have pointed out the results depend heavily on the data. So doing your own tests with your own data is the best way to decide.

Also keep in mind that there is overhead on both sides to GZIP so sometimes that overhead is worth it (slower connections) and sometimes it's not.

James Ward