Microsoft Developer News and Blog Entries

Microsoft Developer

Subscribe to Microsoft Developer: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Microsoft Developer: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Microsoft Developer Authors: Josh Litvin, Stackify Blog, Automic Blog, Jnan Dash, Srinivasan Sundara Rajan

Related Topics: ColdFusion on Ulitzer

CFDJ: Article

Caching in on Performance

Caching in on Performance

There's nothing that can kill your application's performance as quickly as database access. This is a shame, considering that almost every ColdFusion application you'll ever write will incorporate some sort of database integration.

It thus follows that an important part of optimizing an application's performance is reducing its database activity. And no, this doesn't necessarily mean stripping out database access. The trick is to reduce the amount of database activity that your application generates. This is where caching comes in.

Note: In this column we'll be looking at database caching only. ColdFusion also features page and p-code caching, but those subjects require columns unto themselves.

Understanding Caching
Caching is not a new concept, nor is it unique to ColdFusion. The basic principle behind caching is that data that resides in memory can be accessed very quickly - orders-of-magnitude times faster than reading the same data from disk. The hard drive - any hard drive - is still one of the slowest components in a computer. Memory access, on the other hand, is one of the fastest operations a computer can perform.

Caching involves keeping a copy of recent data in memory so that subsequent requests for that data may be fulfilled by accessing the memory-resident copy rather than the original data on the disk.

Many programs feature caching. Most database servers support caching to improve database access time; Internet browsers cache recently used graphics to improve page download time; even operating systems can cache file system access (does anyone remember the DOS FASTDRIV utility?).

ColdFusion Database Caching
So what does all this have to do with ColdFusion? Well, aside from being able to take advantage of the operating system and database server caching (as any other application would do), ColdFusion features application-level caching that you can use within your own development efforts.

