AMF3 and zlib compression
Posted by cornel | Filed under Flex, Java
Yesterday I was reading the Exadel documentation and in the chapter describing AMF format I’ve read the following things: “AMF objects are of a very small volume due to the fact that they are compressed using zlib”. I sent them an email regarding that and explaining that the DEFLATE algorithm is not used in AMF serialization, so there is no zlib connection). They told me that they took the information from web, and I see what the mean – if you will search for “AMF objects are compressed using zlib” you will find a lot of references.
Peter Farland (lead engineer for the SDK team) has already posted several comments on blogs and on the Zend Framework wiki regarding that and I will write it again here: there is no connection between the zlib algorithm and AMF format. Yes the serialization uses some kind of compression (for instance writing references for identical strings) but not zlib.
However the developer is free to compress all HTTP responses using zlib (when supported) so the serialized AMF data will be compressed also. Or you can choose to apply DEFLATE only on some data (like big strings) – you can read here my post related to that.
January 20th, 2009 at 5:02 pm
Wow, interesting… I had just been reading up on AMF serialization/deserialization… http://www.onflex.org/ted/2007/11/abcs-of-amf.php
Ted talks about the zlib compression a lot in this post.
January 20th, 2009 at 5:05 pm
Ahh just re-read all the comments on the aforementioned post, and sure enough, Pete is on there correcting Ted. I think that Ted may be responsible for the zlib rumor. It’s a strong one… thanks a ton for dispelling the myth!
March 13th, 2009 at 8:09 pm
Hello Cornel,
I am thinking about using Flex + BlazeDS with one of my new projects instead of just plain old HTTPService talking directly to a http server. One of the reasons for that was that I have a lot of big xml/text content to transfer from server to client and I figured the AMF format would have some compression built in. (I was using a makeshift gzip compression in earlier projects)
Now after reading your post I did some testing. I made a 1MB text file and put it on a remote location. Using HTTPFox I monitored the transferred size both up and down. The result was that pretty much the whole mega byte got downloaded to my client with hardly any compression noticeable. Using gzip I normally achieve a compression down to 5-10% of the original size.
As a summary I have to say within the limited scope of my tests, additional gzip compression is absolutely required if bandwidth is a factor in your environment imho.
Do you know if I can tell blaze put compression on a channel or something like that? In the past I have used a filter in web.xml to compress all response data.
GzG
Franz
March 14th, 2009 at 1:10 am
Hi Franz,
Please read also
http://cornelcreanga.com/2009/02/remoting-xml-amf-hessian-and-deflate-algorithm/
http://cornelcreanga.com/2008/07/actionscript-compressing-strings/
AMF will minimize the amount of data by writing on fewer bytes the small integers and by writing references for the duplicate objects (string or not), but because is not compressing strings it will not help you at all in your case (as you have also noticed). AMF and Hessian are optimized for graph of objects, not for sending a large string – in this case I agree that deflate/zip is the best solution.
Can’t you change the server and work directly with a graph of objects? I believe it will improve also your productivity. If not probably httpservice with gzip and with some cache mechanism would be the best solution
I’m not aware about compressing all the data send through a channel – but anyway you can use the apache (http://httpd.apache.org/docs/2.0/mod/mod_deflate.html) or you can set a parameter in tomcat (compression=”on” ), it should work for the http requests.