Site Update: WP Super Cache Active

So far so good. It seems the use of CloudFlare CDN hasn’t broken anything critical yet, although as CloudFlare only caches static content, the slow response time of Ziphosting’s servers is still a problem.

So far, I have found that Ziphosting seems to be fine with hosting static files, but as soon as the mySQL server gets involved, everything takes longer.

To combat this, I’ve decided to go with a WordPress caching solution – in this case, I’ve chosen WP Super Cache. The idea is that WP Super Cache will pre-generate static HTML files which are served provided no changes are made to the actual content of the post and comments. Regardless, such caching systems have the potential to screw up the site (i.e. white screens of death) and comments (i.e. delayed, not visible).

One of the changes that was required to get WP Super Cache working is to enforce a new permalinks structure. I had been using WordPress’ default structure for a while, and while not elegant, it was sufficient.

Now, I have migrated to a structure to make WP Super Cache most effective (and avoid a potential issue with too many cached files in a single folder). Luckily, links written in the old format are gracefully redirected to the new structure with no changes necessary. However, links and posts from now on will default to the new structure.

I’ve tried my best to configure WP Super Cache to be most effective to improve the user experience, while also hopefully not being too burdensome on my web hosting provider. I figure I’d do everyone a favour here …

So if you do experience strangeness or problems – please let me know.

UPDATE: Well, it seems the change of permalink format means a reset of all the share button counters on the site. While that’s a bit disappointing, I suppose there isn’t much I can do about it.

UPDATE 2: It seems it’s made the pingbacks feature work again. That’s cool! For some reason they stopped working a while back for pingbacks within my own site …

About lui_gough

I'm a bit of a nut for electronics, computing, photography, radio, satellite and other technical hobbies. Click for more about me!
This entry was posted in Uncategorized and tagged , . Bookmark the permalink.

