Enabling gzip compression for data services

Brian Deitte on the Flex team wrote up a quick set of classes that can be used to compress your network traffic for all 3 data services (RemoteObject using AMF, HTTPService, and WebService). Dan Schaffer on the QA team then did a number of performance tests to see what kind of improvements we could get. I’ve been given permission to re-post his results here. This is strictly for experimentation, it is not officially supported in any way.

You can download the source (includes a README for setup which you should read since it has more info than Dan’s report) here. Dan’s report follows:


Brian wrote a 3 classes to gzip compress the output of flex data services. Configuration is just a matter of adding a filter in web.xml. The player will detect the the header will accept gzip encoding then uncompress the content type. A minimum size may be set in the configuration so only data greaterthan the minimum is compressed. The implementation is really nice because the code is really independent of the Flex source code so it can easily work with any versions of Flex.

Based on a small study I would only recommend compressing the data service streams when the bottleneck is the network bandwith or very large datasets are common. Also under load even on a high performance server the additional cpu cycles required to compress the data stream may slow down the response time. Also the data must be compressible (ie text). I think most data will contain much repitition and be highly compressed with the gzip algorithm.

- Setup is Easy
compile the 3 classes and copy into WEB-INF/classes of the flex app and add to web.xml:
<filter>
<filter-name>GZIPFilter</filter-name>
<filter-class>filter.GZIPFilter</filter-class>
<init-param>
<param-name>debug</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>minimumSize</param-name>
<param-value>0</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>GZIPFilter</filter-name>
<servlet-name>AMFGatewayServlet</servlet-name>
</filter-mapping>
<filter-mapping>
<filter-name>GZIPFilter</filter-name>
<servlet-name>FlexProxyServlet</servlet-name>
</filter-mapping>

- Performance
Encoding a data stream is very cpu intensive. Only when using a fairly beefy server and sending more than 100k of data at once produced performance improvements. A slow server and small packet sizes produced slower round trip time than using an uncompressed stream. In cases smaller than 100k especially <50k the performance is worse with gzip compressing enabled.

I wrote a small app to send data via RemoteObject, HTTPService, and WebService data calls from the server to the flash player. The app sends the small xml files for each cases in 10k, 25k, 50k, 100k, 250k, and 500k. I ran a single client 12 times for each data service and size then removed the highest and lowest, averaging the remaining. On my laptop the gzip compression was always slower. Once I moved the webapp to flexload (a decent multi-processor server) only after 100k was the performance better with gzip compression enabled.

FLEXLOAD4 (time in MS)
10k 25k 50k 100k 250k 500k
Remote Object-gzip 138 150 150 167 324 1442
Remote Object 89 124 136 221 613 1407

Web Service-gzip 177 143 166 194 523 1600
Web Service 108 124 177 299 732 1846

HTTP Service-gzip 155 161 182 178 269 454
HTTP Service 88 107 151 239 466 905

T30 LAPTOP
(time in MS)
10k 25k 50k 100k 250k 500k
Remote Object-gzip 137 160 173 207 642 3294
Remote Object 103 102 129 153 554 2298

Web Service-gzip 240 267 240 271 871 3766
Web Service 110 142 158 213 788 3604

HTTP Service-gzip 140 149 149 209 267 352
HTTP Service 100 105 129 161 244 392

The data was very compressed:
uncompressed compressed
10k 1k
25k 2k
50k 2k
100k 3k
250k 7k
500k 13k