Quick Search for:  in language:    
will,show,Caching,feature,ColdFusion,improve,
   Code/Articles » |  Newest/Best » |  Community » |  Jobs » |  Other » |  Goto » | 
CategoriesSearch Newest CodeCoding ContestCode of the DayAsk A ProJobsUpload
ColdFusion Stats

 Code: 5,644. lines
 Jobs: 19. postings

 How to support the site

 
Sponsored by:

 
You are in:
 

Does your code think in ink?
Login





Latest Code Ticker for ColdFusion
There is currently no new code. Please check back soon.
Click here to put this ticker on your site!


Add this ticker to your desktop!


Daily Code Email
To join the 'Code of the Day' Mailing List click here!

Affiliate Sites



 
 
   

All About Caching! (VERY useful practice!)

Print
Email
 

Submitted on: 8/7/2001 1:29:33 AM
By: Jeremy McAnally  
Level: Beginner
User Rating: By 11 Users
Compatibility:Cold Fusion 4.5, Pre Cold Fusion 4.5

Users have accessed this article 8988 times.
 
(About the author)
 
     This will show you how to use the Caching feature of ColdFusion to improve server performance. Go ahead and give it a read, it never hurt anyone to implement a little caching here and there to dramtically increase performance.

 
 
Terms of Agreement:   
By using this article, you agree to the following terms...   
1) You may use this article in your own programs (and may compile it into a program and distribute it in compiled format for languages that allow it) freely and with no charge.   
2) You MAY NOT redistribute this article (for example to a web site) without written permission from the original author. Failure to do so is a violation of copyright laws.   
3) You may link to this article from another website, but ONLY if it is not wrapped in a frame. 
4) You will abide by any additional copyright restrictions which the author may have placed in the article or article's description.

Configured in the ColdFusion administrator under the "Caching" section, server caching controls how much and when data is stored in memory. An effective server caching strategy can relieve stress on resources such as databases, CPUs, and file systems while dramatically improving application performance. This article explores server caching in ColdFusion, introducing its different pieces and providing examples of how server caching works and its benefits.

Template Cache

All ColdFusion templates are compiled into PCode before execution. This compilation process can be resource intensive and slow down an application. To avoid compiling a template on every request, ColdFusion caches its PCode into memory the first time that it is called. If the cache becomes full, the cache is forced to purge templates on a first in first out basis to accommodate new requests. As a result, the next time the purged template is called, it must be recompiled. This purging is referred to as a cache pop and can be seen when monitoring CFSTAT.

If ever CP/Sec is greater than 0, Allaire recommends that the "Template Cache Size" setting be increased. By default "Template Cache Size" is set to 1024 kilobytes, but a good rule of thumb is to set the template cache size two to five times the total template size. Note that this setting is a maximum limit and is not allocated until necessary. Each template is cached only once, even if it is included in several other templates.

Trusted Cache

Though a template's PCode may be stored in the template cache, ColdFusion checks the actual file to see if it has been modified after it was cached. This check may increase I/O wait and can be avoided by turning on trusted cache, also in the ColdFusion administrator.

With trusted cache enabled, ColdFusion will only access the template cache—even if the template itself is modified. This can be problematic if developers expect to see changes when files are modified. To introduce modified templates into the cache with out restarting the ColdFusion server, disable trusted cache and make a request to each modified template. Trusted cache can then be turned back on.

Database Connection Caching

To avoid the highly expensive task of opening and closing a connection to the database for every request, ColdFusion caches database connections by default. This means that the connection to the database is only opened once for many requests, thereby dramatically improving performance.

If you are connecting to a clustered database configuration, it may be necessary to disable connection caching to allow failover to function properly. This can be accomplished by unchecking "Maintain Database Connections" in the attributes of the data source but will strongly degrade performance.

To avoid unused connections to the database remaining open for long periods of time, the "Limit cached database connection inactive time" setting can be adjusted. It is also possible to manually release all data source connections from the "Verify Data Source" section of the ColdFusion administrator.

Query Caching

Query caching greatly increases performance as result sets are retrieved from memory rather than from the database. Developers should consider caching queries whenever possible.

For example, the following query will be cached for two hours:

<CFQUERY Name="MyQuery" DataSource="dsn" CachedWithin="#CreateTimeSpan(0,2,0,0)#">
    
    
Select * from Inventory where InventoryId =2
    
    
</CFQUERY>
    
    

While caching queries is controlled by code, the limit of allowable cached queries is set in the ColdFusion administrator. With the introduction of CF 4.5x, it became possible to cache more that 100 queries at a time. The amount of queries that can be cached is now limited only by the amount of memory available on the server. As the size of result sets, amount of available memory, and the use of cached queries in applications vary, this setting should be tested under expected load for optimal performance.

Improving scalability is about finding and removing bottlenecks that restrict the growth of a system. The most common bottlenecks for Web systems include:

1.        Insufficient network bandwidth.

2.        Insufficient CPU resources.

3.        Inability to get data to/from the database.

Solving each problem seems simple:

1.        Call the ISP.

2.        Add servers.

3.        Add more database server(s).

Unfortunately, the cost of adding database server(s), both in terms of money and administrative overhead, is very high. So, it seems that maximizing your existing investment in database hardware and software is warranted. Enter query caching.

Query caching is designed to accomplish two goals:

1.        Decrease the time between a page request and the page view.

