bigsite

I think we found the problem – the server’s primary hard drive was slightly corrupted probably due to hard reboots. I’ll be keeping an eye out for additional issues.

We just updated to nginx 1.0.0 and it overwrote the SCRIPT_URI addition to the ‘fastcgi_params’ file. Maybe it wasn’t smart to modify that file. Dropped the change into the global/wordpress-ms-subdir.conf file and that resolved the issue (again).

Looks like the latest development version of WP Super Cache now includes differentiation between http and https served content. I’ve updated the Codex to reflect this significant change.

Supposedly there is some better mobile theme support (i.e. actual caching for mobile themes instead of the current cache bypass) in the development version of the WP Super Cache plugin as well but is kind of hacky and I’m not seeing any rewrite rule modifications yet.

Thanks. But I’m not particularly fond of that solution since it will create so many unnecessary directories.

@abigailblake – We’re using dedicated, on-site hosting, nginx + php-fpm + PHP APC + WP Super Cache on a decent traffic site (we used to be an ISP). We control the servers and I’m very comfortable with PHP and WP plugin authoring. If the person who reported the initial issue to me can replicate it again in our environment, I’ll be looking into it. If I can figure out the issue, it’ll get reported to Trac as a bug with the requisite patch against the WP core.

We may have a similar issue in WP 3.1 (multisite subdomain). If we do, that means I’ll be digging around in the WP source code to see what I can see.

@zsiddique – Build PHP from source. There are lots of examples around on how to build PHP from source for Ubuntu. If you use PHP APC, you want the latest PECL version of PHP APC and the latest version of PHP.

@zsiddique – Try reinstalling the WP Super Cache plugin. I always use the latest development version instead of whatever the official release is. If you have used another caching plugin in the past with your site, that can cause strange conflicts with WP Super Cache. I had weird issues with upgrading to WP Super Cache from WP Cache 2 until I completely deleted all files related to WP Cache 2.

Also, you aren’t running the latest version of PHP.

@pablox – A WSOD indicates an error probably happened somewhere and PHP stopped processing when it encountered the error. Check your server logs since PHP and other errors will show up there. I can only guess as to the cause at this point.

Be aware that not all plugins are WP multisite/network-aware. WP 3.0 finally forced the issue onto plugin authors so the situation is improving slightly.

Cleaned up the Codex with the updated set of configs and tried to make it more general-purpose. Removed the initial “broken” server {} block that was posted since a “try_files $uri =404;” line in a \.php$ location {} block is critical unless the person running nginx knows exactly what they are doing. Also, the correct practice is to use upstream {} blocks for setting up fastcgi servers. Having two configs on the same page was also a bit confusing.

But, other than those issues, the Codex page looks pretty good to me. We just need W3 Total Cache rules and someone to test out the regular WP rules and someone else to see if subdirectory rules work with subdomain as-is. Looking forward to seeing nginx being used more widely now.

@bowe – To answer your questions:

1: Is there a reason why you chose Super Cache over W3 Total Cache? I thought the later was better, but if you have a fully working Super Cache setup with Nginx I might go for Super Cache

We chose WP Super Cache because we were previously using WP Cache 2 upon which WP Super Cache is based. Our setup is fully functional on WP Super Cache. We tried to use W3 Total Cache around the time WP 3.0 came out and ended up White Screening (WSOD) the whole site – that disaster took a whole day to fix. IMO, WP Super Cache is the easier and more stable static caching plugin. They are both comparable in feature set but I’m more familiar and comfortable with WP Cache 2.

2: How have you set up your CDN? Do you use W3 Total Cache for that, or a different plugin? And does that also need rewrites to work? (since .htaccess does not work on NGinx).

We don’t use a CDN (yet). Still, WP Super Cache should be rewriting the page content to point at the configured CDN prior to caching the page in the file system. From the nginx perspective, this is transparent and therefore no changes to the nginx configuration should be required unless, of course, you host your own CDN.

@graq – To answer your questions – I merely ported the rules from .htaccess that were generated by WordPress and WP Super Cache.

1. What is the importance of adding a trailing slash to wp-admin requests?

Mostly to point the user at the right location. I’m sure some code breaks if wp-admin without a trailing slash is passed into the WP codebase.

2. What is the relationship between rewrite /files/$ /index.php last;
and rewrite /files/(.+)$ /wp-includes/ms-files.php?file=$1 last;

The first rule checks to see if the directory is being requested. The second rule passes files to ms-files.php. ms-files.php only serves up multisite files and can’t handle directory requests. Again, these rules came straight out of .htaccess.

3. I use just rewrite ^.*/files/(.*) /wp-includes/ms-files.php?file=$1;
Is that better/worse/same?

Worse. “^.*” is unnecessary.

There is no mention of fastcgi-caching in your configs, which possibly a reason why you are not seeing as much of a performance hike as you were hoping for, as it can be comparable to supercache.

Not likely. By “performance improvements”, I was looking at CPU usage charts of before and after and stacked them up to a similar Apache configuration we were trying. I didn’t see nearly as drastic a difference for nginx vs. Apache for the same setup as PHP APC and WP Super Cache offered. But I did see a slight CPU drop which indicated to me that nginx is more efficient. However, it may not necessarily be worth the effort to switch servers. fastcgi caching won’t necessarily offer any benefit over other caching mechanisms such as WP Super Cache and may possibly get in the way of the normal operations of a WP caching system.

@bowe – I’ve only had experience with migrating an existing WP site from Apache to nginx. nginx isn’t for the feint of heart. I have no experience with HyperDB – although I suspect that is my next upgrade of the site I work with.

I’ve discovered through my own adventures is that most people will get a ton more mileage out of using PHP APC and WP Super Cache together than using an alternative web server like nginx. After using PHP APC and WP Super Cache, I’d start playing with CDNs and scaling the database infrastructure to share the load with other computers. There’s only so much one machine can do.

If your problem with permalinks is short, feel free to post the specifics here as I could have missed something important in my config. Otherwise, use pastebin.com and copy your nginx configuration files there and then talk to the people on the nginx IRC channel.

The IRC channel for nginx is very active. The good folks there kindly look at nginx configurations all day long and help fix problems. One of the regulars there runs a few WP sites with nginx.

@ipstenu – We are already running a couple hundred sites in a single install with no problem here. This should be a configuration option.

@agreda – Glad this post helped you.

@ipstenu – It has been working fine since WPMU.

@andrea_r – It was scaling just fine for us.