So you’ve done your due diligence and gone to great lengths to make sure that your WordPress server setup is top notch.
Nginx, PHP-FPM, and Memcached are all installed and process are running. Batcache and a Memcached PECL plugin are installed for WordPress.
How do you know it’s working, besides that things seem quick?
The obvious answer is to open an incognito or private window in your browser, visit the site in question, and then view source on the page load. In the <head> area, there should be a comment left by Batcache providing statistics on when and for how long it was generated.
However, the easy answer is not always the most fun answer. And not every answer tells the full story. Checking the reponse headers of the HTTP request can also fill you in on some extra info.
Batcache by default is set to only start serving cached page views if a page has been accessed more than twice in a 120 second period. It also should only be serving these cached views to unauthenticated users. Before you’ll be able to see the entire package in action, you need to load whichever page you want to test a few times as a non authenticated user, and then check the headers. If you have a command prompt with curl installed, your easiest option is this:
curl http://mydomain.com/
curl http://mydomain.com/
curl http://mydomain.com/
curl -I http://mydomain.com/
curl -I http://mydomain.com/Do these in quick succession, ignoring the page content that you receive after the first 3 commands. Hint, hint.. use the up arrow. Feel free to ignore me too, because right now I’m hitting it after one page view, so who knows what I did.
After the fourth command, issued with the -I flag that tells curl to only make a HEAD request, your should see output indicating that Batcache has caught the request and is attempting to work some magic.
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 10 Dec 2012 06:19:30 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
X-Powered-By: PHP/5.3.6-13ubuntu3.9
Vary: Cookie
X-Pingback: http://mydomain.com/wordpress/xmlrpc.php
Link: <http://little.shorty/2aYLe>; rel=shortlink
Last-Modified: Mon, 10 Dec 2012 06:19:30 GMT
Cache-Control: max-age=300, must-revalidateThe last two lines in this HEAD output are key. Cache-Control has been turned on, and the max-age of the request has been set to 300 seconds. Sweet! This means that at least one thing is doing something – Batcache.
Now, the second curl request made with the -I flag gives us almost the same information:
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 10 Dec 2012 06:42:45 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Last-Modified: Mon, 10 Dec 2012 06:42:43 GMT
Cache-Control: max-age=298, must-revalidate
X-Powered-By: PHP/5.3.6-13ubuntu3.9
Vary: Cookie
X-Pingback: http://mydomain.com/wordpress/xmlrpc.php
Link: <http://little.shorty/2aYLe>; rel=shortlinkYou’ll notice here that the Cache-Control line has moved up a bit and the max-age of the request has been set to 298 seconds. This means the timer on the cache expiration has started to count down. If you were to keep on making curl -I requests at this point, you could expect that timer to count all the way to 0 before the page cache was regenerated.
The ordering of the lines in these examples may not always match, but if you do this curl -I request multiple times and max-age stays at 300, this is probably an indication that while Batcache is doing what it needs to do, there is no actual caching going on in the background. At this point, check to make sure that you have an object cache plugin installed and that Memcached is in fact running.
Of course, sometimes it isn’t as easy as just making sure everything is running. Batcache and Memcached may be running fine, but if there’s a PHP Session to be maintained, then the Cache-Control header will probably not be modified and you’ll see something similar to this:
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 10 Dec 2012 06:06:33 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Last-Modified: Mon, 10 Dec 2012 06:03:29 GMT
X-Powered-By: PHP/5.3.6-13ubuntu3.9
Vary: Cookie
Set-Cookie: PHPSESSID=dpbnobn95jrgg5fhpfaa5sn707; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Pingback: http://mydomain.com/wordpress/xmlrpc.php
Link: <http://little.shorty/12345>; rel=shortlinkAt this point, you’ll need to go back to relying on the comment left by Batcache in the page source to determine if it is still generating things as intended. Though it may be work a search for ‘session_start()’ through your code base to see if you really need that PHP Session, as this could be negating some of what you are hoping to achieve through caching anyway.
Oh, and if nothing is turned on at all, expect something similar to this:
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 10 Dec 2012 06:21:48 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
X-Powered-By: PHP/5.3.6-13ubuntu3.9
X-Pingback: http://mydomain.com/wordpress/xmlrpc.php
Link: <http://little.shorty/2aYLe>; rel=shortlinkNotice no Cache-Control header at all when Batcache is out of the picture.
All of the above is intended to be taken with a grain of salt. I didn’t research too much of it thoroughly, and a lot is dependant on my specific environment. It may come in handy to a few though, and it’ll probably come in handy to myself again.
Server Setup: nginx 1.0.5 | Memcached PECL | WordPress 3.5 | Batcache | WordPress Memcached Backend
Responses and reactions
Replies
curl -I http://mydomain.com/ didn't display the Cache-Control line for me (curl 7.24.0 and 7.31.0). It took me a while to discover that there was nothing wrong with batcache. curl -i http://mydomain.com/ | head did display it however. It can also be seen in most browser dev tools.
The only requirement for your mention to be recognized is a link to this post in your post's content. You can update or delete your post and then re-submit the URL in the form to update or remove your response from this page.
Learn more about Webmentions.