Over the last few months, I’ve been doing a lot of work trying to speed up the sites on my server….perhaps to the detriment of this site, Gadget Wisdom.
Gadget Wisdom runs on WordPress on a Nginx web server. To run PHP on an Nginx server, you need to pass requests to a FastCGI server.
Nginx supports caching the responses. So, WordPress generates a page dynamically, Nginx caches the response and can serve the cached version on request. Since the resource intensive part is the application, and most people don’t need a changing page, it works for the majority of issues.
For the last few years, refreshing the cache has been done by sending a request with a specific header. This has the effect of telling the system to generate the page again and store the result. A recent upgrade added in the optional Nginx Cache Purge module. This allows a purge of a specific page using a simple URL scheme.
The net difference between the two in effect is that the purge function removes the cached version to be regenerated on the next load. The header option generates a new version of the page which is stored in the cache. The disadvantage of the Purge module is you have to custom-compile Nginx…which means you have to manually keep up on security bugfixes.
Either way, once you decide on methodology, you also have cache validity. For example, many people opt for a microcache solution…where the cache time is very short, measured in seconds. This means that only when the site is being hit will people be served ‘stale’ pages.
The alternative is a very long cache time…measured in hours/days. As long as you have a cache refresh function available, such as the options mentioned above so you can remove the stale pages on demand, you can keep the pages around for longer periods of time.
Right now, my cache validity time continues to rise over time. You also have browser caching. Right now, images are instructed to be cached by your browser for days. I don’t usually change my images much after posting…or at all.
So, this post hopefully covered the basic decision making process for FastCGI caching on Nginx. In Part 2(if I get to it), we’ll cover some of the settings to allow this, as well as some of the considerations you have to make while coding this.
