Today’s article details an internal checklist we will follow when testing if a WordPress-Nginx setup is working perfectly.
Following tests are most common & important:
- Testing WordPress content cache for PHP/MySQL crash
- Testing Browser cache for static files
- Testing Gzip Compression
- Testing Nginx Map{} for Multisite Files
Testing WordPress content cache for PHP/MySQL crash
An ideal WordPress-Nginx setup will utilize caching at multiple levels. Most common way of caching is done by WordPress plugins like W3 Total Cache and WP Super Cache or using Nginx’s fastcgi cache.
Test if your caching solution is working:
If you are using Nginx’s fastcgi-cache, use this alternative method.
Please run following command for at least 2 posts minimum and 2-3 times on each post. If you are testing a Multisite setup, you must repeat everything for at least 2 different sites in network.
Command to run:
curl http://example.com/wordpress-post-url/ | tail -n 4 && echo -e
You should get the following output:
</html> <!-- Dynamic page generated in 0.050 seconds. --> <!-- Cached page generated by WP-Super-Cache on 2012-09-14 04:52:06 --> <!-- super cache -->
Please note the timestamp (highlighted in bold above).
If it remains the same after running command many times, your cache is working.
Test if Content Cache works after PHP crashes
You should run above test again after stopping PHP. service php5-fpm stop
If your cache is not working, you will get “bad gateway error” after PHP stops.
Testing Browser cache for static files
Browser caching must be done on Nginx’s end.
Take any file on your server and run command like below:
Command to run:
curl -I http://example.com/wp-content/uploads/2012/09/wow.png
HTTP/1.1 200 OK Server: nginx/1.2.3 Date: Wed, 19 Sep 2012 19:32:14 GMT Content-Type: image/png Content-Length: 3035 Last-Modified: Thu, 06 Sep 2012 15:14:25 GMT Connection: keep-alive Expires: Thu, 31 Dec 2037 23:55:55 GMT Cache-Control: max-age=315360000 Accept-Ranges: bytes
If you see lines in bold with future date, then it means browser cache is working. This will reduce load on server for repeat visitors!
Testing Gzip Compression:
Gzip support is by default enabled/handled by Nginx so we need not add config lines for it again. For this reason, none of my Nginx configuration have gzip block.
In case you are not sure, you can test if your site is using gzip by following this – http://rtcamp.com/wordpress-nginx/tutorials/nginx/enable-gzip/
Make sure you enable gzip for HTML, CSS & Javascript output atleast.
Testing Nginx Map{} for Multisite Files
If you are following our WordPress-Nginx series, then you must be using Nginx Maps{} directive on your WordPress Multisite setup.
In that case, you must check if static file uploads on Multisite can be accessed when PHP crashed.
Just stop PHP, and run following command.
curl -I http://example.com/wp-content/uploads/2012/09/wow.png
HTTP/1.1 200 OK
That means, you can access files without PHP.
For added safety, clear browser cache and open file URL in browser.
Hi Rahul,
When testing W3 after PHP is stopped, do you mean it is normal that we get a “bad gateway error” or it is supposed to serve the files without talking to PHP (use Nginx rule to get the cached files) ? Thanks.
Jack
@Jack
“bad gateway error” can either mean caching is not working or the page was not cached before PHP went-down. This is reason we need to make sure if cache is working properly with PHP on.
I configure W3 Total Cache using your article.
And then I got a cached page (it had a HTML comment from W3), stopped PHP-FPM, but I’m getting “Bad Gateway”.
Do you know why?
Please check – http://rtcamp.com/groups/wordpress-nginx/forum/topic/w3-total-cache-with-nginx-not-working/
I replied there.
I think you need to mention the followup articles.
i can see you mentioned as “means browser cache is working”
But where is Browser cache article link?
Also, I cannot see GzipCache enabling article link too…..
Thanks for pointing it out. 🙂
Added a detailed tutorial here – http://rtcamp.com/wordpress-nginx/tutorials/nginx/enable-gzip/
I hope it will be helpful.
How can I figure out why after turning php5-fpm off, the site home page shows 502 Bad Gateway, instead of serving the cached file? Looking for tips to get this working as it should. I’ve nginx, php-apc and w3 total cache. (No fastcgi caching).
Did you followed our config for w3tc – http://rtcamp.com/wordpress-nginx/tutorials/single-site/w3-total-cache/ ?
If yes, please share your config on https://rtcamp.com/support/forum/wordpress-nginx/ and we will try to debug it.