IBM Support

Overview of WebSphere Commerce performance and stability configurations

Recommended Resources


Abstract

An overview of initial configuration settings that affect performance and stability of a WebSphere Commerce environment. This document is intended to be used as a reference point when starting the tuning process. It can also be used to validate current settings to ensure proper configuration.

Content

Performance tuning is an iterative process which involves tuning and configuring the various systems and components of the environment which include, but not limited to, the database, the web server and the application server. Multiple changes may be required to reach the desired performance of the system under stress. When tuning, it is important to begin with a baseline and monitor performance metrics to determine if any parameters should be changed. The objective of this document is to provide a baseline for the most common configuration settings that affect performance and stability of a site. It is not intended to be a definitive resource for tuning, but to provide guidelines and recommendations that will be applicable to the majority of WebSphere Commerce sites. Each WebSphere Commerce environment is different, but by using the following list, you can validate your environment configuration settings to ensure they are not poorly configured.

Note: Support can not provide specific tuning recommendations for your site. The configuration parameters and values documented below are intended to be used as starting values when tuning and validating your WebSphere Commerce environment configuration.




Application "Funnel ":
Application funnel is the definition of concurrent executing threads across critical components in the Commerce solution. Experience and study shows that when hardware resources are saturated, application throughput and response time degrades. Therefore, it is critical to ensure under all situations, we do not let in more traffic than the system can handle. The purpose of the funnel, and tuning in each tiers for that matter, is to protect the system resources on each tier beyond saturation. This will enable each tier to operate at its best and allow transactions to be served quickly.

Note: How much concurrency each tier can consume before saturation depends hardware capacity such as CPU, memory and IO. However, application efficiency, caching strategy, features and data have just as much impact. Therefore, it is an iterative effort to continue to tune and adjust the funnel to the most optimal case for each deployment and when major changes are introduced. This document provides the 'starting point' for the funnel and it is recommended for customers to adjust as needed to best fit the unique implementation including the ratio between WC and Solr.



Operating System:
Parameter Default Value Description Initial Value
ulimit -f File Size Limit unlimited
ulimit -n File Handle Limit 8192
Additional Info Operating System prerequisites

WebServer : (configurable in httpd.conf)
Parameter Default Value Description Initial Value
ThreadsPerChild 25 Number of threads created when a child process starts. 256
ThreadLimit 25 Upper limit of threads per child process 1024
ServerLimit 64 Max number of processes allowed 2
MaxClients 2048 The number of concurrent users 2048
MinSpareThreads 25 Minimum number of idle threads IHS will maintain 1
MaxSpareThreads 75 Max # of ide threads before 1024
KeepAlive On Define whether or not to allow persistent connections On
MaxKeepAliveRequests 0 Maximum number of requests to allow during a persistent connection. 0 = unlimited amount. 100
KeepAliveTimeout 10 # of sec to wait for the next request from same client 15
StartServers 1 Initial number of server processes to start Equal to ServerLimit


WebServer Plug-in :
Parameter Default Value Description Initial Value
MaxConnections -1 Used to gauge when server is getting overwhelmed. Used to limit the number of pending request to AppServer. Equal to max web container threads
ConnectTimeout 0 How long should the plug-in wait when trying to open socket to Appserver 5
LoadBalanceWeight 2 A starting weight that is dynamically changed by plug-in during runtime. Value is lowered each time a request is assigned to clone. Once it gets to 0, it must readjust the weights. Recommend to have a higher value. 20 or higher
ServerIOTimeout 0 Determines how long plug-in will wait for response from application -60
RetryInterval 60 Sets the length of time the plug-in will wait before trying to use an appserver that was marked down. (number of appservers in cluster - 1) x (absolute ServerIOTimeout) - 1
ServerIOTimeoutRetry
-1
New but extremely important setting that can be used to control the number of retries due to ServerIOTimeout. Retries are always limited by the number of servers in the cluster.
(Introduced with PM70559)
Recommend to set this to limit the number of retries of request that timed out
Note: Additional information can be found in post " Fail in your own terms - Plug-in failover options"



