Static Content and Caching

With this basic setup working, the next step is for nginx to statically serve some images. This step will allow you to tune your back-end httpd processes for dynamic content serving. I'll also serve images with an expires header of 30 days, which will cut down on the number of requests a client needs to make for common images that rarely change. To accomplish this, add the following to your server context:

location ~* ^.+\.(jpg|jpeg|gif|png)$ {
       root      /path/to/www;
       expires   30d;
}

If you'd like to disable logging for images requests, add the following line to the configuration:

access_log off;

Next, nginx will gzip some output received from the httpd back-ends before sending it to the browser. The nginx server will only gzip certain content based on mime type and will completely disable gzip for some known-broken browsers. Add the code in Listing 3 to your server context.

If you'd like to cache some of your dynamic content with nginx, you have two options; file based or memcached based. If you're considering using nginx to cache content, be careful how you cache content that differs based on whether a visitor is logged in or not. To enable the file-based cache, add the following to the http context in your configuration file:

proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=one:10m;

The levels parameter sets the number of subdirectories for the cache, and the key and filename are an md5 of the proxyied URL, resulting in filenames similar to /data/nginx/cache/c/29/b7f54b2df7773722d382f4809d65029c.

With the cache path set in the http context, you can now setup your cache in the http, server, or location context. To cache all 200 and 302 responses for 30 minutes and all 404 responses for 5 minutes, add the following:

proxy_cache one;
proxy_cache_valid 200 302 30m;
proxy_cache_valid 404 5m;

If you'd prefer to use memcached for your cache, it's almost as easy (see Listing 4).

Server Statistics

Many monitoring systems support the httpd mod_status module to gather and trend statistics. The stub_status module serves a similar role with nginx. This module is not compiled by default and must be enabled with the --with-http_stub_status_module configure argument. Once the module is compiled in, add the code in Listing 5 to your configuration file. An HTTP request to domain.com/nginx_status will return a plain text response in the format shown in Listing 6.

Additional Modules

The httpd mod_rewrite module is used by many sites. While nginx does have a rewrite module, its syntax is slightly different from the one for httpd. The nginx wiki has the full details [4].

One example of rewrite feature is a simple rewrite to enable SEO-friendly member pages:

rewrite ^/users/(.*)$  /user.php?user=$1? last;

A more complicated rewrite uses an if condition to redirect your visitors to a consistent domain:

if ($host ~* www\. (.*)) {
   set $host_without_ www $1;
   rewrite ^(.*)$ http://$host_ without_www$1 permanent;
}

The GeoIP module creates variables based on the IP address of the client matched against the MaxMind GeoIP binary files. The nginx GeoIP module has two prerequisites – libGeoIP and the MaxMind GeoIP database(s). The latest libGeoIP is available from the MaxMind site [5], but keep in mind that many distributions have libGeoIP in their package repositories.

Add the following two lines to your http context to enable the GeoIP module.

geoip_country GeoIP.dat;
geoip_city GeoLiteCity.dat;

You will now have the variables listed on http://wiki.nginx.org/NginxHttpGeoIPModule at your disposal. One common use case for the GeoIP module is to use the $geoip_country_code variable to send requests to different proxy upstreams based on country. If you'd like to pass the GeoIP information to you httpd back-ends, add the following to your proxy configuration:

proxy_set_header HTTP_GEO $geo;

Table 2 shows some additional nginx modules, along with a brief overview of their functionality.