This post will discuss what caching is, and how it is used in CodeIgniter. The next post will provide a few helper methods for clearing caches for specific pages (or really, URIs). I think this will make CI’s caching feature a lot more usable.

In a nutshell, this is how (and why) output caching is typically implemented:

Suppose we have a page at http://mysite.com/stats/website which loads and shows all the statistics about the users on my site, activity, files posted, etc. In other words, a lot of SQL queries (maybe 40 or so) and calculations go into this page. That takes significant time and resources.

Now imagine that this page is particularly popular. Maybe a heavily-read blog or bookmarking service links to your website, and you receive an unexpected burst in traffic. All of those page loads are re-running your calculations and queries, and that is consuming serious memory and CPU cycles. The number of requests your website can serve per-minute is now falling through the floor!

The idea of caching involves using the fact that our page probably doesn’t need calculate those statistics or run those queries every time. Perhaps gathering all of that data once an hour would suffice.

“Caching” involves generating the statistics page like we normally would, but saving a copy of the output we were going to send to the user for a certain amount of time. During that time period, everyone who requests that page will get the same page output that we generated x minutes ago.

After that time period passes, and we receive another page request, we recalculate the stats, and send them to the user. Of course, we’ll save the newer stats for a given amount of time for subsequent requests.

This basic caching — “page caching” — is the kind that CodeIgniter offers.

When you are inside a controller, you can tell CodeIgniter that you want to cache any requests to the current URI for n minutes. For that time period, you only want to send the output your are about to generate.

This is how it looks:

class Stats extends Controller
{
  function website()
  {
    // 40 SQL Queries (Maybe a little overboard)
    // Serious, ultra-precise calculations
    // More intensive code that isn't good for fast page loads
 
    // Tell CI you want to cache the output of this page for 10 minutes.
    // This means that for the next 10 minutes, when CodeIgniter receives
    // a request for stats/website, the CI system will not even consult this
    // method or instantiate this controller. It will serve a static page containing
    // the exact content that you output here.
    $this->output->cache(10);
 
    $this->load->view('stats/website', $data);
  }
}

And that’s all you have to do! In this example, CodeIgniter’s output caching works great.

So then, what were the qualms I mentioned earlier?

Suppose we also cache user profile pages, which might be located at a URI similar to http://mysite.com/users/profile/kennyk. For whatever reason, we will assume that caching this page could be very beneficial due to heavy traffic on the site.

If a user profile is cached for 10 minutes, and a user updates his profile in some profile editing area, he will still see the older version of his profile page when he tries to view it. This can be confusing and inconvenient.

Other MVC frameworks (like Rails) handle this issue in a snap by allowing the developer to “sweep” caches at will. CodeIgniter does not offer any functionality similar to this.

My next post will document a cache helper I’ve whipped up to allow CodeIgniter to sweep caches for a given URI. Look out for “Flushing CodeIgniter’s URI-based Cache (Part II).”

$this->output->enable_profiler(true);

In your controller before you load a view, CodeIgniter will give you information regarding how fast the page loaded, how many SQL queries executed, the content of each query, and the running time of each query. This is incredibly useful when you are trying to debug your application, or simply see how quickly things are loading.

There’s only one problem: To enable profiling, that line of code above must be present. What if you want to profile several pages, or even your whole web application? In that case, you have to start thinking:

• I could put that line in the constructor of my controller, and then of of that controller’s methods will be profiled.
• I could put that line in each method I want to profile.

These methods start to get ugly. And of course, you don’t want to comment out each profiling line when you don’t need them.

My method to tackle this problem involves using CodeIgniter’s Hooks feature to enable or disable profiling for the entire web applications based on a value in the configuration file. In the end, I can turn on profiling for my entire website via a config value by setting it to true or false. This is my method:

1. Enable hooks in your CodeIgniter Application by going to config/config.php end setting the flag to true:

$config['enable_hooks'] = TRUE;

2. Create a file in the config directory named hooks.php if it does not already exist. Inside it, place:

$hook['post_controller_constructor'][] = array(
                                'class'    => 'ProfilerEnabler',
                                'function' => 'EnableProfiler',
                                'filename' => 'hooks.classes.php',
                                'filepath' => 'hooks',
                                'params'   => array()
                                );

3. Create a folder in your application directory named hooks (If it does not already exist). Inside it, create a file named hooks.classes.php. Inside it, put:

class ProfilerEnabler
{
	function EnableProfiler()
	{
		$CI = &get_instance();
		$CI->output->enable_profiler( config_item('enable_profiling') );
	}
}

4. Finally, add this line to your application’s main configuration file:

$config['enable_profiling'] = false;

Setting this value to true will enable profiling across your entire website. Now, you can zip through pages, checking the load times of each without any trouble!

Note: I’ve always thought that an additional way to do this would be to extend the Controller class and enable profiling from there. But this method, I think, has the least impact on existing code.