• Dealing with Slow modules and Caching

    One thing I often come across is sites that load slowly due to a single module needing to load data from an external source. Caching helps with this considerably, at least until the cache expires.

    As a prime example, let's use a Twitter module. To load the feed data, the module needs to access Twitter's API. This happens when the page request is received by the hosting server, and one of two things will then happen. If the cache data exists and is still valid (i.e. hasn't expired) the page will load lightning fast.

    Unfortunately, if the cache has expired, or just doesn't exist, the module will need to access Twitter's API. Occasionally the API runs slowly and so the user has to wait for your homepage (or whichever page the module is on) to load. This provides the user with a bad experience, made worse if the module doesn't actually form part of the core content that the user is (im)patiently trying to view.

    This documentation details a quick and easy way to resolve this issue.

  • Finding the cause of high CPU utilisation on Linux

    We've all had it happen from time to time, suddenly sites on a server we manage appear to have slowed to a crawl. Having logged in you take a look at the running processes to find the cause. 9 times out of 10 it's something like a backup routine overrunning, so you kill the task and everything's OK again.

    What do we do, though, if that's not the cause. It can sometimes be difficult to narrow down exactly what's causing it if the process list shows everything's currently OK. The slowdown may only kick in for a few seconds, but the perfectionist in us still needs to know what the cause is so we can mitigate it (if it's a particular page on a particular site, what happens if it suddenly gets a lot of hits?)

    This documentation details ways to monitor usage without needing to spend all day looking at top. The main aim being to try and identify which process is responsible to then dig a little further.

     

  • Joomla and NGinx Reverse Proxy Caching: Keeping your dynamic content fresh

    We've placed a caching NGinx reverse proxy in front of our Joomla site, but haven't yet addressed the issue of the content that we do want to remain dynamic. We might, for example, have a module such as mod_GoogPlusFeed embedded on a number of pages, but with the configuration we've used so far, this won't update until the cached copy has expired.

    In this guide, we're going to walk through the few easy steps to ensure the content is regularly updated - without undermining what we were originally trying to achieve - fast response times.

    The primary basis of what we're going to do is very similar to Dealing with Slow modules and Caching, so much so that some of the set up is the same

  • Joomla Performance Tweaks for Busy Websites

    Joomla! now runs a fair proportion of websites, and it's interface obviously appeals to a great many users (over 30 million downloads as of April 2012). For big busy sites, however, the performance isn't always as good as it could be. It's not bad, by any means, but can certainly be improved upon.

    To clarify: by busy, I mean numerous visitors all hitting at more or less exactly the same time.

    Aimed at developers and owners of large Joomla sites, the tweaks in this documentation will help you improve the performance of your site. However, it should be considered advice, and not a step-by-step instructional, if your site is that busy, the database tweaks in particular may actually hinder performance slightly.

    If visitors are reporting long load times, especially during busy periods, then these tweaks may be of use to you.

  • NGinx and Apache with Joomla!

    I recently published a guide to configuring NGinx as a reverse proxy to Apache on CentOS. It works well with Joomla! 2.5 and 3.x but doesn't always play quite so nicely with Joomla! 1.5.

    Having had to configure a system today, I thought I'd document what I had to do differently.