In my previous article, we discussed the use of mod_gzip
to dynamically compress the output from an Apache 1.3.x server. With the growing use of the Apache 2.0.x family of Web servers, the question arises of how we can perform a similar GZIP-encoding function within this server. With great foresight, the developers of the Apache 2.0.x servers have included in the codebase for this server, a module that performs this very task.
Compile and Enable mod_deflate
mod_deflateis included in the Apache 2.0.x source package. Its compilation it is a simple matter of adding it to the configure command, like this:
./configure --enable-modules=all --enable-mods-shared=all
--enable-deflate
When the server is made and installed, the GZIP-encoding of documents is easily enabled. We simply add three lines to the httpd.conf file:
SetOutputFilter DEFLATE
SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png)$
no-gzip dont-vary
SetEnvIfNoCase Request_URI .pdf$ no-gzip dont-vary
What Does It Do?
This enables the automatic GZIP-encoding of all MIME-types, except image and PDF files, as they leave the server.
Image files and PDF files are excluded as they are already in a highly compressed format. In fact, PDFs become unreadable by Adobe’s Acrobat Reader if they’re further compressed by mod_deflate
or mod_gzip
.
On the server that we used to test mod_deflate
for this article, no Windows executables or compressed files were served to visitors. If you deliver these types of files, add the following line to the httpd.conf file to prevent them being sent in a GZIP-encoded format.
SetEnvIfNoCase Request_URI .(?:exe|t?gz|zip|bz2|
sit|rar)$ no-gzip dont-vary
For the file-types indicated in the exclude statements, the server is told explicitly not to send the Vary header. The Vary header indicates to any proxy or cache server the particular condition(s) that will cause this response to Vary from other responses to the same request.
If a client sends a request that doesn’t include the Accept-Encoding: gzip header, the cached item won’t be returned. The item that’s stored in the cache cannot be returned to the requesting client if the Accept-Encoding headers do not match. In this case, the request must be passed directly to the origin server to obtain a non-encoded version. In effect, proxy servers may store 2 or more copies of the same file, depending on the client request conditions that cause the server response to Vary.
Removing the Vary response requirement for objects that are not handled means that, if the objects do not vary due to any other directives on the server (browser type, for example), then the cached object can be served up without any additional requests until the Time-To-Live (TTL) of the cached object has expired.
How Does It Compare?
In examining the performance of mod_deflate
against mod_gzip
, the one item that seems to distinguish mod_deflate
is the compression algorithm used. The mod_deflate
algorithm uses ZLIB and doesn’t seem to be as effective at compressing files as the GZIP method used for mod_gzip
for Apache 1.3.x. The examples below demonstrate that the compression algorithm for mod_gzip
produces between 4-6% more compression than mod_deflate
for the same file.
Table 1 – /compress/homepage2.html
Table 2 – /documents/spierzchala-resume.ps
Attempts to increase the compression ratio of mod_deflate
using the directives that were provided for this module produced no further decrease in transferred file size. A comment from one of the author’s mod_deflate
states that the module was written specifically to ensure that server performance was not degraded by using this compression method. With future releases of this module, the authors of mod_deflate
may want to compare their algorithm to the one used in mod_gzip
, to see if there are ways to improve the achieved compression ratio in mod_deflate
without compromising server performance.
Conclusions
Despite the fact that the compression algorithm is not as effective as that found in mod_gzip
for Apache 1.3.x, using mod_deflate
for Apache 2.0.x is still an excellent way to decrease the size of the files that sent to clients. Anything that can produce between 50% and 80% in bandwidth savings with so little effort should definitely be considered for any and all Apache 2.0.x deployments.
Frequently Asked Questions about Apache’s mod_deflate
What is the mod_deflate module in Apache?
The mod_deflate module is a crucial component of the Apache HTTP server. It’s responsible for output compression, which means it reduces the size of data before it’s sent to the client. This process can significantly improve the performance of a website by reducing the amount of data that needs to be transferred between the server and the client. It’s particularly useful for compressing HTML, CSS, and JavaScript files, which can often be quite large.
How does mod_deflate improve website performance?
By compressing the data before it’s sent to the client, mod_deflate reduces the amount of data that needs to be transferred. This can significantly speed up the loading time of a website, especially for users with slower internet connections. It can also reduce the amount of bandwidth used by the server, which can help to reduce hosting costs.
How can I enable mod_deflate on my Apache server?
To enable mod_deflate on your Apache server, you’ll need to add some specific directives to your server’s configuration file. These directives tell the server to load the mod_deflate module and specify which types of files should be compressed. The exact directives you’ll need to use can vary depending on your server’s configuration, but there are many resources available online that can guide you through the process.
Are there any potential downsides to using mod_deflate?
While mod_deflate can significantly improve website performance, it’s not without its potential downsides. The process of compressing data can put additional load on the server, which could potentially slow down the server if it’s not properly configured. Additionally, not all types of files benefit from compression, and in some cases, compression can actually increase the size of the file.
Can I use mod_deflate with other Apache modules?
Yes, mod_deflate can be used in conjunction with other Apache modules to further enhance website performance. For example, you might use it with the mod_expires module to control caching, or with the mod_headers module to control HTTP headers.
How can I test if mod_deflate is working correctly?
There are several ways to test if mod_deflate is working correctly. One of the simplest methods is to use an online compression test tool, which can tell you if your server is correctly compressing data. You can also check the headers of your server’s responses for the ‘Content-Encoding: gzip’ header, which indicates that the data has been compressed.
What types of files should I compress with mod_deflate?
In general, it’s best to compress text-based files, such as HTML, CSS, and JavaScript files. These types of files can often be significantly reduced in size through compression. Binary files, such as images and videos, are usually already compressed, so compressing them further with mod_deflate is unlikely to provide any benefit and could potentially increase their size.
Can I control the level of compression used by mod_deflate?
Yes, you can control the level of compression used by mod_deflate by adjusting the ‘DeflateCompressionLevel’ directive in your server’s configuration file. The level of compression can be set between 1 (least compression, fastest) and 9 (most compression, slowest). The default level is 6.
Can mod_deflate be used with HTTPS?
Yes, mod_deflate can be used with HTTPS. However, it’s important to note that some older browsers do not support compression over HTTPS, so you may need to configure your server to disable compression for these browsers.
How can I troubleshoot issues with mod_deflate?
If you’re having issues with mod_deflate, there are several steps you can take to troubleshoot. First, check your server’s error logs for any messages related to mod_deflate. You can also use an online compression test tool to check if your server is correctly compressing data. If you’re still having issues, you may need to consult with a professional or seek help from the Apache community.
Stephen is currently the Principal Technical Trainer and Senior Diagnostic Analyst at Keynote Systems. He has been actively been working with, supporting and analyzing data from Internet technologies since 1994.