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).”

As soon as I realized the need for a logger while developing wpSearch, I decided to check to see if one had already existed on the internet — someone had surely created a simple logging class and made it available before .. I would think. I’m a believer in the C programmer’s motto “build upon the work of others”, so checking to see if someone else has done the same thing prior to starting a project comes naturally.

After a little browsing, I couldn’t find what I was looking for. Put plainly, I wanted a logging class that:

• Checked permissions prior to logging
• Had a priority heirarchy built in ( Debug, Info, Error, and Fatal Message Levels)
• Logged to plain old text files
• Managed file handling cleanly (Open the file once, close the file once)
• Managed resources (make sure the file gets closed)

Not too complicated. This logging class would require around 100 lines of code.

Another option involved using logging functions available in Zend, or the logging class provided in PEAR. These libraries were a little overkill for what I needed, so I passed.

I decided to write of the class myself, and it has turned out to be pretty handy. I figured someone else would probably find it useful as well, so I have posted it on it’s own project page. Click here to go to the KLogger project page.

Using KLogger is very straight-forward. Here’s an example:

require_once 'KLogger.php';
...
$log = new KLogger ( "log.txt" , KLogger::DEBUG );
 
// Do database work that throws an exception
$log->LogError("An exception was thrown in ThisFunction()");
 
// Print out some information
$log->LogInfo("Internal Query Time: $time_ms milliseconds");
 
// Print out the value of some variables
$log->LogDebug("User Count: $User_Count");

Depending on the priority level that is used when instantiating a new KLogger, only certain messages are actually logged to the file. If the most verbose priority level is used, ( KLogger::DEBUG ), all messages are logged. If the least verbose level is used ( KLogger::FATAL ), only Fatal-level errors are logged. Here’s a breakdown of the most verbose level to the least-verbose level:

• Debug (Most Verbose)
• Info …
• Warn …
• Error …
• Fatal (Least Verbose)

A sixth level is also available: KLogger::OFF, so if you need to release a site without logging, you can simply set the priority level to Off, and not have a single message logged. (In fact, a log file will never be opened).

There isn’t too much documentation on the class right now, but it shouldn’t be too hard to figure out.

A couple comments on design: A few log class examples I’ve seen implement a singleton pattern, essentially locking the programmer into using one logger at all times. I usually lean towards letting the developer decide those things: If he wants to use a single logger, he can create a global log object in his application.

An screenshot of KLogger:

I think at this point I’ve actually done a better job describing KLogger in this post than on the project page. A few more details are listed there, along with the download. If you find it useful, leave a comment and let me know.

Click here to go to the KLogger project page.