10.3. Data Format Optimization

Data can be exchanged between a BlazeDS server and a Flex client in a number of formats, which include both binary and text-based forms. AMF3 facilitates a very efficient way of binary transmission of data between the server and the client. In addition, you can choose to go with a text-based format that could be well structured like XML or delimited like comma-separated or tab-delimited text. JSON (JavaScript Object Notation) and AMFX, where AMF is transmitted in XML, are also options.

In each of these cases, the following performance-related measures need to be considered:

• Data size—The volume or size of the data in a particular format

• Server execution time—The time the server takes to serve the data

• Transmission time—The time the data takes to traverse the wire from the server to the client

• Parsing time—The time the client-side program takes to parse the data so that it's available for consumption

• Rendering time—The time it takes to render the data in a UI component on the client side

Although accurately measuring the size and duration intervals in the preceding list is fraught with inefficiencies and challenges, these measures do provide an indication of the scale of differences among the various options. In this section, I will present a way to measure the data size and the execution, transmission, parsing, and rendering time intervals.

For starters, let's measure the execution time on the server. The execution time on the server is not only impacted by the format but also by the time it takes to generate the data and collect it.

One of the best unobtrusive ways of measuring the time it takes to generate a response is to set up a Servlet filter to do so. Such a Servlet filter could also measure the size of data that is generated. A Servlet filter that measures data traffic is available in the dsadapters project, which is accessible online at http://code.google.com/p/dsadapters/.

The core snippet of the doFilter method where the Servlet filter measures the data traffic size and execution time is as follows:

Calendar startTime = Calendar.getInstance();

    int contentLength;
    long execTime;

    try
    {
      ByteArrayResponseWrapper wrapper = new ByteArrayResponseWrapper(
        (HttpServletResponse) response);
      chain.doFilter(request, wrapper);
      contentLength = wrapper.getOutputAsByteArray().length;
      execTime = Calendar.getInstance().getTimeInMillis() - startTime.getTimeInMillis();
      response.getOutputStream().write(wrapper.getOutputAsByteArray());
    }
    catch (Exception e)
    {
      throw new ServletException(e);
    }
    finally
    {
    }

The two most important lines of code as far as the traffic measures go are sandwiched between the line where the chain.doFilter is called and the line where response.getOutputStream is called. Both these lines are in the try block of the preceding code snippet.

The filter uses a ByteArrayResponseWrapper class to wrap the response up as a byte array. The size of the data is measured simply by measuring the length of the byte array. The server execution time is simply the time elapsed between the point when the doFilter method starts executing to the point where it writes the response out to the output stream.

The transmission, parsing, and rendering time need to be captured at the client end. Transmission time can best be captured by adding an event listener for the acknowledge event of the mx.messaging.MessageAgent of the mx.messaging.ChannelSet in use. The time elapsed between the application's initialization and the invocation of the acknowledge event listener provides a measure of the transmission time. Parsing time can be assessed by measuring the time from transmission to the point when the result event handler of the RPC component is called. Rendering time can be measured from the time the result is available at the RPC component to when a UI component such as a DataGrid dispatches its updateComplete method.

You can choose to alter these measures and come up with your own set of metrics, but as you run these tests you will notice that a few results are consistently unambiguous, which are the following:

• Data transferred as binary AMF is consistently the smallest and the fastest among all the alternatives.

• The parsing time for AMF data is negligible, as the data is already available in AS3 form.

• XML parsing using E4X is often faster than hand-coded parsing for text formats like CSV or TSV.

• As the amount of data increases, the gap in size and time taken between the binary AMF and the text-based formats widens sharply, sometimes a magnitude of over 10 times in favor of AMF.

• Text formats are very sluggish in performance and often don't scale beyond 10,000 rows or so. Although one could debate why you would need to retrieve 10,000 rows at once, the metrics stand as mentioned.

Therefore, choose the data format appropriately and almost always favor the more efficient binary AMF unless there is a good reason to support an alternative format.

In the last few sections, you have learned about clustering, data compression, and data formats, and each of these enhances performance and increases scalability. In the section on clustering, the technique of connection failover and client load distribution was explored. Next, the benefits of asynchronous connections for scalable server-side pushing are explained.