Nginx on the front end is AMAZING when it comes to handing static content. Then let Apache or FastCGI do the heavy lifting of PHP and your website can handle much higher loads than normal.

Anyway, what I had come up with isn’t too far from what you’ve already done, except that I use Apache for the back-end and I have added support for mobile phones.

The mobile phone support was important to me, since I am using a different themes for those, which aren’t cached. I would post it here if it wasn’t such a long line (I’m checking for more mobile browsers than WP Super Cache does), so have a look at:

http://www.myatus.co.uk/2009/12/17/faster-wp-super-cache-with-nginx/

Just take that code that checks the user-agent, place it among the other “if .. set $supercache_uri” lines as shown here, and instead of ’set $mobile “M”;’ you use “set $supercache_uri ”;”. Don’t forget to disable it in WP Super Cache itself

function spawn_cron() {

//skipped some code

if ( $argyle )
fputs( $argyle,
“GET {$parts['path']}?check=” . wp_hash(‘187425′) . ” HTTP/1.0\r\n”
. “Host: {$_SERVER['HTTP_HOST']}\r\n\r\n”
);

}

The socket was closed immediately, and nginx, working as a frontend for Apache, considered this as an error (#499 – the socket was closed prior to reply of webserver), the GET request was not relayed further and the task planner did not work. The problem can be resolved by adding a usleep(100000); delay (or a bit bigger, depending on the load of the server).

In further versions, wp-cron was rewrited and the tasks were spawned by this code:

wp_remote_post($cron_url, array(‘timeout’ => 0.01, ‘blocking’ => false));

A 0.01 second delay is often too small, so this should be changed to

wp_remote_post($cron_url, array(‘timeout’ => 0.1, ‘blocking’ => false));

or something like this, for proper work of wp-cron and nginx.