Performance comparison

This section will give you an idea how the discussed methods compare to each other in terms of performance. To visually compare the three different methods, we employed three charts which you can see below. The first chart (see Figure 4) compares the three methods against each other with the web, HTTP, and AMF services hosted locally, where bandwidth is not an issue. HTTP services hold their own against Remoting, while the high overhead of each Web service call clearly makes them the also-ran here.

Figure 4. A time-per-call comparison of the three communication methods when hosted locally

In the second chart (see Figure 5), the bandwidth is being throttled artificially at 512 KB/s using the Charles Web Debugging Proxy to emulate services being consumed over a typical Internet connection. In this more realistic scenario, all three methods slow down, but HTTP services take the biggest hit, coming closer to the performance of web services than Remoting. This is due to the inefficient XML format of HTTP services, which makes an impact on speeds when bandwidth is taken into account. Still, web services remain the slowest, with Remoting leading the pack.

Figure 5. Another speed comparison, but with bandwidth throttled to a realistic 512 Kbits/s

The third chart (see Figure 6) compares the packet size depending on the number of students included in the ClassData object. As was mentioned before, due to AMF being a binary format the packets it sends are consistently smaller than both HTTP and web services by about a factor of ten.

Figure 6. A comparison of the packet sizes sent by each method

As you can see, the slightly more complicated setup of AMF is amply compensated with its excellent performance and bandwidth efficiency. A tenfold packet size difference together with its very short call times leaves HTTP and web services behind. If we take into account other factors such as mileage, type of data that is being sent, and HTTP compression, the relative performance of the discussed methods can change.

Conclusion

This article familiarized you with the three most popular HTTP request/response mechanisms used for communicating between Flex and .NET: HTTP services, web services, and Remoting.

HTTP services, while providing relatively good performance on small data amounts, require manual parsing of XML messages on both client and server sides, making them less programmer-friendly. The SOAP protocol used by web services adds the convenience of strongly typed objects, while unfortunately making it the heaviest and slowest, which becomes distinguishable even on fairly small data sizes. Remoting using Fluorine is the only mechanism of the bunch based on a binary protocol. Its efficiency is quite noticeable: on big data sets, data packets can be as much as ten times smaller than those of its non-binary rivals. With its compactness comes higher speed.

The decision as to which method to use is often dictated by what kind of service you have available. Given the vast popularity of web services, it is likely that you may have to use them for communication in your application. Still, in situations when you are not tied to an existing service, Remoting with Fluorine is our recommended communication method. While it performs as well on small data sets as the others, its ability to adapt to heavy data loads makes it excellent for performance-critical applications involving intensive information transfer.

Where to go from here

You have learned about the three most popular methods used for Flex to .NET communication: HTTP services, web services, and Remoting. By now, you should have a clear understanding of how to use each one of them and how they perform when compared to each other.

Page 7 of 7

Previous Page