Page 298 - DCAP408_WEB_PROGRAMMING

Web Programming

Notes your content as opposed to going dynamically through the process of generating the content.
Unfortunately, this incredible speed-up is only available to stateless pages where all visitors are
treated the same. Content management systems – including weblogs and wikis – have many
pages that are a great fit for this approach, but account-based systems where people log in and
manipulate their own data are often less likely candidates.
Specifying which actions to cache is done through the caches_page class method:
class WeblogController < ActionController::Base
caches_page :show, :new
end
This will generate cache files such as weblog/show/5.html and weblog/new.html, which match
the URLs used to trigger the dynamic generation. This is how the web server is able pick up a
cache file when it exists and otherwise let the request pass on to Action Pack to generate it.
Expiration of the cache is handled by deleting the cached file, which results in a lazy regeneration
approach where the cache is not restored before another hit is made against it. The API for doing
so mimics the options from url_for and friends:
class WeblogController < ActionController::Base
def update
List.update(params[:list][:id], params[:list])
expire_page :action => “show”, :id => params[:list][:id]
redirect_to :action => “show”, :id => params[:list][:id]
end
end

Notes Additionally, you can expire caches using Sweepers that act on changes in the
model to determine when a cache is supposed to be expired.

13.5.3 Data Caching

Data retrieving from a repository can be quite a “heavy” task from a performance point of view,
especially when the data repository is located far from the application server (e.g., web service
call, RPC call, Remoting, etc.) or some specific data is accessed very often. So, in order to reduce
the workload and time for data retrieving, you can use a caching functionality.
There are some rules that you should be aware of:
1. Use caching of data for a small period of time and avoid caching for the whole application
lifecycle.
2. Try to cache the data that is likely to not be changed very often (e.g., dictionary elements).
3. Some data repositories can support notification events if the data is modified outside of
the application (e.g., the data is just stored in a file).
Besides the obvious goals, data caching has some pitfalls (all of them are about potential situations
when cached data can expire and application uses inconsistent data):
1. If the application is going to be scaled to a distributed environment (web farm, application
cluster), then every machine will have its own copy of cached data. So, one of the machines
can modify the data at any time.
2. Several applications can access the same data repository.

292 LOVELY PROFESSIONAL UNIVERSITY