Hello,
I'm not too happy with the concept of purging a cache item a la Varnish that the purge 3rd party module promotes. Here are some reasons:
-
Nginx is not Varnish, the cache item is a file. So it's quite simple to deal with it.
-
In Nginx if you bypass the cache the cache get's refreshed, i.e., the response is fetch from upstream, so that instead of purging and
waiting for a new request to create a new cache item we should instead bypass the cache when we want to update an item and thus do
both the purging and the updating in a single request.
So if you want to use any sort of expiration logic you should instead of purging do a request bypassing the cache and voilà you have now an
updated item. There are several ways to do that. My favorite involves sending a special header with a secret token (to protect against abuses) such
that if the token matches the cache is bypassed.
What do you think? I know that there are proponents/adepts of using a pseudo HTTP method PURGE (a la Varnish) as the main mechanism for non stale caching around here ;)
Comments
I suppose you could adapt the
I suppose you could adapt the http://drupal.org/project/purge module to send the special header.
The only advantage I see would be that you wouldn't have to compile nginx with the cache_purge module.
Not only
that, but also there's no purge. The request would be a simple HTTP HEAD request that would update the item in the cache. So what was once two operations: purge + update is no only one.
Well, that's the main thing.
Well, that's the main thing. I agree with you.
It feels much more "nginxy" to bypass the purge operation completely.
This really sounds like a
This really sounds like a discussion you should be having with the Nginx developers upstream. IMO, Nginx's caching currently isn't very sophisticated, so if it works for you then great, but otherwise current Nginx caching clearing/updating methods feels very much like hacks on top of a feature that isn't fully implemented.
Certainly there's plenty of room for improvement
but the fact that a cache item is a file is a plus, IMHO. Instead of other approaches that give you more features at a cost of less "control" and more levels of indirection.
AFAIK, the caching facilities are going to be improved in the new 2.0 branch. Also I don't quite get the unsophisticated tag regarding Nginx caching. You might say that it lacks some convenient features, but I equate simplicity with sophistication.
Certainly setting up Nginx caching is not as easy as spinning up Varnish and grabbing a VCL file from somewhere. But the payout comes in greater simplicity and control.
This discussion is about how
This discussion is about how to optimize a simple caching scheme for Drupal users with minimum fuss.
If it seems unsophisticated, that's because we're intentionally keeping it that way. nginx can provide ssl, caching, static file serving, gzip compression, module architecture, and backend load-balancing with a fairly simple configuration and low resource usage. Varnish 3.0 is just starting to catch up with nginx in some of these areas.
If we were talking about complex caching schemes, we'd likely be talking about using nginx to communicate with memcached, redis, or other state of the art distributed key-value store with its own TTL and purge mechanisms and not using the native nginx cache.
Indeed
if you want to have a comprehensive all bells & whistles caching setup Nginx delivers:
It has both Perl and Lua embedded.
You can use Redis. Memcache, using 3rd party modules that are used in production for top 100 sites, or
whatever you can get to work with Lua and/or Perl.
It supports all of memcache text based protocol.
You can create sockets and make requests from within.
The purpose here is simplicity. If you're ok with extra parts in your system, then Nginx allows you to have very complex caching setups.
This is kind of OT, since we want to make it simpler.