Application Server/Commerce Server is the second tier in a Commerce environment. There are several areas that should be reviewed when tuning Commerce Server, including JVM, WebContainer, Connection Pool and Caching. The configurable parameters can be modified using the WebSphere Application Administrative Console.

JVM Settings:

32-bit:
Parameter Default Value Description Initial Value
Minimum Heap Size 256 mb Specifies, in megabytes, the initial heap size available to the JVM code 1.5 gb
Maximum Heap Size 1024 mb Specifies, in megabytes, the maximum heap size that is available to the JVM code 1.5 gb
Minimum Nursery size Not Specified Specifies the minimum size allocated on heap for new objects. 256 mb
Maximum Nursery size Not Specified Specifies the maximum size allocated on heap for new objects. 512 mb
Garbage Collection Policy Not Specified Specifies the garbage collection policy to be used Generational Collection policy (gencon) -Xgcpolicy



64-bit:
Parameter Default Value Description Initial Value
Minimum Heap Size 512 mb Specifies, in megabytes, the initial heap size available to the JVM code 1.5 gb
Maximum Heap Size 1024 mb Specifies, in megabytes, the maximum heap size that is available to the JVM code 4.0 gb
Minimum Nursery size 256 mb Specifies the minimum size allocated on heap for new objects. 512 mb
Maximum Nursery size 512 mb Specifies the maximum size allocated on heap for new objects. 1024 mb
Garbage Collection Policy Not Specified Specifies the garbage collection policy to be used Generational Collection policy (gencon) -Xgcpolicy

* Note: It is strongly recommended to move to 64-bit architecture to take advantage of the larger heap size that a 64-bit JVM can address.


WebContainer :
Parameter Default Value Description Initial Value
Minimum WebContainer Thread Pool 25 Specifies the minimum number of webcontainers in pool to handle incoming request. 25
Maximum WebContainer Thread Pool 25 Specifies the maximum number of webcontainers in pool to handle incoming request. 25
WebContainer Thread Inactivity Timeout in milliseconds 3500 Specifies the number of milliseconds of inactivity that should elapse before a thread is reclaimed 3500
IsGrowable false Specifies whether the number of threads can increase beyond the maximum size configured for the thread pool. false
Note: Minimum and Maximum WebContainer Thread Pool should be the same to prevent overhead of destroying threads and prevent native memory issues.
**Note: For additional information: Key Tuning Configurations: WebContainer Pool


JDBC Connection Pool:
Parameter Default Value Description Initial Value
Connection timeout 180 30
Minimum number of connections 0 Specifies the minimum number of physical connections that you can create in this pool 5
Note:Additional considerations
Maximum number of connections 55 Specifies the maximum number of physical connections that you can create in this pool. 55
Use the following equation to determine appropriate number of connections:
# of WebContainer Threads + # of Scheduler Threads + Key Manager + Auditing + Parallel and Serial MQ Listener Threads + # of non-WebContainer threads used by Custom Code
Prepared Statement Cache 50 Specifies the number of statements that can be cached per connection. 150
Connection Timeout (seconds) 180 Specifies the interval, in seconds, after which a connection request times out 30
**Note: Additional info if firewall exist
Reap Timeout (seconds) 300 Specifies the interval, in seconds, between runs of the pool maintenance thread. 300
Unused Timeout (seconds) 1800 Specifies the interval in seconds after which an unused or idle connection is discarded. 1200
PurgePolicy Entire Pool Specifies how to purge connections when a stale connection or fatal connection error is detected FailingConnectionOnly
Note : For additional information on minimum setting review the following post
*Note: Additional information: Key Tuning Configurations: DataSource Connection Pool
**Note : If there is a firewall between the Commerce Server and Database, refer to the following technote for configuration parameters


