Web servers will transport data more quickly if compression is enabled. The degree to which compression speeds up data transfer is
data-dependent; many instances of repeated patterns, such as zeros, are
necessary for compression to be effective. You can see an example of the benefits of data compression with James Ward's Census application; click on Navigator, then run some benchmarks with GZip enabled and disabled.
Because AIR, SWF and SWZ files are already compressed, there is no benefit to applying further compression to them.
Compression is MIME-type specific; the MIME types that should have compression applied must be explicitly configured. Data is compressed and decompressed transparently to the client and Flex data services, if used. The following information applies to data transferred as AMF, XML, plain text and HTML, and is equally applicable for all of today's popular web technologies.
If Tomcat serves the web content, then the Connector that manages the http protocol needs the following extra attributes set in server.xml:
- Set 'on'. You can specify a numeric value for unusually high compression, but the additional server load does not generally justify the benefits.
- Comma-delimited list of MIME types to compress. AMF data has the MIME type
- You can ignore this parameter for most applications
Here is a sample HTTP 1.1 connector definition:
For more information on Tomcat HTTP configuration, see The HTTP Connector
If Apache serves the web content, then an output filter needs to be defined in http.conf (the actual name of the appropriate configuration file varies by platform). In order to conserve the load on your server, you should only enable compression for specific MIME types. MIME types are specified as a space-delimited list. The following configures compression in the same manner as for the Tomcat example above:
AddOutputFilterByType DEFLATE text/html text/plain text/xml
For more information on Apache compression, see mod_deflate
When streaming messages using Flex data services, each message is pushed as an HTTP response chunk. Wikipedia has a writeup that suggests that one should not attempt to compress streaming data "HTTP servers sometimes use compression (gzip or deflate) to allow reducing time spent for transmission. Chunked transfer encoding can be used to delimit parts of the compressed object. In this case, it is worth noting that the chunks are not individually compressed. Instead, the complete payload is compressed and the output of the compression process is chunked using the scheme described in this article. In the case of compression, chunked encoding has the benefit that the compression can be performed on the fly while the data is delivered, as opposed to completing the compression process beforehand to determine the final size."
James Ward pointed out that there is a JDK bug patch from LinkedIn that enables Tomcat's GzipOutputFilter to send partial result when flushBuffer() is called.