Marketing cache design considerations

When you are designing the marketing caching for your site and stores, there are many options, enhancements, and best practices to consider for improving marketing performance.

Before you design the marketing caching for your site, ensure that you are familiar with what can be cached, and how caching can improve your marketing activities. Within your site you can cache e-Marketing Spot JSP snippets, as well as entire JSP files. These objects can be cached within the following marketing-specific caches:
  • Marketing Business Objects Cache
  • Marketing User Behavior Cache
  • WCMarketingDistributeMapCache
  • DynaCache Marketing Command Cache

For more information about improving marketing performance with caching, see Improving marketing performance with caching.

Marketing business object cache (DM_Cache)

The DM_Cache is used by WebSphere Commerce to cache all information that is related to an activity definition. The stored information includes the following activity information:
  • The activity
  • The element information includes implementation, behavior, and related rules
  • Which activities are scheduled to an e-Marketing Spot
  • The default content that is assigned to an e-Marketing Spot
  • The ordering scheme that is assigned to an e-Marketing Spot
The default size for this cache is 2500 entries. You can increase this cache size to meet your site requirements. As a best practice for your site, ensure that the size of this cache matches your site requirements. If your site has more than 500 active activities, increase this cache size. When you are determining the required size of this cache for your site, assume that your store is recording five entries for each active Web activity. For more information about caching business objects, see marketing business object cache overview.

WebSphere Commerce Version 7.0.0.2As another best practice, ensure that your site is updated to WebSphere Commerce Version 7 Fix Pack 2. With this fix pack, this cache can offload entries to disk to reclaim memory and improve performance. This cache is not capable of offloading entries to disk if WebSphere Commerce Fix Pack 2 is not installed.

Marketing user behavior cache (DM_UserCache)

DM_UserCache caches the current user behavior information for shoppers. This information is a cached version of the online behavior for shoppers that is recorded in the database. The recorded online behavior includes experiment paths, categories that are browsed, products that are browsed, search terms that are used, URLs matched, and non-repeatable activities. As a best practice for your store, assess the required size of this cache for your site and if needed, change the cache size. If your store encounters high volumes of traffic, increase the size of the cache. The default size of this cache is 10000 entries. For more information about caching user behavior, see the MarketingUserCache section in Marketing business object cache overview.

As another best practice, ensure that your WebSphere Commerce instance is updated to the Fix Pack 2 level. If WebSphere Commerce Version 7 Fix Pack 2 is installed, your site can enable this cache to offload entries to disk to reclaim memory and improve performance. This cache is not capable of offloading entries to disk if WebSphere Commerce Fix Pack 2 is not installed.

Marketing services - user behavior

Your site can use marketing services to temporarily store user behavior information updates. Any change to user behavior information is first recorded in memory and then periodically persisted in a batch to the database. You can modify the batch size by setting your changes in the marketing component configuration file, wc-admin-component.xml. For more information about recording data, see data recording: improving runtime performance. As a best practice, use the default settings, which include a default batch size of 200.

Marketing services - marketing statistics

Your site can also use marketing services to temporarily store marketing statistics. The gathered statistics are initially recorded in memory and then periodically persisted to the database with the SaveMarketingStatistics scheduled job. For more information about changing the frequency of the SaveMarketingStatistics scheduled job, see marketing statistics for Management Center. As a best practice, use the default settings for the SaveMarketingStatistics scheduled job.

If you are not using the marketing statistics, you can disable the collecting of these statistics. For more information, see Disabling marketing statistics

DynaCache marketing command cache

The DynaCache marketing command cache caches data that displays in e-Marketing Spots. This data includes catalog entries, categories, and store content information. The command cache cachespec can be used to cache queries that retrieve information from the database to display in the storefront e-Marketing Spots. As a best practice for your store, add the sample cachespec entries to the cachespec for your store. For more information about marketing command caching, see command caching for marketing.

Caching catalog hierarchy queries (WCMarketingDistributedMapCache)

Your site can use the WCMarketingDistributedMapCache cache to store information about catalog hierarchies. Many marketing activity targets and actions rely on determining whether a catalog entry belongs to a particular category. To determine the parent hierarchy for a catalog entry or category, database queries must retrieve the parent category information from the database. To reduce the load on your database, you can enable the WCMarketingDistributedMapCache cache to cache catalog hierarchy information. Enabling the caching of catalog hierarchy queries can improve the performance of the following campaign elements that use catalog hierarchy queries:
  • Shopping Cart Target
  • Purchase History Target
  • Catalog Browsing Behavior, Current Page (for catalog browsing behavior)
  • Merchandising Association Action
  • Top Browsed Action
  • Best Sellers Action
If your store uses any of these targets or actions, enable this cache as a best practice for your store. For more information about enabling the WCMarketingDistributedMapCache data cache, see WebSphere Commerce data cache.

Marketing (CampaignInitiativeCache) registry

The Marketing CampaingInitiativeCache registry keeps a mapping of an e-Marketing Spot name to the e-Marketing Spot primary key. This registry contains entries for e-Marketing Spots that are defined in the database and not defined in the database but that are still included on store pages. If your site fully caches e-Marketing Spot JSPs this registry provides no reuse. For this registry, each e-Marketing Spot is called only once and then the store JSP is cached. If your site fully caches e-Marketing Spot JSPs, you can disable this registry to prevent the memory usage of this registry for storing unnecessary cache entries.
WebSphere Commerce Version 7.0.0.2Note: If you want to change the registry size or offload your entries to disk, you must upgrade your WebSphere Commerce instance level to WebSphere Commerce Version 7 Fix Pack 2. With this Fix Pack, entries are moved to the DM_Cache and you can offload these entries to disk. As a best practice for managing this registry, install WebSphere Commerce Version 7 Fix Pack 2. The transfer of entries to DM_Cache and the option of offloading entries to disk provides improved management options of this marketing registry.
Feature Pack 3Feature Pack 2WebSphere Commerce Version 7.0.0.0Feature Pack 4Feature Pack 1

