Welcome!

You will be redirected in 30 seconds or close now.

ColdFusion Authors: Yakov Fain, Jeremy Geelan, Maureen O'Gara, Nancy Y. Nee, Tad Anderson

Related Topics: ColdFusion

ColdFusion: 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)

    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.


    IoT & Smart Cities Stories
    Whenever a new technology hits the high points of hype, everyone starts talking about it like it will solve all their business problems. Blockchain is one of those technologies. According to Gartner's latest report on the hype cycle of emerging technologies, blockchain has just passed the peak of their hype cycle curve. If you read the news articles about it, one would think it has taken over the technology world. No disruptive technology is without its challenges and potential impediments t...
    Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
    Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
    René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
    If a machine can invent, does this mean the end of the patent system as we know it? The patent system, both in the US and Europe, allows companies to protect their inventions and helps foster innovation. However, Artificial Intelligence (AI) could be set to disrupt the patent system as we know it. This talk will examine how AI may change the patent landscape in the years to come. Furthermore, ways in which companies can best protect their AI related inventions will be examined from both a US and...
    In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
    Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (November 12-13, 2018, New York City) today announced the outline and schedule of the track. "The track has been designed in experience/degree order," said Schmarzo. "So, that folks who attend the entire track can leave the conference with some of the skills necessary to get their work done when they get back to their offices. It actually ties back to some work that I'm doing at the University of San...
    When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...
    Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...
    Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...