8 Responses to Site Update: WP Super Cache Active

  1. sparcie says:

    It would be interesting to see what difference, if any, you notice in speed. Also I’d expect a caching service like cloudflare might interfere with accurate hit statistics on your web server. Do they have a statistics section for reporting how much is cached and cached page hits?

    As for my experience it seems slightly slower if anything, but it could just be a busy time of day, a local network issue, or that I’ve happened to hit uncached content. Uncached content will be slightly slower because of the time required to check the cloudflare cache, redirect, check the local cache and then finally generate content. Of course this should only happen on the first time a page is viewed or after the cached data has expired. The expiration time might have to be adjusted, but not until you get some performance feedback. I also think some stats packages (like awstats) can tell you how long the requests take to process.

    Fortunately this isn’t an issue for myself as I use wordpress for hosting my blog itself, and only static pages for my self-hosted download page, and it barely gets any traffic at all.


    • lui_gough says:

      Good point – as CloudFlare is acting as a reverse proxy, it does hide the IP of the originating requestor. However, there is a CloudFlare WordPress Plugin that restores this information, based on the fact that CloudFlare adds an optional HTTP header to indicate who the request was forwarded for, thus restoring the identity of the visitor at least when it comes to commenting IP address.

      For server side analytics, things are tricky. There really isn’t anything there that I am aware of that will fully restore all analytics on the server side (as awstats is), but to at least alleviate some of the issues, CloudFlare has its own analytics engine that can be used to gauge the visitorship as well as identifying the number of request wholly handled by CloudFlare and bandwidth saved. I will be keeping a good eye on this, but so far on the first day, 25% of data bandwidth have been saved by CloudFlare caching static objects, which only represented 10% of all erquests.

      The slight slowdown in CloudFlare might actually not be as bad for some users outside of AU – remember that CloudFlare has a network of endpoints, and by fetching your site from an endpoint that’s closer to the server and relaying it through CloudFlare’s own private network to your local edge node you can avoid congestion on the public internet – especially congested transit links here and there. Less of an issue for Australian visitors, as I’m hosted here, but for overseas visitors it can make a big difference.

      I’ve also done some extensive tweaking of cache expire times here and there, to values which make more sense for me, although of course I still want some “freshness” in case I do make a mistake and need to update a post. Unfortunately for CloudFlare free users, they will have to invalidate the whole cache to see immediate updates, so that’s why I don’t set the cache expiry too long so as to avoid the need to waste the whole cache on an emergency change.

      I’m in the process of looking at Google Analytics and Pingdom Tools Real User Monitoring to monitor performance worldwide. Notably, use of CloudFlare does not interfere with these analytics services, or even WordPress Jetpack Stats because they are Javascript based and rendered by the end user directly! So most people will see no problems at all.

      The local WP Super Cache is a little lacking in stats about is effectiveness, but already based on the Website Test at Pingdom Tools and, it’s making a big difference to load times – home page load times are shrinking from ~6 seconds time to first byte and ~25-30s for full loads to just 2.5s to first byte (so my host is still slow) and 9-18s for a full load (CloudFlare picking up the load for all the heavy images).

      Provided it doesn’t break anything, I think this is a pretty good result, especially considering CloudFlare is volunteering their services for free at this time (could be subject to change in the future, as we all know). I’ve also enabled the Smart Errors so if my database does go down, they should serve a recently cached version of the output, thus helping out the visitors when downtime does happen.

      – Gough

      • sparcie says:

        Wow that sounds really effective, and should improve the general experience of your site. Kinda weird it seems slower here, but that is probably local congestion.

        I’ll try again from another internet connection later to see if that helps.


        • lui_gough says:

          Thanks a tonne matey! I just remembered I enabled CloudFlare’s Rocket Loader Asynchronous Javascript acceleration (which is, incidentally in beta and known to break certain things) – disabling it seems to fix Jetpack Comments … you shouldn’t see any duplicate comment error anymore. I hope. Fingers crossed.

          Part of the reason is because the JS is probably being executed by Rocket Loader to submit the comment, which then causes it to be redirected back to the same page to refresh for the pending comment – and Rocket Loader somehow decides to re-execute the post.

          – Gough

        • lui_gough says:

          It also reminds me of something – WP Super Cache doesn’t cache pages for recent commenters – if you have the cookies identifying you as a recent commenter, then you’re actually seeing the dynamically generated page which would explain the 6+ seconds wait for the HTML for the page when Ziphosting is under load. CloudFlare will still make the images appear very snappily after the HTML comes in.

          For new visitors, and other visitors who don’t comment, they will benefit from the cache (if not expired). A quick test on (you can try this yourself) shows:
          First View -> 15.568s load time, 4.280s to first byte
          Repeat View -> 2.990s load time, 1.374s to first byte

          It seems the test shows the first view as being a cache miss and the repeat view being served the cached version of the page – hence the big difference in the time to first byte. Re-running the test merely a minute after the first test was run, but without any site changes to spoil the cache gives the following:
          First View -> 9.409s load time, 0.204s time to first byte
          Repeat View -> 1.915s load time, 0.304s time to first byte

          Improvement? Undeniable! The test was launched with their Sydney, Australia server so results will differ (especially when pages expire from cache). I’ve enabled pre-load, so once a day, all the post’s static pages are regenerated (if not expired by edits to the page or comments), which should also mean that less often accessed reference pages will appear quicker too, however, not for recent commenters (unfortunately).

          I’ve also made a change to the page rules in CloudFlare, so all files in /legacy/* which are static are cached for maximum time with maximum timeout.

          I’m learning as I go, but it’s definitely been resulting in measurable differences. Something to keep in mind if trying to serve a website from a Raspberry Pi (yeah … where it all started). CloudFlare approves –

          – Gough

          • sparcie says:

            Hmm, sounds like I might be getting slower speeds for having been logged in and using the same machines for browsing regularly.

            Although now I’m on my home desktop and it’s later in the day the speed is certainly much much better than normal, and it certainly sounds much better from the results you’ve found.

            It’s amazing how little processing power you need to run a web server. My old 50Mhz times 3 CPU SPARC can actually serve static pages up fairly quickly, although it falls over on any kind of dynamic content.


  2. sparcie says:

    In just posting that comment it took what seemed like an age to submit, and then said it had submitted a duplicate comment. Could this be related to the caching? I’ve checked and my comment did get through for moderation.


    • lui_gough says:

      It’s almost definitely due to the caching at CloudFlare’s end. It’s probably because my Ziphosting server (eugh) didn’t get back to CloudFlare fast enough, and somehow it had timed out and retried the operation somewhere along the way.

      By the way, around this time all the way through the evening, Ziphosting is normally seeing higher loads, and everything takes “an age”. We’re talking about 10 seconds from click to even a reply from the server that it had received your request. This kinda slowness breaks many CDNs, and even share features like Facebook (i.e. can’t load any description or images). The WordPress Jetpack Photon image CDN for example, has a hard coded 10s timeout …

      I hope that CloudFlare is able to handle it – at least I didn’t see a duplicate comment on this end :). Hopefully it isn’t something bigger, like Ziphosting rate-limiting requests from CloudFlare IPs … If worst comes to worst, I can always revert.

      – Gough

Error: Comment is Missing!