HCL Commerce default tunables
HCL Commerce has two instance profiles, Test and Production. Each profile contains its own tunable values for the HCL Commerce application servers, including Java virtual machines (JVMs), cache, and others. These values are in place to provide a standard base level of performance from which to operate, or tweak for improvements to individual configurations.
The Test profile is used for application servers in Authoring or Functional testing environment. The Production profile is used for application servers in Production or Performance testing environment. The tunable values that are listed in this document provide a reference that you can use as a starting point in fine-tuning your own environment. You can tune each value based on the performance test result in your own environment.
HCL Commerce uses containerization. To ensure that your tuned settings persist in subsequent container instances, follow the procedure that is described in Building a custom Docker image from a deployable package. Alternatively, you can customize the Docker startup process to do the JVM tuning during docker startup. For more information, see Tutorial: Customizing the Docker start-up logic. If no runEngine command exists, you can develop a customized runEngine command or replace the complete configuration file with customized content. For testing or experiment purpose, you can change the tunable value manually.
WebSphere IBM JVM Settings (for HCL Commerce and HCL Commerce Search)
The following table lists start values for WebSphere application servers that are running in Liberty (for Store and Search server) and the WebSphere Application Server (for Transaction servers). To simplify the tuning effort, use similar tuning parameters for different application servers. If the workload likely to be different on different servers (for example, on the Transaction server that is compared with Store servers), you can use different tunable values for different servers. The RunEngine commands to change the JVM settings are: set-heap-size/add-system-property (for Store and Search servers), and set-heap-size/add-generic-jvmarg (for Transaction servers). To modify JVM settings manually in Liberty, edit the jvm.options file directly. For the WebSphere Application Server, make your changes in the Administration Console.
| Property Name | Version 9 Test Profile | Version 9 Production Profile |
|---|---|---|
| 32 / 64-bit JDK | 64-bit | 64-bit |
| Thread Stack size | -Xss1m | -Xss1m |
| Initial heap size (-Xms) | 512m | 2048 m |
| Maximum heap size (-Xmx) | 1536m | 4096m |
| Disable JIT | No | No |
| Garbage collection policy (-Xgcpolicy) | gencon | gencon |
| Garbage collection threads (-Xgcthreads) | 2* | 8* Set the gcthreads value to the available VCPU number or VCPU number -1. To determine the optimal VCPU number for each application server Docker container, refer to Docker performance tuning. |
| Fixed nursery (-Xmn) | Not specified | 1536m |
| Starting nursery (-Xmns) | 256m | Not specified |
| Max nursery (-Xmnx) | 768m | Not specified |
| Garbage collection logging |
Enabled with log rotation*: -Xverbosegclog[:<file>[,<X>,<Y>]] |
Enabled with log rotation*: -Xverbosegclog[:<file>[,<X>,<Y>]] * For more information regarding this default, see, Boring but necessary: Rotate the GC log!. |
| Additional tuning parameter for JSP optimization | -Dcom.ibm.wsspi.jsp.disableResourceInjection=true | -Dcom.ibm.wsspi.jsp.disableResourceInjection=true |
HCL Commerce Cache Settings (DynaCache)
The Base Cache is the cache instance that stores Servlet cache entries and some command cache entries. It is defined in all application servers: Store, Transaction and Search. However, the Base Cache is not used by default on the Search server.
The tunable values are applicable when a Servlet cache (for a JSP fragment) is used. The cache is stored in the Store server in the Remote store environment, or in the Transaction server in the Local store environment. For the Remote store environment, the production Store server normally follow the Production profile, while the Transaction server follows the Test profile. Modify the Base Cache settings manually: On Liberty servers, edit server.xml file directly. On the WebSphere Application Server, make your changes within the Administration Console.
| Property Name | Version 9 Test Profile (or when Servlet Cache is not used) | Version 9 Production Profile (or when Servlet Cache is used) |
|---|---|---|
|
2000 | 5000 |
|
Off | On |
|
Off | Off |
|
N/A | High performance and high memory usage |
|
N/A | 10 GB* 10 GB is a starting value. Your value can be determined by balancing the disk space and total cache entry size. |
HCL Commerce Data Cache Settings
Configuring HCL Commerce data cache
Different data cache instances are defined for each of the the three HCL Commerce application servers (Store, Search, and Transaction). The default profile value is the same for the same cache instance on different servers (for example, WCFlexFlowDistributedMapCache exists on both the Store server and Transaction server). But you can adjust the value based on the actual usage on different servers.
The values in the following table are starting values for performance tuning. Your business data volume is likely to be different than the default. Therefore, for example, one company might have a large catalog (land therefore a large number of Catalog Group and Catalog Entries) but a very small number of promotions. Another company may have a small catalog but a large number of promotions. Increase or decrease the data cache size accordingly. Increasing your data cache will increase the memory footprint by the number of cached objects (data caches are only stored in memory). The HCL Commerce performance team has done performance testing to ensure that the recommended cache size setting does not cause JVM out-of-memory conditions. However, the actual data cache size in memory is determined by each cache entry size and total cache entry number in memory. Do your own performance testing to ensure that the configured data cache size can be contained in memory, and balance between performance and memory usage.
Transaction server data cache instances
You can manually modify data cache settings the WebSphere Application Server Administration Console.
| Property Name | Version 9 Test Profile | Version 9 Production Profile |
|---|---|---|
|
20,000 | 100,000 |
|
20,000 | 100,000 |
|
2,500 | 25,000 |
|
10,000 | 50,000 |
|
1,000 | 5,000 |
|
5,000 | 25,000 |
|
1,000 | 5,000 |
|
1,000 | 5,000 |
|
5,000 | 25,000 |
|
1,000 | 5,000 |
|
1,000 | 5,000 |
|
5,000 | 25,000 |
|
3,000 | 15,000 |
|
3,000 | 15,000 |
|
5,000 | 25,000 |
|
2,000 | 10,000 |
|
2,000 | 10,000 |
|
1,000 | 5,000 |
|
1,000 | 5,000 |
|
100,000 | 500,000 |
|
1,000 | 5,000 |
|
2,000 | 10,000 |
|
1,000 | 5,000 |
|
1,000 | 1,000 |
|
3,000 | 10,000 |
|
3,000 | 15,000 |
|
3,000 | 15,000 |
|
3,000 | 15,000 |
|
5,000 | 50,000 |
|
5,000 | 50,000 |
|
3,000 | 15,000 |
|
10 | 50 |
|
10 | 10 |
|
5,000 | 25,000 |
Store server data cache instances
You can manually modify data cache settings by directly editing server.xml.
| Property Name | Version 9 Test Profile | Version 9 Production Profile |
|---|---|---|
|
1,000 | 5,000 |
|
5,000 | 25,000 |
|
3,000 | 15,000 |
|
3,000 | 15,000 |
|
1,000 | 5,000 |
|
1,000 | 5,000 |
|
1,000 | 5,000 |
|
1,000 | 1,000 |
Search server data cache instances
You can manually modify data cache settings by directly editing server.xml.
| Property Name | Version 9 Test Profile | Version 9 Production Profile |
|---|---|---|
|
5,000 | 25,000 |
|
1,000 | 5,000 |
|
2,000 | 10,000 |
|
3,000 | 15,000 |
|
5,000 | 25,000 |
|
2,000 | 10,000 |
|
2,000 | 20,000 |
|
5,000 | 25,000 |
|
1,000 | 5,000 |
|
5,000 | 25,000 |
|
3,000 | 15,000 |
|
100 | 100 |
Other tunables
The following tunables are applicable to the Production profile only. You do not need to tune them for the Testing profile.
Liberty Executor setting
Liberty has a different thread pool model than the WebSphere Application Server. There is a unified Executor pool for different connections. The default value for this is automatic tuning. However, HCL Commerce performance testing reveals that this value may cause unpredicted behaviors under heavy workloads.
<executor maxThreads="50" coreThreads="4" />HTTP KeepAlive setting
<httpOptions keepAliveEnabled="true" maxKeepAliveRequests="-1" /> Transaction timeout for Search server
<transaction totalTranLifetimeTimeout="600s"/>