Where would you use caching within your applications? Here are some examples:

  • Almost every form that prompts for an address displays a list of states. Those states should never be hard-coded (even though there's no fifty-first state scheduled to join the U.S. at this time); instead, state lists should be populated by a query against a states table. But as that states list doesn't change often (it's 40 years since Hawaii came on board), reading it from the database every time it's needed is a waste of database resources. The states list is thus a primary candidate for caching.
  • Employee lists are another good example. While it's true that employee lists can change frequently, it's doubtful that they change so often that they have to be read from the database each time they're needed (if they do, do yourself a favor: find a new employer, and quickly). Caching employee lists for a few hours will reduce database activity, and the only penalty is that personnel changes won't be immediately reflected in your lists.

    Even though frequently retrieved data is likely cached by the database server itself, retrieving the data again is obviously more resource intensive than not requesting it at all. Furthermore, as ColdFusion usually isn't running on the same box as the database server, eliminating unnecessary database requests can also reduce network traffic between the two machines, which in turn further eliminates potential performance bottlenecks.

    This is where ColdFusion-based data caching comes in. ColdFusion supports two forms of caching: variable-based caching and query-based caching. We'll take a look at both.

    Variable-Based Caching
    Variable-based caching is a simple concept, and has been supported by ColdFusion since version 3. Most ColdFusion variables persist while a page is being processed and are automatically destroyed as soon as page processing is complete. But ColdFusion features several special variable types that are designed to persist even after a page has finished processing. Table 1 lists some of them.

    Usually, persistent variables are used to store simple data. For example, if you wanted to count how many requests were made to a specific page since ColdFusion was started, you could use the following code:

    <CFIF NOT IsDefined("SERVER.pagecount")>
    <CFSET SERVER.pagecount=0>
    </CFIF>
    <CFSET SERVER.pagecount=SERVER.pagecount+1>

    The first three lines of this code block ensure that the SERVER variable exists. The inner <CFSET> statement will be processed only once, the very first time the code is executed. After that, the IsDefined() test will always return FALSE because SERVER variables persist until ColdFusion is restarted. The final line of code increments the variable by 1, and will be excepted every time the page is requested.

    So what does this have to do with query caching? Well, it's simple, really. ColdFusion allows you to save query results to persistent variables. Look at the following code example:

    <CFIF NOT IsDefined("APPLICATION.states")>
    <CFQUERY NAME="APPLICATION.states" DATASOURCE="datasource">
    SELECT * FROM states ORDER BY name
    </CFQUERY>
    </CFIF>

    This code checks to see whether an APPLICATION variable named "states" exists. If it doesn't, a <CFQUERY> is executed, and the query is saved to APPLICATION.states. If this code were processed again before the variable timed out, the query wouldn't be executed because it already existed. Once the variable timed out (at the interval specified in the ColdFusion Administrator or in the <CFAPPLICATION> tag), the query would be processed again and the variable would be restored.

    The only catch here is that any references to the query must include the specifier APPLICATION. To use the results in a <CFOUTPUT> you'd have to do this:

    <CFOUTPUT QUERY=
    "APPLICATION.states">

    The choice of which variable type to use is yours, although you'll probably find that SERVER and APPLICATION variables are the ones you want for most applications.

    Because of how variable-based query caching works, the best place to execute (and cache) your queries is in the APPLICATION.CFM file. This way, the first time the application is used all the queries are cached ready for use. On subsequent page requests the cached copies will be used automatically.

    Query-Based Caching
    Query-based caching is a little different, and is new to ColdFusion 4.0. Unlike variable-based caching, query-based caching occurs right within the <CFQUERY> tag. It is supported by two new <CFQUERY> attributes, as listed in Table 2.

    To demonstrate this, let's take a look at the same states list example:

    <CFQUERY NAME="states"
    DATASOURCE=
    "datasource"CACHED
    WITHIN=CreateTime
    Span(0,0,30,0)>
    SELECT * FROM states
    ORDER BY name
    </CFQUERY>

    In this code example the CACHEDWITHIN attribute is specified using the CreateTimeSpan() function; here an interval of 30 minutes is specified. When the code is executed, ColdFusion will cache the results if it can do so (if the maximum number of allowed cached queries hasn't been reached). No indication about whether or not the results were cached is given, and unlike variable-based caching you need do nothing special to use the query.

    The following code will work whether or not the data has been cached:

    <CFOUTPUT QUERY="states">

    Upon subsequent requests to the page, you may determine whether cached data was used by looking at the debug output at the bottom of the page (if debugging is turned on). Instead of seeing output that looks like this:

    states (Records=50, Time=40ms)

    you'd see output like this:

    states (Records=50, Time=Cached Query)

    The cache will be used until the specified interval is reached, at which time the data will be reread from the database. Once it has been reread, it will once again be cached if ColdFusion can do so.

    It's important to note that unlike variable-based caching, query caching is well suited for dynamic SQL. When the ColdFusion caching engine processes the SQL, it looks at any dynamic statements and even user login information and determines whether the query is the same as one already cached. This means that a query that is built using conditional logic (perhaps statements appending FORM fields) can be cached safely and properly.

    Variable-Based Caching vs Query-Based Caching
    So which caching mechanism is right for you? Well, the answer is both - it really depends on what you're trying to do. Table 3 lists important points about each cache type.

    To help you determine which option will work best for you, consider the following:

  • The states list doesn't need to time out, and should be shared by all applications and users (it's highly doubtful that you'd display a different list of states for different users or applications). As such, it's probably best cached as a SERVER or APPLICATION variable.
  • "Next n of n style" interfaces are used to allow users to browse through subsets of query results one screen at a time. The way these interfaces are designed usually forces ColdFusion to reread the entire result set each time a subset is needed. As these interfaces are usually driven by user search criteria and need to persist for a limited time (while the user views search results), they are perfect candidates for query-based caching.
  • User-specific queries (those containing user-specific information) should be cached using SESSION or CLIENT variables.
  • Highly dynamic queries usually benefit least from query caching; not all queries should be cached.
  • If you want to ensure that a query has been cached, don't use query-based caching.
  • Any data that must always be 100% current should not be cached.

    The Fine Print
    I have one warning to give you before you run off to cache every query in your application: cached queries can chew up lots of precious memory, and you can't control how much they'll chew up.

    ColdFusion lets you specify a maximum number of queries to be cached using query caching, but not a maximum size (in theory, you could cache a hundred queries each of thousands of megabytes of data - I say in theory because in practice that would kill your server before you finished caching them all). For this reason, query caching can be disabled altogether in the ColdFusion Administrator.

    Variable-based caching can't really be turned off. While the use of specific data types (e.g., CLIENT) may be prevented, others (e.g., SERVER) cannot. Nor is there a way to restrict how many variables may be created (or the size of their contents). The bottom line is that while caching can improve performance, abusing caching can do exactly the opposite.

    Conclusion
    In my experience, 99 out of 100 ColdFusion performance problems are directly related to database access. While not a substitute for good relational database design, appropriate database hardware and efficient SQL, query caching can dramatically improve application performance and response time when used properly.

    Considering that almost every ColdFusion application you'll ever write will incorporate some sort of database integration, that's a very good thing indeed.

  • More Stories By Ben Forta

    Ben Forta is Adobe's Senior Technical Evangelist. In that capacity he spends a considerable amount of time talking and writing about Adobe products (with an emphasis on ColdFusion and Flex), and providing feedback to help shape the future direction of the products. By the way, if you are not yet a ColdFusion user, you should be. It is an incredible product, and is truly deserving of all the praise it has been receiving. In a prior life he was a ColdFusion customer (he wrote one of the first large high visibility web sites using the product) and was so impressed he ended up working for the company that created it (Allaire). Ben is also the author of books on ColdFusion, SQL, Windows 2000, JSP, WAP, Regular Expressions, and more. Before joining Adobe (well, Allaire actually, and then Macromedia and Allaire merged, and then Adobe bought Macromedia) he helped found a company called Car.com which provides automotive services (buy a car, sell a car, etc) over the Web. Car.com (including Stoneage) is one of the largest automotive web sites out there, was written entirely in ColdFusion, and is now owned by Auto-By-Tel.

    Comments (1) View Comments

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    Most Recent Comments
    jay 04/30/02 04:29:00 PM EDT

    good article