Has anyone tried nginx caching with Drupal?

Yes, we are using ncache and still testing different live setups, to compare with Varnish performance and Pressflow compatibility. I think we will be able to share the results in the next two weeks.

~Grace

It is also often mentioned in the High performance g.d.o.. Pressflow has everything we need to use reverse proxy cache. Now we need only some good benchmarks to compare Varnish and Ncache results.

This is my preferred thread there: http://groups.drupal.org/node/25617

~Grace

I've had a chance to play with nginx native caching a bit and so far I've come to these conclusions:

The Patch

The dev team has worked up a patch to Drupal core that is designed to make Drupal friendly to the Varnish and Squid caching reverse proxies. It makes a few helpful changes such as:

1. removes session cookies for anonymous users,
2. sets a NO_CACHE cookie when you log in which persists for the session after logging out,
3. sets Expires and Cache Control headers in php for index.php (other files are still set through .htaccess),
4. sets a Vary: Cookie header so that forward proxies in the chain will know when people log in,
5. provides sample Varnish and Squid settings in default.settings.php comments to use the NO_CACHE cookie to recognize logged in users and users that were logged in but have logged out,
   among other things.

Note that removing session cookies for anonymous users is going to break the functionality in a few modules, such as letting an anonymous user put items into a shopping cart before they log in to purchase.

The development of the patch and the reasons for the changes are explained in this thread http://drupal.org/node/147310. The patch has been developed for D7 and committed there, but it has also been backported by David Strauss at Four Kitchens for incorporation into Pressflow (optimized version of drupal) and the backport is now used on d.o (see http://nnewton.org/node/9). The patch for D6 can be obtained from Four Kitchens' public versioning system using a bzr client and minimal diff/patch skills.

I've applied the patch for testing with Nginx.

Using native Nginx caching

Recent versions of nginx, including the latest 7.61 and above, feature integrated caching of responses from backend servers. Whether you're using an Apache backend behind Nginx, or a special server, or just using Fastcgi for php as a backend, nginx can cache the responses from those backends as static files on the file server. Caching in RAM is a horse of another color and is achieved using memcache, which nginx also supports but is not the subject of this post. Nginx will take a client request, check to see if it has a static file in its cache for that request and serve that static file if found. I don't know if it buffers the keys in memory or makes file system checks. If it is not found, it will continue to pass the request to the backend server and then as it serves the file back out to the client, it will create a static file for that request in its cache. The file is saved on the file system with an md5 hash. The file will be saved and served for a set period of time and then flushed.

The settings for a simple system that caches everything and flushes it after 10 minutes is easy enough:

That defines a caching zone named "two" that saves up to 500mb worth of static files at /var/cache/nginx. "Levels" defines the depth of the directory structure used, to avoid such things as 32k directory limits and should be adjusted based on the number of pages to be cached. The caching mechanism names the static files using the URI as a key (md5 hashing them), caching "any" responses (or you can limit it to certain http response codes, i.e. 200, 304, etc.), and purges them after 10 minutes. Nginx respects the backend response headers such as Cache Control or Expires when those headers say not to cache. Since those headers are created by Drupal to instruct the client browser, Nginx must be told to ignore those headers. Nginx must also be told to pass Set-Cookie, since it doesn't do so by default with caching.

Now with Squid or Varnish you are also going to cache static files (i.e. css files, js files, images, or whatever). The reason for this is that Squid and Varnish have shown themselves to be much faster at serving static files than Apache with mod_php, so rather than allowing Apache to serve those static files, they are cached by Squid or Varnish and served by them (without any php overhead that is included in every apache thread when you use mod_php). However, Nginx with fastcgi/php is also much faster than Apache at serving static files, and by some benchmarks just as fast as Squid or Varnish. Your own benchmarks on your production system are the only way to tell for sure if Nginx will serve static files for you as fast as Squid or Varnish. For my purposes here, I'm not caching static files, but using Nginx to serve them directly. All I'm caching with this config are the dynamic responses from the fastcgi/php backend.

Now if you're using Drupal only to serve anonymous users, and you don't mind your content updating every 10 minutes, this setup is fine. However, once you log in, Nginx will keep serving you cached files so you won't be able to see your edits. Nginx will also cache all your admin work, which would be a waste of cycles and storage and also creates a security problem. You could setup an admin subdomain if you only have a few editing admins, but most Drupal installs allow basic authenticated users to login to post and do their business, so this is not acceptable.

So the patch provides for the NO_CACHE cookie when people log in, and provides settings for Squid and Varnish to serve fresh pages if you have that cookie and to not cache any pages requested by a person with that cookie. Unfortunately, Nginx cannot do this at the moment. There may be some hackish way to configure it using if{} statements, but Igor (the developer of nginx) recommends something else. He recommends adding the cookie value to the key that the cache uses, so that when a person with the NO_CACHE cookie hits nginx, their url+cookie key will miss the cache which is based on url+empty_cookie_value and pass the request to the backend. This would work, except that the cache would then cache the new url+cookie requests as well, and when the person logged out, they would still get the logged in pages that we don't want in the cache in the first place. Igor's solution to this is for the php script (i.e. Drupal) to serve an additional http header with logged in requests to tell Nginx on the way out not to cache those requests. Igor suggests the X-Accel-Expires header with a value of zero. Nginx will respect that header, just as it would respect Cache Control or Expires, except that we're not ignoring it, so that responses from Drupal that are marked with that header will not be cached. Since the logged in responses will never cache, the uri+cookie requests will always miss the Nginx cache and be passed through.

