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.
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.
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.
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.
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.
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.
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 greatly increases performance as result sets
are retrieved from memory rather than from the database. Developers should
consider caching queries whenever possible.
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
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.
scalability is about finding and removing bottlenecks that restrict the growth
of a system. The most common bottlenecks for Web systems include:
Insufficient network bandwidth.
Insufficient CPU resources.
Inability to get data to/from the database.
each problem seems simple:
Call the ISP.
Add more database server(s).
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.
caching is designed to accomplish two goals:
Decrease the time between a page request and the page view.
Reduce the amount of work generated for the database server
for each page view.
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.
<CFQUERY Name="qStates" DataSource="#Request.DSN#">
ORDER BY StateCode
ORDER BY StateCode
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.
you get too excited, there are a few details to consider: