Is GZip compression worthwhile with AMF

Question

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?

Ascribe

Maybe this is a ridiculous question - are you leveraging options exposed by your servlet container (ie, tomcat) to turn on compression? Or are you using a custom request filter to do this? I've seen code floating around that suggests rolling your own filter, but I don't see why you can't simply enable compression on the tomcat connector. thanks! – Traffic

Answer 1

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.

Appendage

On which size does the performance penalty of compression/decompression outweigh the reduced network traffic? – Tharp

@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). – Appendage

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. – Hithermost

Answer 2

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.

Waylonwayman

Answer 3

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.

Liquorice