WP-super-cache on lighttpd

Because my web server does not have a lot of processing power, dynamic web pages can sometimes be a bit slow. Especially if the server is busy. Serving static HTML pages is a lot better than serving PHP pages. In fact, most of the blogs on this site are just static “copies”. Using a web site downloader, such a HTTrack, I’ve made an exact copy of the web sites. This copy is served, instead of the dynamic content.

This server blog is a live blog, so I cannot make a static copy. But with the WordPress plugin WP-super-cache you can make caches of all pages. If a specific page is available in the cache, the cached paged in served. This saves a lot of executing time; no need to go to the database and get all the content. The cache has a time-out, so at regular intervals the caches are refreshed. And if a new post or comment is made, the cache is refreshed too. So users of the site won’t see any difference.

WP-super-cache supports two modes: the mod_rewrite and PHP. PHP will always work, but pages are served via PHP. The PHP script checks if a cache file exists, and serves that. This is still a lot faster than when PHP has to contact the database to build the page. But is still uses PHP. The other mode is mod_rewrite, but this is very specific to an Apache webserver. Because this site is running lighttpd, I had to search for the correct instructions. There are sites that describe a solution. However, after some debugging, I found out the solution doesn’t actually work (although it seems to work because the PHP mode is used). Also, when running WordPress as a multiblog site, images are also served using PHP. The solution below eliminates any executing of PHP when there is a static page available.

A special module, mod_magnet, in needed for lighttpd. First, install mod_magnet for lighttpd:
sudo aptitude install lighttpd-mod-magnet
Next, enable mod_magnet by runnuing:
sudo lighty-enable-mod magnet

Next, add a magnet rule to a site. In a previous post I explained how to add a site to the lighttpd configuration. To enable magnet for a site, a line needs to be added. The complete configuration then looks like this:

$HTTP["host"] =~ "server.vijge.net" {
server.document-root = "/home/www/wordpress"
var.wp_blog = 1
magnet.attract-physical-path-to = ( server.document-root + "/rewrite.lua" )
include "wpmu-rewrite.conf"
}

As you can see, a file called rewrite.lua is used. Create a file with this name in the WordPress installation directory. Paste the following code into the file:
[code lang=”lua”]
function serve_html(cached_page)
if (lighty.stat(cached_page)) then
lighty.env[“physical.path”] = cached_page
–print(“Serving cached page: ” .. cached_page)
return true
else
return false
end
end

function serve_gzip(cached_page)
if (lighty.stat(cached_page .. “.gz”)) then
lighty.header[“Content-Encoding”] = “gzip”
lighty.header[“Content-Type”] = “”
lighty.env[“physical.path”] = cached_page .. “.gz”
–print(“Serving gzipped page: ” .. cached_page .. “.gz”)
return true
else
return false
end
end

if (lighty.env[“uri.scheme”] == “http”) then
ext = “.html”
else
ext = “-https.html”
end

cached_page = lighty.env[“physical.doc-root”] .. “/wp-content/cache/supercache/” .. lighty.request[“Host”] .. lighty.env[“request.orig-uri”] .. “/index” .. ext
cached_page = string.gsub(cached_page, “//”, “/”)

attr = lighty.stat(cached_page)

if (attr) then
query_condition = not (lighty.env[“uri.query”] and string.find(lighty.env[“uri.query”], “.*s=.*”))
user_cookie = lighty.request[“Cookie”] or “no_cookie_here”
cookie_condition = not (string.find(user_cookie, “.*comment_author.*”) or (string.find(user_cookie, “.*wordpress.*”) and not string.find(user_cookie,”wordpress_test_cookie”)) or string.find(user_cookie, “.*wp-postpass_.*”))
if (query_condition and cookie_condition) then
accept_encoding = lighty.request[“Accept-Encoding”] or “no_acceptance”
if (string.find(accept_encoding, “gzip”)) then
if not serve_gzip(cached_page) then serve_html(cached_page) end
else
serve_html(cached_page)
end
end
end

Finally, add the following line to the wp-config.php file in the WordPress directory:
define('WP_CACHE', true);
Now you can go to the WordPress admin pages and configure everything. The mode setting in the admin pages does not have any effect. The rewrite.lua is always used. I recommend setting the mode to PHP, because setting it to mod_write will give an error that mod_rewrite is not enabled.

5 thoughts on “WP-super-cache on lighttpd

  1. hey, thank you for this. it works perfectly. I also didn’t know about mod_magnet and it seems really useful. 🙂

  2. Please fix the lua script, you have a typo there on line 39, the condition isn’t closed, you had a “$” in there probably when you copied and pasted from the terminal.

    That line should probably be as follows:

    cookie_condition = not (string.find(user_cookie, “.*comment_author.*”) or (string.find(user_cookie, “.*wordpress.*”) and not string.find(user_cookie,”wordpress_test_cookie”)))

    1. Uncomment the lines starting with
      –print(
      Then look in your web server error logs to see if it shows up.

      You could also look at, for example, the top command. It shouldn’t show any activity for PHP or MySQL when requesting a page. However, this does assume you have no other things on your page that invoke PHP/MySQL. E.g. I have some statistics that are written to the database, so for that you would see PHP/MySQL activity.

      1. Another way is to look at the source of the page. At the very bottom there is a comment like

        Cached page generated by WP-Super-Cache on 2016-11-23 14:31:48

        Visit the same page in two different browsers, and the time should always be the same. Note that if you use a browser that you used before the log to the site (cookies present) cache is bypassed. Use a different browser, or use incognito mode.

Leave a Reply to Daniel Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.