About Pagelet Caching Strategies
Pagelet caching is controlled both by the programmer and
by the administrator who registers the pagelet in ALI or Ensemble.
Each and every pagelet needs a tailored caching strategy to fit its
specific functionality.
A pagelet’s caching strategy should take all possibilities into
account and use the most efficient combination for its specific functionality.
A pagelet that takes too long to generate can degrade the performance
of every page that displays it. These questions can help you determine
the appropriate caching strategy:
- Will the content accessed by the pagelet change? How often?
- How time-critical is the content?
- What processes are involved in producing pagelet content? How
expensive are they in terms of server time and impact?
- Is the pagelet the only client with access to the back-end application?
- Is the content different for specific users?
- Can users share cached content?
Determine how often pagelet content must be updated, dependent
on data update frequency and business needs. Find the longest time
interval between data refreshes that will not negatively affect the
validity of the content or the business goals of the pagelet.
Since caching is indexed on the settings used by a pagelet, new
content is always requested when settings change (assuming that no
cached content exists for that combination of settings).
There are two common situations in which you might mistakenly decide
that a pagelet cannot be cached:
- In-place refresh: You might think that caching would "break"
a pagelet that uses in-place refresh because the pagelet would be
redirected to the original (cached) content. This can be avoided if
a unique setting is updated on every action that causes a redraw,
effectively "flushing" the cache. (In-place refresh renews the portlet
display by causing the browser to refresh the portal page at a set
interval.)
- Invisible preferences: If the content of the pagelet is
dependent on something other than preferences (for example,
the pagelet keys off the User ID to display a name or uses ALI security
to filter a list), caching can still be implemented with “invisible
preferences” (in this case, User ID). As with in-place refresh, invisible
preferences are set solely for the purpose of creating a different
cache entry. They are set programmatically, without the user’s knowledge.
For details on implementing caching, see the following topics:
