Checklist For Perfect WordPress-Nginx Setup

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
You will see output like below:
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
If output contains

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.

9 Responses to “Checklist For Perfect WordPress-Nginx Setup”

  1. 一篇关于Nginx+Wordpress-multisite+静态文件处理的重要文章 | WP奇才

    […] Checklist For Perfect WordPress-Nginx Setup http://rtcamp.com/tutorials/checklist-for-perfect-wordpress-nginx-setup/ […]

  2. Jack

    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

    • Rahul Bansal

      @Jack

      1. First you need to open a page while PHP running so a cached version of page will be created to start with.
      2. Then you can view HTML-source of that page to check timestamp in HTML comments from footer (most caching plugins adds one).
      3. Then you can refresh that page after clearing browser cache. If timestamp doesn’t change cache is working most likely.
      4. Finally, shut down PHP and refresh that page. At this point you will see the page again.

      “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.

  3. Marco

    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?

  4. Atul Bansal

    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…..

  5. Jon

    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).


Comments are closed on this article.
Please use our free support forum for support and discussions.