nginx Latest Entries

Enable WordPress Plugin, Theme Updates and Pretty Permalinks on Nginx

WordPress doesn’t know that your Nginx web server is capable of doing URL rewrites without mod_rewrite and Apache, so we explain that by adding:

add_filter('got_rewrite', 'nginx_has_rewrites');
function nginx_has_rewrites() {
	return true;
}

in your theme’s functions.php.

It is very likely that along Nginx you are also running PHP-FPM for all your PHP needs, and for some reason WordPress thinks its PHP process can’t write to disk. We tell WordPress that it can:

add_filter('filesystem_method', 'nginx_make_filesystem_direct');
function nginx_make_filesystem_direct() {
	return 'direct';
}

AJAX Cache Purge Cookie Plugin

This plugin sets a “version” cookie of your site’s content, which can be used for time-based cache invalidation, as the cookie is checked and updated (if necessary) on each page request through a single AJAX request.

Download: ajax-cache-purge.zip (June 26, 2010)

Installation

Please note that this plugin is intended for people who run their own servers.

  1. Upload and enable the plugin.
  2. Add the value of wp_cache_key_cookie to the cache key.

Nginx Example

fastcgi_cache_path 	/var/www/cache  levels=1:2
			keys_zone=wp-cache:10m
			inactive=2m max_size=2000m;

fastcgi_temp_path 	/var/www/cache/tmp;

server {
	# other config options

	location ~ \.php$ {
		# wp_cache_key_cookie is supplied by the plugin
		set $wp_cache_key $scheme$host$request_uri|$cookie_wp_cache_key_cookie;

		#add key in header for debugging
		#add_header	WP_KEY $wp_cache_key;

		fastcgi_cache 		wp-cache;
		fastcgi_cache_key 	$wp_cache_key;
	}
}

Use AJAX for Cache Invalidation

Let’s have a site wide version number that is changed every time something is updated and cache needs to be invalidated. This number is stored in a simple text file. Cache keys are made up of Request-URI and this unique key, which is passed around in a cookie VERSION_NO.

On every page request javascript calls version.php?timestamp (which is never cached because of the timestamp), which using stat() reads the last modified timestamp of that text file and compares it to the value of VERSION_NO cookie. If they are different, a new cookie value is set, which in turn changes the cache key for all future requests, and the cache is invalidated.

The only thing I don’t know is how fast and resource hungry is the stat() call?

Update: or would it be better to use filemtime()? There is a comment which says that 1000 filemtime() calls take 0.0049 seconds, which I think is very reasonable.

PHP APC Potential Cache Slam Averted for Key

APC opcode cache TTL lockup

APC opcode cache TTL lockup (via t3.dotgnu.info)

This server uses PHP 5.3 with PHP-FPM (FastCGI Process Manager) patch and APC opcode cache. Several minutes after activating APC, I noticed that some pages stopped loading. Turns out it was because of an APC timebomb bug which is when all cache writes got locked because of expiring cache entries and new writes happening at the same time. The temporary solution is to add apc.slam_defense = 0 and apc.write_lock = 1 in php.ini.