Unfortunately, the patch was not targeted at Nginx, so no such additional header is included. Squid and Varnish don't need it. Since I'm not a programmer (I'm clearly in a much more long-winded profession), I haven't attempted to add the header to the patch. It seems like it might require only a line or two in the correct spot. If someone would like to offer the appropriate patch, I'd be happy to test it.

Native Nginx caching or Boost

Finally I have to ask myself if caching is really worth the trouble with the existence of a great module like Boost if you're using Nginx. The fact is that Drupal+Boost with Apache+mod_php still isn't fast enough. Boost creates the static files, but you're still serving them with Apache+mod_php. Varnish or Squid in front of Apache+mod_php serving their cached files is going to blow the non-proxy setup out of the water because Varnish and Squid are so much faster than just Apache+mod_php at serving static files.

However, this may not hold true if you're using Nginx, because Nginx is also very fast as serving the static Boost files.

Boost also has several advantages. Since it works at the Drupal level, it can provide options like excluding specific pages from the cache, and expiring cache pages when they're edited. Boost can create two versions of every page, one uncompressed, and one pre-compressed with gzip, and Nginx can decide which to serve based on the capabilities of the browser. Precompression can save CPU cycles over on-the-fly compression and can allow you to use the highest and most CPU costly level of compression. Boost also includes a pre-crawler that can create your entire set of cache files during cron jobs. Of course, you could write your own cron-activated crawler to touch files through Varnish, but Boost includes a sophisticated Drupal-specific one that uses the the Drupal path alias db. Boost accomplishes some of these feats by adding some db overhead while managing the cache, but the reduced load on the database by no longer using database-based caching for anonymous users is substantial.

So the question becomes, is native Nginx caching preferable to Boost caching at all if you're using Nginx? The way to answer that question is with extensive benchmarking, which I have not undertaken.

Any thoughts?

Edit: Fixed some formatting errors caused by my non-understanding of the Markdown filter and failure to use the Preview button.

I made a tiny module to insert the header that nginx requires. My current config is:

I'm a little sad to lose the redirect to clean urls of the Global Redirect Module, and I need to check to see if Google Analytics cookies are being set. But generally it works correctly and quickly with the combination of patch, http{} and location{} config, and tiny module.

Edit: You do still need the nginx_header module and the "fastcgi_pass_header X-Accel-Expires;" to handle the NO_CACHE cookie.

You don't want the "fastcgi_ignore_headers Cache-Control Expires;" or "fastcgi_cache_valid any 10m;" in the config.

You need to set caching to aggressive (normal won't send the header), set "Page Cache Maximum Age" to the desired expire time, and something like the following to catch the cookie and it will give the correct expire time in the Cache Control header and Nginx will honor it.

Sorry for spamming the group mailing list.

Very interesting, How can i subscribe to thread?

http://en.wikipedia.org/wiki/Access_time is interesting, guess we can assume when dealing with network latency the difference between memory and disk is minimal. Did you happen to get CPU & Memory load of ncache vs nginx+boost? Varnish uses 80mb of ram correct? I would guess CPU usage would be much lower when doing nginx+boost since it doesn't have to run the MD5 function 3k a second.

I linked your post to the front of the Boost page, hope you don't mind :)

Unrelated to the benchmarking, but related to the original thread, I'm looking at the "fastcgi_cache_min_uses" directive to use nginx caching as a sort of "throttle" module. For ordinary low traffic, all pages are dynamic. However, if you get more than a certain number of requests for a page within a certain time frame, it caches the page and serves the cached version. In this example, it serves dynamically until the same page is requested 100 times within 10 minutes, then it caches the page for 10 minutes, then starts over. You get caching of your popular pages, but not all pages. Digg insurance?

You would still want to use Pressflow/patched Drupal and the Nginx Header Module.

It's doable, but it's an edge case. See http://technosophos.com/content/53900-speedup-nginx-drupal-and-memcache-... I dunno if he ever released his patches to the memcache module or his nginx config.

What I'm talking about is using either Boost or nginx native caching which also serves cached pages without touching the Drupal php backend. Both save the pages to disk files instead of keeping them in memory like memcached. But with OS filesystem caching, files are saved in memory to the extent that memory is unused, and OS file caches are quite efficient.

It depends on the scale of your application. If you've got one server hosting your site (or a second mysql server) then there's no advantage using memcached over using nginx's native file cache or Boost and letting the OS filesystem cache keep the files in memory. Of course if you've got a few 64MB dedicated memcached servers, then that's a different story. That's what memcached is all about.

Subscribing to the topic.