DynaCache:
Parameter Default Value Description Initial Value
Cache Size 2000 Specifies the maximum number of entries the cache holds 2000
Replication Type Not Shared Not shared: only invalidation requests get replicated. Cache entry generated on individual JVM and will not be shared. This reduces DRS overhead but will take a little bit longer for all JVMs to have a warm cache. Not Shared
Enable All Out of Box Data Cache --- Refer to Knowledge Center to enable Data Cache
JVM Parameters required for Caching Refer to Knowledge Center: Enabling Dynamic Cache
Note: Additional information on finding the size of caches can be found here
Recommendation for Extreme Scale:
  • The catalogs, containers, and clients all need to be running WXS version 8.6.0.8. There are numerous performance improvements at the highest level. Anyone using the dyncache must have PI40055 on. This is for slow inflation of data.
  • JR50131 should be applied. This apar will send a single cache clear signal when the cache is cleared rather than one for each object.
  • The COPYMODE of the dynacache grid should be set to COPY_ON_READ_AND_COMMIT This allows for optimal storage and seriallization of dynacache data.
  • Consider enabling the near cache if you applications can tolerate possible stale data
-



Database: Important settings to help with performance and locking
Parameter Default Value Description Initial Value
Total Allowed Connections n/a Specifies the total number of connections allowed Sum of (total max JDBC Connections from all JVMs) + (total backend connections) +
(admin connections)
AVG_APPLS 1 Used for applications with large number of concurrent users. This parameter helps the optimizer plan for bufferpool, sortheap and other shared resource availability for a chosen access plan at run time. 1
Sorts n/a Used for large sorts. Used in conjunction with the DBM cfg parameter SHEAPTHRESH. Use shared sort and tune sort related parameters to minimize sort overflow
BufferPool Determines how database is defined to handle memory for processing statements Tune bufferpool to minimize physical reads. Tune bufferpool for all tablespace sizes.
Registry (settings to reduce locks)
DB2 version older than Fix Pack 4
DB2_EVALUNCOMMITTED On Allows table or index access scans to defer or avoid row locking until a data record is known to satisfy a predicate evaluation. On
DB2_SKIPINSERTED On Allows statements using either Cursor Stability or Read Stability to skip uncommitted inserted rows as if they had not been inserted. On
DB2_SKIPDELETED On Allows statements using either Cursor Stability or Read Stability to unconditionally skip deleted keys during index access and deleted rows during table access. On
DB2_REDUCED_OPTIZMIZATION n/a This setting can help reduce lock contention for DELETE statements which
cascade delete to multiple tables
JULIE
DB2 version 9.5 Fix Pack 4 or newer
DB2_WORKLOAD n/a Expands into the following parameters:
DB2_REDUCED_OPTIMIZATION=INDEX,UNIQUEIN
DEX,JOIN,NO_SORT_MGJOIN,JULIE
DB2_MINIMIZE_LISTPREFETCH=YES
DB2_INLIST_TO_NLJN=YES
DB2_ANTIJOIN=EXTEND
DB2_EVALUNCOMMITTED=YES
DB2_SKIPINSERTED=YES
DB2_OPTPROFILE=YES
DB2_OPT_MAX_TEMP_SIZE=10240
DB2_SKIPDELETED=YES
WC
NUM_INITAGENTS This setting is used to determine the initial number of idle agents that are created in the agent pool when db2start command is issued. Set to the same value specified for max_connections
NUM_POOLAGENTS This setting can be used to keep the agents in memory after the application disconnects. see DB2 KC

Marketing:

Parameter Default Value Description Initial Value
PersonalizationId false The Personalization ID identifies a user and allows WebSphere Commerce to present them with personalized content when the user interacts with the business, throughout the business lifecycle. enabled
PersistentSession cookieValue false Enable persistent sessions, which will store some session-related information of the registered user to permanent cookie enabled
Experiment Evaluation Event Listener false Enable listener to support some behavioral features and to gather marketing statistics for marketing experiments. To improve performance, you can limit the SensorEventListener to monitor events raised only by the stores module. enabled
SensorEventListener false Enable listener to support some behavioral features and to gather marketing statistics enabled
Marketing Cache (DM_Cache) size n/a Used to cache all information related to an activity definition: activity,element information, ordering scheme of espot and default content of espot 3 times the number of spots in EMSPOT table