2.        Reduce the amount of work generated for the database server for each page view.

Implementing query caching is very simple. For example, examine the query below, which might be used to retrieve a list of states for a <SELECT> list.

Before:         <CFQUERY Name="qStates" DataSource="#Request.DSN#">
SELECT StateCode
FROM States
ORDER BY StateCode
</CFQUERY>

After:          <CFQUERY Name="qStates" DataSource="#Request.DSN#"
 CachedWithin="#CreateTimeSpan(0,1,0,0)#">
SELECT StateCode
FROM States
ORDER BY StateCode
</CFQUERY>

You just empowered ColdFusion to hold on to the results of that query for up to an hour. ColdFusion will now stop repeatedly asking the database for the results of this query. In fact, ColdFusion will reuse the results of that query for up to an hour before asking the database for that result set again. The database is now relieved of the duty of fetching these rows and sorting them (which usually involves creating and dropping a temporary table) for each request to that page.

Before you get too excited, there are a few details to consider:

  • There is a limit to the number of queries you can cache. This number is configured in the ColdFusion Administrator under "Caching." In ColdFusion 4.01, you cannot set this number higher than 100. This limitation was removed in ColdFusion 4.5, but that is not an invitation to set the value to 30,000. Caching too many result sets will cause memory starvation and heavy virtual memory paging, negating the benefits.
  • If you have a dynamic query, such as "SELECT * FROM Catalog WHERE CatalogNumber = #val(FORM.CatalogNumber)#", each permutation of that query counts as one cached query. Therefore, query caching should only be used for commonly accessed result sets. The CFML Language Reference defines a distinct result set by stating "…the current query must use the same SQL statement, data source, query name, user name, password, and DBTYPE. Additionally, for native drivers it must have the same DBSERVER and DBNAME (Sybase only)."
  • There is no easy way to invalidate a result set, if you detect that a result set should be invalidated. Therefore, the time span used for the result set cache should be chosen carefully. However, if you have a result set that is accessed four times per second, setting a timeout as low as a minute reduces the load on the database (for that query) by a factor of 240.
  • You cannot use query caching for parameterized queries (queries using <CFQUERYPARAM>.) Parameterized queries should be used for common non-cached queries, since they allow the query plan to be reused on some database systems (such as Oracle), and they are virtually immune to malicious query editing as documented in Allaire Security Bulletin ASB99-04 (http://www.allaire.com/handlers/index.cfm?ID=8728&Method=Full)

Keep in mind that queries are also global to the server, so if you use the same query with the same name in multiple pages, that cached result set is shared between the pages. 

The repetitive nature of Web pages often causes database servers to work very hard at producing the same results sets over and over again. However, by using the Query Caching capability included with ColdFusion, a significant amount of work can easily be moved from the database server to the ColdFusion servers. This allows for a much higher ratio of ColdFusion servers to database servers, enhances the performance and scalability of your Web system, and maximizes your investment in your database servers.

When designing a server caching strategy, it is important to take into account available sever memory and the need for fully dynamic information. If poor application performance is an issue, these settings may make a world of difference. During implementation, testing should take place to ensure that the application and server reacts as expected. Be sure to monitor server memory and verify that application data is correct.


Other 2 submission(s) by this author

 

 
Report Bad Submission
Use this form to notify us if this entry should be deleted (i.e contains no code, is a virus, etc.).
Reason:
 
Your Vote!

What do you think of this article(in the Beginner category)?
(The article with your highest vote will win this month's coding contest!)
Excellent  Good  Average  Below Average  Poor See Voting Log
 
Other User Comments
8/7/2001 1:32:27 AM:Jared Bruni
this is a very well written article you are a good writer
Keep the Planet clean! If this comment was disrespectful, please report it:
Reason:

 
8/16/2001 11:57:10 AM:Will
This article was nicely written, and it's very informative. Great work!
Keep the Planet clean! If this comment was disrespectful, please report it:
Reason:

 
3/26/2002 3:00:04 AM:veron
Very well said. The content is very useful..thanks. Well done!
Keep the Planet clean! If this comment was disrespectful, please report it:
Reason:

 
5/13/2002 10:38:04 PM:Eric Ross (*)
Interesting Article.
Keep the Planet clean! If this comment was disrespectful, please report it:
Reason:

 
4/21/2003 11:04:31 PM:
thu
Keep the Planet clean! If this comment was disrespectful, please report it:
Reason:

 
Add Your Feedback!
Note:Not only will your feedback be posted, but an email will be sent to the code's author in your name.

NOTICE: The author of this article has been kind enough to share it with you.  If you have a criticism, please state it politely or it will be deleted.

For feedback not related to this particular article, please click here.
 
Name:
Comment:

 

Categories | Articles and Tutorials | Advanced Search | Recommended Reading | Upload | Newest Code | Code of the Month | Code of the Day | All Time Hall of Fame | Coding Contest | Search for a job | Post a Job | Ask a Pro Discussion Forum | Live Chat | Feedback | Customize | ColdFusion Home | Site Home | Other Sites | About the Site | Feedback | Link to the Site | Awards | Advertising | Privacy

Copyright© 1997 by Exhedra Solutions, Inc. All Rights Reserved.  By using this site you agree to its Terms and Conditions.  Planet Source Code (tm) and the phrase "Dream It. Code It" (tm) are trademarks of Exhedra Solutions, Inc.