Data propagation with the stagingprop utility

When the marketing data for your store is pushed to your production server, the marketing cached data must be cleared. Clearing this data is accomplished by clearing the CampaignInitiativeCache marketing registry. You can use an automated method of clearing this registry. You can enable database triggers on the production server to detect changes in the marketing data. When the triggers run, they insert an entry into the CACHEIVL database table that calls the DynacacheInvalidation scheduled job to clear the marketing registry. When the registry is cleared, the job then clears the marketing distributed maps. The job also issues an invalidation command for dialogMarketingJsp and dialogMarketingCommand. You can use these strings as dependency IDs so cached e-Marketing JSPs can be invalidated whenever the marketing information changes.

WebSphere Commerce Version 7.0.0.1

DynaCache marketing JSP fragment cache

There are some options to consider when you are designing your store pages in order to achieve optimal performance for your e-Marketing Spots. Querying the database to retrieve object information to load full objects for display in an e-Marketing Spot can impact resource usage. Your store e-Marketing Spots do not need to load full catalog entries, categories, or content from the database or command cache. You can configure your store e-Marketing Spots to return only ID information for catalog entries, categories, and store content. Returning only this information reduces the impact of queries for e-Marketing Spot evaluation. The Marketing Service can also cache this returned ID information so that it can be reused.

By returning only ID information, the client JSP needs to render only the catalog entry, category, or content with databeans or web services. The JSP fragment for the rendered catalog entry, category, or content is then cached for reuse. This process is the recommended technique for handling catalog entries, and is supported for categories and store content. If your store JSPs require more information to generate the HTML and javascript to display an object than is returning in the CatalogEntry SDO use this caching technique as a best practice for your store.

You can use this caching technique to return only the catalog entry ID and to cache the catalog entry display fragment to improve performance. With WebSphere Commerce Version 7 Fix Pack 1, the Madisons sample store uses this caching technique by default.

If your site uses this caching technique, the following code snippets provide caching options to help manage your storefront performance:
  • The ScrollingProductsESpot.jsp file contains code that specifies that marketing services are to return product IDs. This configuration is enabled by setting the following parameter in the <getData> tag in the Get MarketingSpotData service call. The code for specifying the return of product IDs resembles the following code:
    <%-- do not retrieve the catalog entry SDO but obtain the catalog entry Id only --%>
    <wcf:param name="DM_ReturnCatalogEntryId" value="true" />
  • The ScrollingProductsESpot.jsp file also contains code that specifies that the objects to be returned are CatalogEntryId objects instead of the CatalogEntry objects. The code to specify the return of the CatalogEntryId objects resembles the following code:
    <c:if test='${marketingSpotData.dataType eq "CatalogEntryId"}'>
  • For each product that displays in your store, your store is using a JSP fragment to display the product. These JSP fragments resemble the following code:
    <c:import url="${jspStoreDir}Snippets/Catalog/CatalogEntryDisplay/CatalogEntryThumbnailDisplay.jsp">
  • You can cache the product display JSP fragment. To cache this fragment change the cache settings in the cachespec.xml file. This file is in samples\dynacache\Madisons directory. The cache entry settings for setting the product display JSP fragment to be cached resembles the following code:
    <cache-entry>
     <class>servlet</class>
    
     <name>/Madisons/Snippets/Catalog/CatalogEntryDisplay/CatalogEntryThumbnailDisplay.jsp</name>
     <property name="do-not-consume">true</property>
     <property name="save-attributes">false</property>
    
     <cache-id>
      <component id="emsName" type="parameter">
       <required>true</required>
      </component>
      <component id="catalogId" type="parameter">
       <required>true</required>
      </component>
      <component id="DC_storeId" type="attribute">
       <required>true</required>
      </component>
      <component id="DC_lang" type="attribute">
       <required>true</required>
      </component>
      <component id="DC_curr" type="attribute">
       <required>true</required>
      </component>
      <component id="DC_cont" type="attribute">
       <required>true</required>
      </component>
      <component id="DC_mg" type="attribute">
       <required>true</required>
      </component>
      <component id="intv_id" type="parameter">
       <required>true</required>
      </component>
      <component id="experimentId" type="parameter">
       <required>false</required>
      </component>
      <component id="testElementId" type="parameter">
       <required>false</required>
      </component>
      <component id="catEntryIdentifier" type="parameter">
       <required>true</required>
      </component>
     </cache-id>
     
     <dependency-id>storeId:productId
      <component id="storeId" type="parameter">
       <required>true</required>
      </component>
      <component id="catEntryIdentifier" type="parameter">
       <required>true</required>
      </component>
     </dependency-id>
     <dependency-id>productId
      <component id="catEntryIdentifier" type="parameter">
       <required>true</required>
      </component>  
     </dependency-id>
     <dependency-id>activityId
      <component id="intv_id" type="parameter">
       <required>true</required>
      </component>
     </dependency-id>
    </cache-entry>