Dyna caching in WCS

Caching improves response time and reduces system load to improve the performance of world-wide web applications.
The Dyna caching service includes:-
ü  Servlet or JSP result cache, caching the fragments of JSP or whole page.
ü  Command cache to cache business objects.
ü  Edge Side Include (ESI) caching to cache, assemble and deliver the dynamic web pages at the edge of enterprise network.
ü  Invalidation support to ensure that the content of cache is correct. Invalidation can be rule-based, time-based, group-based and programmatic.
ü  Replication support, to enable cache sharing and replication on multiple servers.
ü  Disk offload capability, to enable and storing large amount of data, preserve the content in the application server until it is restarted or stopped.
The caching specific behaviour of the WCS is specified in the cachespec.xml present in the Stores.war.
Dyna caching service, places the objects in the cache which is identified by unique cache-id’s (<cache-id> rules) defined in the <cache-entry> elements.
Once the objects with particular cache-id are in the cache, then the subsequent request for the same cache-id is served from the cache.
Cached objects are removed from the cache according to the information provided in the <cache-entry> elements such as <time-out><invalidation> and<priority> elements.
When the available cache memory is full, LRU algorithm removes the cached objects with the lower priority.
The <dependency-id> and <invalidation> elements defines the rule to generate dependency-id’s and the invalidation-id’s, which together specifies certain objects should be removed from the cache after the request is processed.
The <inactivity> element is used to specify a time to live (TTL) value for the cache entry based on the last time that the cache entry was accessed.
Caching strategy
When determining a caching strategy for WebSphere Commerce, the key issues that need to be resolved are:
Ø  Which pages should be cached
Ø  Where caching should take place
Ø  Cache full pages or page fragments
Ø  How to invalidate the cached data.
When determining which Web pages should be cached, good candidates for caching are pages that:
Ø  Are accessed frequently
Ø  Are stable for a period of time
Ø  Contain a majority of contents that can be reused by a variety of users

The following <cache-entry> example uses a <cache-id> element to cache results created by a JSP and generate a cache ID with two components, "storeId" and "catalogId", obtained from parameters in the request object:
<cache-entry>
 <class>servlet</class>
 <name>/ToolTech/. . ./StoreCatalogDisplay.jsp</name>
 <property name="save-attributes">false</property>
 <property name="store-cookies">false</property>
 <timeout>3600</timeout>
 <priority>3</priority>
 <cache-id>
  <component id="storeId" type="parameter">
   <required>true</required>
  </component>
  <component id="catalogId" type="parameter">
   <required>true</required>
  </component>
 </cache-id>
...
</cache-entry>

Comments

Popular posts from this blog

Dataload Utility In WCS

10 Steps to Configure Email – Websphere Commerce Server

Multiple Wish List