Promotions:

Parameter Default Value Description Initial Value
PromotionPersistenceManager Cache (MaxCacheSize) 1024 Cache used to store promotion objects, can prevent unnecessary calls to the database. Increase default value if your site contains more actively used promotions
PerformCheckForCategoryLevelPromotions false Enable if you do not have a lot of category level promotions. It checks for active category-level promotions. If not found, it prevents the call to retrieve parent categories. true
WCPromotionDistributedMapCache Cache to improve promotion-related logic true

WebSphere Commerce Search: The configuration settings for search are directly related to the size of your catalog data and if your site has multiple indexes (language specific). The following parameter values will show how to find the appropriate setting value for each. In addition to these settings, it is important to design the search profile to include only needed providers, processors and return fields to reduce he payload and save extra processing.

Note: It is recommended to use a Staging environment to build the index and then propagate to the production environment.

The Initial Value column settings are based on the following information:

Sample catalog size: Catalog size = 1.8 million entries
Total attributes = 2000
Total categories = 10000
Each product contains 20 attributes
Average size of each Catalog Entry 10 KB

Runtime / Slave Solr Server (which handles search request): The parameters are configured for each core. Combined values from all cores should not exceed the maximum heap size. In general, with the exception of ramBufferSize, the settings listed below can be larger on the slave server because it servicing search request.

Parameter Default Value Description Initial Value How to determine the initial value
ramBufferSize 64 This sets the amount of RAM that may be used by indexing for buffering before they are flushed to directory. Slave will have a smaller ramBufferSize.
queryResultCache
1000
Caches results of searches - ordered lists of document ids
(DocList) based on a query, a sort, and the range of documents requested.





1.44 gb
The optimal size of this cache should be decided based on the results of the common queries that are cached. The is used for caching results of normal queries.

On Slave server, the queryResultCache
queryResultCache is 4 bytes per docId (int) reference x queryResultWindowSize x 10M cache slots for caching the first three pages of the main query
queryResultWindowSize 36 An optimization for use with the queryResultCache. When a search is requested, a superset of the requested number of document ids are collected. 36 queryResultWindowSize = (size of search result page in storefront multiplied by the page returned + 2 prefetch pages)
queryResultMaxDocsCached 36 Maximum number of documents to cache for any entry in the queryResultCache. 36 For optimal performance, this should be set to the same value as queryResultWindowSize
filterCache 1000 This cache stores information to filter out the right documents across the entire index for a particular query. Used for caching filter queries
It is used for caching filter queries. This cache will not present the returned documents in a sequence and so, is not appropriate for caching a query that relies on relevance or sort field




