WordPress MU

1. Nginx Fastcgi Cache - From the personal results I've experienced so far this easily beats and replaces a significant portion of other caching systems like supercache and w3 total cache.

It's also been very handy for cutting back on image processing and serving outside the typical caching benefits.

blogs.php causes a lot of unnecessary additional load on the server because it uses php to find and serve static files. With nginx fastcgi_cache the response from blogs.php can be cached so its served as fast as any other static files. This works across multiple blogs and domains. You can control cache times based on whether they or not they are users. For example if they are a user you might send them cached pages of up to 30 minutes old and if they are not a user you might send a cached response of a day. If its a jpeg you might set the cache to 7 days plus add in browser caching in the headers.

If you've got this kind of set up on something like Amazon you can set up a terabyte Elastic Block for nginx to cache php responses on there. I haven't tried it yet but in theory you could in fact cache to multiple terabyte Elastic Blocks in Amazon or any mounted network drive. This means a lot of your caching is done for the cost of extra disk space and you're not just restricted to one computers disk space. Thats something that has held supercache back over batcache. Batcache you have to purchase more memory to expand. Nginx fastcgi cache will not solve all your cache problems but it works very well with a batcache solution.

After the success in eliminating the load I replaced blogs.php to include dynamic image resizing eg:

/files/2009/12/megan-fox.jpg?w=345

This is helpful for themes that have all kinds of custom sized images in the template. blogs.php will do the resizing once and then nginx will served the cached version of the resize for as long as you specify.

2. Google App Engine for Image Processing and Serving statics - The above solution is pretty cool but I was thinking as you get more and more users statics obviously take up load time (although this isn't such a big deal with nginx.) Image processing however takes up more and more cpu time on your server. I was thinking it would be call to have a Google App Engine app which provides a service to your mu installation and does all your image resizing and serves all images as well as the core wordpress statics. That way you remove the image processing to a firstly free, then very affordable solution with virtually unlimited scalability for these features.

You could also tack on the functionality which converts javascript files into the one php file.

Anyway those are a couple of ideas.

You could also tack on the functionality which converts javascript files into the one php file.

Actually we tried something like that awhile back and the use of wp-super-cache didn't allow that.

We now do a single plugin call for wp-head though that calls all of the javascripts in one batch instead of allowing the individual plugins do it. Saves time as you don;t have all those add_actions through out all of the code. You just have one. Well, two since we do this for the admin side as well.

We also do this for plugin CSS additions as well.

Clearly, not invoking PHP is ideal, but you get that with W3 Total Cache, WP Super Cache and some of the other plugins that produce .html files. The only reason I tend not to agree with web server only performance optimization approaches is because one ends up just shifting lots of functionality to the web server instead of optimizing the application and the web server separately (which I feel produces a much more scalable stack), especially when opcode caching is in play.

Having said that, Nginx support is in the roadmap for W3 Total Cache and all of the various modules available will be explored and bench tested, meanwhile, W3 Total Cache is the most robust solution for integration of CDN functionality (whether self-hosted or not) as well as minification. The database caching improves concurrency for you and works with a multiple server environment, the same is true for page caching as well. There have already been users modifying the apache directives to realize stellar performance in lighttpd and nginx, so I think all that's left is to do some bench testing to see which modules unlock the best performance. I would venture to guess that disk-based caching solutions are still going to be best for most standalone server environments.

As for managing images generated by PHP, I recommend generating flat files and using logic to directly access those files to reduce the invocation of PHP. If coupled with elastic storage like S3 (and coupled with varnish for example) or a CDN, you would realize the performance you want without having to deal with image manipulation in each request PHP which will always be expensive.

@tdjcbe, so do you rewrite every third party plugin and theme you use to leverage the single wp-head call?

Hi, I'm tottaly new here, nice to meet you