Promotion evaluation considerations

When we are designing promotions for the site, consider how your promotions are being evaluated. How you design your promotions and configure your promotion evaluation process can affect the site performance during promotion evaluation. When we are creating promotions, consider the promotion type, the promotion conditions, the size of orders that are evaluated, and the agenda builder used for promotion evaluation.

• Promotion types and conditions

• Promotion engine configuration

• Promotion agenda builders

• Number of products in an order

• Catalog structure

• Number of customer segments and conditions

Promotion types and conditions

When creating promotions in Management Center, certain promotion types and conditions can affect the store performance. For more information about the effect of certain promotion types on the store performance, see promotion types and conditions considerations.

Promotion engine configuration

We can configure the settings of the promotion engine to improve the performance of promotion evaluation. We can make the following changes by adjusting the settings in the promotion engine configuration:

• Disable the engine debug trace by setting <Debug>false</Debug>. Instead of using the engine debug tracing, we can use WebSphere Application Server tracing. For more information about the WebSphere Application Server tracing, see trace components.

• If the BestDeal support is enabled, ensure that the <SequenceCombinationLimit> is configured with an acceptable value. For more information about changing the value for this setting, see best deal support for promotions.

• Adjust the cache size for PersistenceManagers, in particular the <InitialCacheSize> and <MaxCacheSize> for the PromotionPersistenceManager. By setting the cache size according to the store promotion usage we can improve performance. Setting the cache size can prevent unnecessary access to the database and prevent promotion rule XML parsing. The default setting allows the cache to contain 1024 promotion objects. This cache can be expanded to 8192 objects. Increase the <MaxCacheSize> if the site contains more actively used promotions. This cache is contained in JVM, and the size can be adjusted according to the available free memory at runtime.

• Enable the WCPromotionDistributedMapCache DistributedMap. Enabling this setting can help improve promotion-related logic performance.

For more information about adjusting the settings of the promotion engine and more promotion engine configuration options, see configuring the promotion engine.

Promotion agenda builders

When the promotion engine is invoked, an agenda builder is first used to determine the active promotions for an order. The specific promotion agenda builder the site uses can affect the performance of the promotion evaluation process. For more information about ensuring the site uses the appropriate agenda builder, see promotion agenda builder considerations.

Number of products in an order

A shopping cart with many products does not perform the same as a cart with few products. This behavior is due to the number of calculations that need to perform to evaluate the promotions for a cart with many products. This calculation-based performance issue is compounded when multiple promotions are applied to the same item in a cart. To improve performance, focus on the typical size and makeup of orders for promotion performance evaluation during performance tuning. Test large orders concurrently with typical orders to ensure that the evaluation of these orders do not cause a reduction in performance for average shoppers.

We can adjust the cart size threshold for shoppers to help avoid performance issues as a result of large cart order sizes. For more information about adjusting the cart size threshold, see configuring order boundaries to prevent unbound exceptions.

Catalog structure

Many promotion types have catalog-based conditions. The performance of the catalog information retrieval can affect promotion evaluation. Since a promotion can be set up at the parent product or category level, the CalculationCodeListDataBean must resolve the item-product relation. The CalculationCodeListDataBean must discover the category structure for each item in a shopping cart to verify whether the order item qualifies for a category-level promotion. The process uses the category structure for each item to build a query for promotion information against the
CATENCALCD and CATGPCALCD tables. The number of catalogs for our store and the depth of your category structures can affect the performance of this process. This process is also triggered in ShopcartDrivenAgendaBuilder logic to filter out unrelated promotions according to the shopping cart. The logic for this process uses the WCS DataCache to access catalog information. We can enable the following distributed maps to enable better performance of the promotion logic for retrieving catalog information:

• WCCatalogGroupDistributedMapCache DistributedMap

• WCCatalogEntryDistributedMapCache DistributedMap

Note: To improve performance, the default promotion logic caches the resolved category structure and attributes data in promotion objects during the evaluation process.

Number of customer segments and conditions

Customer segments can be defined as one of two types:

• Explicit customer segments which have members explicitly added into the segment.

• Implicit customer segments where characteristics of the customer are used to determine membership in the segment. For example, demographics or purchase history.

Use explicit segments performs better than implicit customer segment whose rules must be repeatedly evaluated at runtime. Enabling the WCUserDistributedMapCache DistributedMap also helps the performance of member-related logic.

Related tasks
WebSphere Commerce data cache
Enable WebSphere Commerce data cache

Related reference
Promotion performance tuning