400000
filterCache = (avg search result) x (4 bytes per docId) x (# of cache entries)

assume average search result page is 20. Multiple 20 x 4bytes) x (5000 cache entries)
documentCache 1000
Solr caches documents in memory so that requests need not use disk space for stored fields. This cache avoids Solr having to re-fetch a document during a request. 500000 documentCache = (avg size of catalog entry) x (# of cache entries)

(avg size of catalog entry is 10KB) x (5000 cache entries) =
maxBooleanClauses 3072 Maximum number of clauses in each BooleanQuery, an exception is thrown if exceeded.
3072
stores that contains a high number of categories or contracts should increase the default value for maxBooleanClauses.

Master Solr Server (where indexing takes place). The parameters are configured for each core. Combined values from all cores should not exceed the maximum heap size. In general, with the exception of ramBufferSize, the settings above (queryResultCache, queryResultWindowSize, queryResultMaxDocsCached, filterCache and documentCache) will be much smaller than the settings on a runtime / slave server because it is not handling request. It is primarily used to build index.

Parameter Default Value Description Initial Value How to determine Initial Value
ramBufferSize 64 This sets the amount of RAM that may be used by indexing for buffering before they are flushed to directory. 1.2 gb Master will have a large ramBufferSize for indexing. It can not exceed the maximum heap size value.

General Search settings:
Parameter Default Value Description Initial Value
services/cache/WCSearchNavigationDistributedMapCache n/a Cache used by search cache facet data, catalog group data, and relevancy data Tune this cache instance to the number of facteable categories. Note: When using Feature Pack 7 Rest this should be configure on Solr server
services/cache/WCSearchAttributeDistributedMapCache n/a Used to cache additional data for attributes. Tune this cache instance to the number of attribute dictionary facetable attributes values.
Note: When using Feature Pack 7 Rest this should be configure on Solr server
Search JVM Heap Size 512 mb Specifies, in megabytes, the initial heap size available to the JVM code 1.5 gb
Maximum WebContainer Thread Pool 50 Specifies the maximum number of webcontainers in pool to handle incoming request. 50
This should be smaller than the "total" number of Commerce WebContainer threads (all Commerce nodes)
Garbage Collection Policy n/a Specifies the garbage collection policy to be used Generational Collection policy (gencon) -Xgcpolicy
Feature Pack 7 - Enable Search Data Cache n/a Enabling the WebSphere commerce search data cache
Feature Pack 7 using Rest should disable remote business context service n/a Disabling the remote business context call
Recommended Commerce Search Apars Recommended Search Apars in Search Blog
You can disable certain expression providers and result filters to optimize the storefront flow and improve the overall response time. Review Knowledge Center
Additional tuning parameters WebSphere Commerce search performance tuning


Search Engine Optimization (SEO):Refer to the article on finding cache sizes, "How Big is your Cache". This method should be used to find the appropriate settings for each SEO data cache.

Parameter Default Value Description Initial Value
WCSEOURLKeyword2URLTokenDistributedMapCache 3000 This cache is used during the process of parsing the incoming SEO URL to construct the matching dynamic URL 3000
WCSEOURLToken2URLKeywordDistributedMapCache 3000 This cache is used during the process of constructing the SEO URL to retrieve the URL keywords required. 3000
WCSEORedirectRulesDistributedMapCache 1000 This cache is used to find the new URL keyword to be used, when an incoming URL being parsed contains an URL keyword that has been redirected. 1000
WCSEOURLDistributedMapCache 5000 This cache is responsible for caching parsed SEO URLs. When an incoming SEO URL is parsed, the parser's result data is cached so that subsequent requests with the same URL can directly use the cached parser result instead of parsing the URL again. 5000
CleanSEOURL job n/a Run regularly to review SEO URL redirects in place and remove the redirects that are no longer needed.


Orders : If you site has large shopping carts, you should utilize the performance improvements for large shopping carts
Parameter Default Value Description Initial Value
Enable optimized large shopping cart commands n/a To improve the performance of large shopping carts, you can optimize the OrderItemAdd, OrderItemUpdate, OrderItemDisplay, and OrderCalculate commands. Enabling optimized large shopping cart order commands
Enable optimized tax command n/a The optimized tax command provides improved performance for sites that encounter shopping carts that include hundreds of order items or more. Enabling optimized tax commands
Enable optimized shipping calculation n/a The optimized shipping calculation command provides improved performance for sites that encounter shopping carts that include hundreds of order items or more. Enable optimized shipping calculation commands

Additional information on these topics can be found in the Knowledge Center




Document information

More support for: WebSphere Commerce Enterprise
Configuration

Software version: 6.0, 7.0, 7.0.0.1, 7.0.0.2, 7.0.0.3, 7.0.0.4, 7.0.0.5, 7.0.0.6, 7.0.0.7, 7.0.0.8

Operating system(s): AIX, IBM i, Linux, Solaris, Windows

Software edition: All Editions

Reference #: 1684611

Modified date: 08 April 2015