Cache in with LTM and iRules

Web applications are getting larger and more complex, not to mention far more heavily utilized, every day. At some point you're going to start running into resource limitations on the server(s) that are currently managing your applications, and it will be time to expand. At this point you have a couple of options. One is to start rolling out more and more servers and, likely, placing them in geographically distributed data centers to try and cater to a worldwide audience. Another, and in most cases a far more effective one in both cost and functionality, is caching. Wikipedia tells us that a cache is "a collection of data duplicating original values stored elsewhere or computed earlier, where the original data is expensive to fetch (owing to longer access time) or to compute, compared to the cost of reading the cache." That sounds pretty accurate to me, but what does that mean for you, and how would you use it?

Whether you're looking into improving performance, investigating the possibilities of a scalable cloud infrastructure, or just trying to reduce the latency to some of your users from around the world, there are few more effective tricks to pull out of your hat than caching. The basic idea is to store information that is often requested but rarely changed in a manner that prevents your webservers from having to do any processing for those requests. Perhaps you have a set of images or html pages that account for 50% of your traffic but stay generally the same. Maybe it's downloadable content like videos, PDFs, or podcasts. Sometimes it's just a portion of your site that stays the same for all users, like a navigation system or the site's skin. All of these things can be stored in a cache that will directly serve the requests whenever a user tries to access one of those items, thereby greatly reducing the workload of the servers, not to mention often dramatically improving the user experience.

It's by making use of just this kind of caching, as well as some fun iRules, that Joyent was able to scale LinkedIn's Bumpersticker app* on Facebook to over one billion requests per month. The reduction in load they saw was dramatic. Sometimes, though, simple caching isn't enough. The LTM's caching functionality is easy to configure...just set up a profile and you're off and running. If you're looking for a little more fine tuning, however, there's always iRules.

Chances are that sometimes you'll want to cache different pieces of your application for different periods of time on a single virtual. The iRule in the below example shows you how to do just that. By setting up a couple of simple switch statements that inspect the URI of the request we're able to quickly identify if this is content that gets updated more or less often and either serve the request from cache or expire that content and force the LTM to retrieve a new copy before serving it. This is a simple example of how you can use iRules to augment and extend the already powerful caching functionality of the LTM.

when CACHE_REQUEST {
  if { [CACHE::age] > 300 } {
    switch -glob [string tolower [HTTP::uri]] {
      "/fiveminutes1/*" -
      "/fiveminutes2/*" -
      "/fiveminutes3/*" {
        CACHE::expire
        log local0. "Matched 5 minutes"
      }
    }
  } elseif { [CACHE::age] > 60 } {
    switch -glob [string tolower [HTTP::uri]] {
      "/shorttimer1/*" -
      "/shorttimer2/*" -
      "/shorttimer3/*" {
        CACHE::expire
        log local0. "Matched 60 seconds"
      }
    }
  }
}

There are several other CACHE commands in iRules as well. Just looking at the list I can see a pretty clear use case for looking at the number of hits a cached item has received over a given period of time with CACHE::hits and CACHE::age and then deciding whether to stop caching that content all together with the CACHE::disable command.

Whatever your particular usage might be, whether you're thinking about scaling, trying to find more efficiency, or just trying to slay the lag beasts of the world, think about caching, LTM and iRules.

*Check out more about the Joyent/Bumpersticker story in the DC Podcast Interview we did with their CTO, Jason Hoffman.