Richard Monson-Haefel blogged about the advantages and disadvantages of AMF versus JSON versus XML on InsideRIA.
Also I agree with some of his points, IHMO he also misses some important ones.
Batching is an important pattern, but the point is that the current implementations using AMF(BlazeDS) are simply Remote Procedure calls over HTTP POST.
As I said before the consequence is that BlazeDS, does not play very well with the HTTP caching infrastructure.
In short the POST's are never cached.
I just cannot see how automatic batching of RPC calls can be easily implemented. Restful API's based on JSON or XML can more easily support automatic batching and even could potentially (not sure whether the limitations of the Flex HTTPService would allow this) make use of http pipelining. Restful API's could also better use HTTP's caching features as well as lead to more scalable implementations on the server side, because to much state would be avoided there.
I agree, and would add "in practice" and "for most use cases".
I think that some benchmarks are a bit misleading. Who would really want to load that much data in one request to the client, if the client typically cannot show all the data? What you want to do is to use some kind of paging or on demand loading support, because most users in typical applications are not going to look at all the data anyway.
I bet that then the differences between the formats will become minor and probably negligible as soon as you use paging or a similar mechanism.
The reference to another performance analysis that Richard provides seems to go in this direction as well.
So at the end I would rather agree with one of the commenters on Richard's blog
There is one other requirement that you need to take into account and that is security.
Using Webservice Remoting with authentication doesn't seem to work very well at the moment with Flex.
Therefore If you are going to use HTTP's authentication mechanism, you currently have to use BlazeDS (or the like) or use HTTPService and parse the XML manually.
Also I agree with some of his points, IHMO he also misses some important ones.
For example, there is the "batch" pattern which says that it is sometimes cheaper to batch many I/O operation than to do them individually. But again using that pattern requires planning and a specific context to make it effective.
Batching is an important pattern, but the point is that the current implementations using AMF(BlazeDS) are simply Remote Procedure calls over HTTP POST.
As I said before the consequence is that BlazeDS, does not play very well with the HTTP caching infrastructure.
In short the POST's are never cached.
I just cannot see how automatic batching of RPC calls can be easily implemented. Restful API's based on JSON or XML can more easily support automatic batching and even could potentially (not sure whether the limitations of the Flex HTTPService would allow this) make use of http pipelining. Restful API's could also better use HTTP's caching features as well as lead to more scalable implementations on the server side, because to much state would be avoided there.
The truth is that performance differences between JSON and AMF are not that wide.
I agree, and would add "in practice" and "for most use cases".
I think that some benchmarks are a bit misleading. Who would really want to load that much data in one request to the client, if the client typically cannot show all the data? What you want to do is to use some kind of paging or on demand loading support, because most users in typical applications are not going to look at all the data anyway.
I bet that then the differences between the formats will become minor and probably negligible as soon as you use paging or a similar mechanism.
The reference to another performance analysis that Richard provides seems to go in this direction as well.
So at the end I would rather agree with one of the commenters on Richard's blog
Yeah, having a JSON implementation natively in Flash would be great.
There is one other requirement that you need to take into account and that is security.
Using Webservice Remoting with authentication doesn't seem to work very well at the moment with Flex.
Therefore If you are going to use HTTP's authentication mechanism, you currently have to use BlazeDS (or the like) or use HTTPService and parse the XML manually.
4 comments:
Hi,
Sorry you felt my Census benchmark is misleading. That certainly isn't my intention. Every time I use Census in a demo I clearly state that the benchmark is about loading large amounts of data. Some people need to do that, some don't. I frequently work with enterprises that do have reasons they need to load large data sets up-front.
-James
Hi James,
Thanks for your comment.
It was not my intention to express that your benchmark does not have any value.
I think it shows pretty well that there are different costs for large amounts of data to be send, and also what kind of costs there are (parsing, amount of data send).
Nevertheless in most (business) applications I've seen so far, I believe people should have been thinking about paging (or a similar technique) from the beginning.
With paging the differences somehow become minor an the client side (also there still might be less load on the server for AMF) and also are almost independent on the size of the list.
Your tests also shows that LCDS paging is pretty fast and the performance is probably independent of the the number of entries in the list.
Regards,
Markus
Do you know how JSON and AMF compare in terms of size of data transfer alone? I feel this is very important in data-heavy apps. I would assume that AMF being binary is much leaner than JSON?
Actually JSON and AMF are pretty on par in terms of data size, plus as your favourite server / data-gateway can throw GZIP encoding on them they because more or less equal, AMF winning by just a little amount.
Uncompressed sizes varied by 3% for me (amf being th smaller) , gziped by less than 1%.
Post a Comment