Home
Documentation
HCL Commerce is a high-availability, highly scalable and customizable e-commerce platform. Able to support hundreds of thousands of transactions per day, HCL Commerce allows you to do business with consumers (B2C) or directly with businesses (B2B). HCL Commerce uses cloud friendly technology to make deployment and operation both easy and efficient. It provides easy-to-use tools for business users to centrally manage a cross-channel strategy. Business users can create and manage precision marketing campaigns, promotions, catalog, and merchandising across all sales channels. Business users can also use AI enabled content management capabilities.
Performance
Topics in the Performance section describe the means by which to plan, implement, test, and re-visit the optimization of HCL Commerce site performance.
Methodology
Like site security, a proper approach to site performance requires planning, execution, testing, monitoring, and maintenance. The following collections of topics describe each phase of this process, and contain the recommended considerations, and best practices for getting the most out of your HCL Commerce deployment.
Tuning
an HCL Commerce deployment is made up of many individual parts that work together to provide the e-commerce experience. By default, each part is configured to provide a base level of performance. However, individual changes can be made to potentially gain extra performance. The following collection of topics provides details on how to make these performance changes to the individual components of your site.
Search performance tuning
Consider these search performance tuning hints and tips when you administer HCL Commerce Search.
prohibitConcurrentCacheMiss query server configuration
The new prohibitConcurrentCacheMiss has the configuration value true and is enabled by default. It can be disabled by setting it to false in the CrossTransactionCache section in the query server wc-component.json configuration file. When configured as true, the result is a decrease in the burden imposed on the ElasticSearch servers due to not repeatedly executing the same query from the same query server.

Documentation
HCL Commerce is a high-availability, highly scalable and customizable e-commerce platform. Able to support hundreds of thousands of transactions per day, HCL Commerce allows you to do business with consumers (B2C) or directly with businesses (B2B). HCL Commerce uses cloud friendly technology to make deployment and operation both easy and efficient. It provides easy-to-use tools for business users to centrally manage a cross-channel strategy. Business users can create and manage precision marketing campaigns, promotions, catalog, and merchandising across all sales channels. Business users can also use AI enabled content management capabilities.
- Getting started
  HCL Commerce has different advantages for business users, administrators and developers. HCL Commerce targets each of these roles with a tailored set of offerings so that each of your users can get maximum benefit.
- Installing and deploying
  Learn how to install and deploy HCL Commerce development environments and HCL Commerce production environments.
- Migrating
  Before you migrate to HCL Commerce Version 9.1, review this information to help plan and execute your migration.
- Operating
  Topics in the Operating category highlight tasks that are typically performed by business users, customer support representatives, to complete their day-to-day tasks in the operation of the HCL Commerce site.
- Integrating
  Topics in the Integrating category highlight the tasks that are commonly performed for using HCL Commerce in combination with other products.
- Administering
  Topics in the Administering category highlight tasks that are typically performed by the Site Administrator, to support daily operations of the HCL Commerce site.
- Customizing
  The topics in the Customizing section describe tasks performed by an application developer to customize HCL Commerce.
- Tutorials
  HCL Commerce provides many tutorials to help you customize and understand your HCL Commerce instance and stores.
- Samples
  Topics in the Samples category highlight the various samples that are provided with HCL Commerce.
- Compliance
  The following section describes how you can leverage HCL Commerce features and functionality to help your site be compliant with different privacy and security standards.
- Securing
  These topics describe the security features of HCL Commerce and how to configure these features.
- Performance
  Topics in the Performance section describe the means by which to plan, implement, test, and re-visit the optimization of HCL Commerce site performance.
  - Methodology
    Like site security, a proper approach to site performance requires planning, execution, testing, monitoring, and maintenance. The following collections of topics describe each phase of this process, and contain the recommended considerations, and best practices for getting the most out of your HCL Commerce deployment.
    - Design phase
      During the design phase of your project, it is important to consider performance priorities. It is important to design a solution that has a good balance of features and performance consideration, build a performance test environment, and begin to deploy tools that are required to support your performance strategy. It is also important to identify architecture limitations that might change a non-functional requirement.
    - Development phase
      During the development phase, it is important to measure the response time of business critical steps in the development environment.
    - Testing phase
      During the testing phase, it is important to start with simple, common test cases and gradually go to more complex scenarios and environment configurations. Other priorities include measuring the performance of the application as load scales up to projected peak and identifying and resolving the root causes of resource constraints and application bottlenecks.
    - Maintenance phase
      Post-launch, during the maintenance phase, instrument and monitor performance indicators in the production environment to enable the team to proactively identify and address potential issues before users are affected. Priorities also include fostering communication between marketing, performance, and operation teams to be better prepared for promotional events. And using the data that is captured from production to optimize planning for future marketing and promotional activities.
    - Web server considerations
      Even though the web server is a mature technology, it can still be tuned to get better performance, especially on large websites. This section covers the common performance considerations for all the web servers, and is operating system independent.
    - Application server considerations
      HCL Commerce is ultimately another Java 2 application that runs on top of WebSphere Application Server and WebSphere Liberty. As a result, WebSphere Application Server acts as the operating system for HCL Commerce. Optimizing the application servers optimized improves the performance of HCL Commerce.
    - JDBC_MONITOR_ENABLED parameter
      JDBC Monitor (Java Database Connectivity) is a debugging tool that allows you to examine SQLs that are executed in any application for performance and troubleshooting purposes. This document provides the installation steps for JDBC Monitor.
    - Tuning
      an HCL Commerce deployment is made up of many individual parts that work together to provide the e-commerce experience. By default, each part is configured to provide a base level of performance. However, individual changes can be made to potentially gain extra performance. The following collection of topics provides details on how to make these performance changes to the individual components of your site.
      - HCL Commerce performance tuning
        HCL Commerce by itself does not have too many performance tuning knobs. Consider HCL Commerce to be a Java EE application that consists of business logic and relies on WebSphere Application Server to provide the core function to make HCL Commerce perform well.
      - Tuning best practices
        Use these tips and best practices to help you successfully work with Workspaces and HCL Commerce Search, deploy HCL Commerce, and develop reusable and easily maintainable JSP pages within the HCL Commerce store development framework.
      - 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.
      - Search performance tuning
        Consider these search performance tuning hints and tips when you administer HCL Commerce Search.
        Enabling the Solr administrative interface
        You can monitor Solr in HCL Commerce Search using the Solr administrative interface. The Solr native administrative interface can be used to gather runtime statistics for each Solr core that is running on the search server. It can also be used to perform simple search queries.
        Activating the web cache monitor
        You can use the web cache monitor to view and manage Search cache information.
        Guidelines to improve faceted navigation performance
        Facet filtering introduces many permutations to products displayed to the user. The large variety can significantly reduce cache hit ratio and increase server utilization as more results must be rendered rather than served from cache.
        Search and Marketing statistics in HCL Commerce
        In a typical deployment model, business users typically do not have access to the production system. The situation is different when business users want to review live production data, such as search and marketing statistics. In this case, the data must be replicated into a staging or authoring environment to be viewed in the Management Center. The production system is not impacted by the data replication operation. It is the staging or authoring system that pulls the production data back into the staging database, without involving any production CPU cycles.
        Tuning search relevancy
        You can fine-tune search relevancy using Solr and HCL Commerce-side indexing and querying features.
        Tuning Index Load
        You can tune Index Load for optimal performance by configuring the tunable values and evaluating the results.
        Tuning product grouping
        The product grouping feature is based on the Solr field collapsing and result grouping query feature. There might be performance impacts when you enable product grouping. Consider the factors that influence performance impacts and how to design and tune to minimize the impact. It is recommended that you assess the business requirements for the affected store pages, as some of the configurations might change the search results being returned.
        Using the Solr atomic update feature with Search
        Atomic update, also known as partial update, enables you to make index updates on specified stored fields in an existing document. This approach is especially useful when a core has many fields and only a small number of them have been changed between index builds.
        prohibitConcurrentCacheMiss query server configuration
        The new prohibitConcurrentCacheMiss has the configuration value true and is enabled by default. It can be disabled by setting it to false in the CrossTransactionCache section in the query server wc-component.json configuration file. When configured as true, the result is a decrease in the burden imposed on the ElasticSearch servers due to not repeatedly executing the same query from the same query server.
        HCConcurrencyLimiter configuration
        Server performance can be affected when too many query requests are concurrently sent to the Elasticsearch servers. You can control the load by limiting the number of threads that can concurrently issue query requests.
        Search performance and capacity best practices
        A high-volume HCL Commerce implementation can include large catalog volume, large number of languages, and a limited amount of time to build the search index. By doing careful capacity planning and following performance best practices, you can optimize performance and capacity for HCL Commerce version 9.0.1.3 and higher.
      - Database performance tuning
        The database is usually one of the potential areas for bottlenecks that makes HCL Commerce unable to scale and perform well. It is therefore crucial that the database is tuned appropriately for your implementation.
      - JVM performance tuning
        For improved performance, JVM settings require careful tuning. Tune your JVM settings to avoid experiencing memory allocation errors. The symptoms for these errors can vary from intermittent performance problems to the periodic failure and restart of the JVM. Consider the default JVM settings set by HCL Commerce as a starting point. The information in the JVM performance tuning topic is specific to the IBM JDK.
      - Promotion performance tuning
        HCL Commerce provides business users with multiple features and functionality to help enhance developing promotions for a store. However, planning is required to use the various techniques available to achieve and maintain wanted site performance.
      - Marketing performance tuning
        The Management Center Marketing tool provides business users with many features to help enhance site and store marketing activities. Planning is required to use the various caching techniques available to achieve and maintain your optimal site performance.
      - Performance improvements for large shopping cart
        The following shopping cart commands have been optimized for performance: OrderItemAdd, OrderItemUpdate, OrderItemDisplay. These changes optimize the commands so that performance gains can be achieved, especially in cases where shopping carts typically contain hundreds of order items.
      - Enabling and disabling large shopping cart performance enhancements
        The large shopping cart performance enhancement consists of many different elements, which can be enabled or disabled separately. The enhancements are disabled by default.
      - Enabling and disabling the optimized large shopping cart order commands
        To improve the performance of large shopping carts, you can optimize the OrderItemAdd, OrderItemUpdate, OrderItemDisplay, and OrderCalculate commands.
      - Enabling and disabling the optimized tax command
        The optimized tax command provides improved performance for sites that encounter shopping carts that include hundreds of order items or more.
      - Enabling and disabling the optimized shipping calculation command
        The optimized shipping calculation command provides improved performance for sites that encounter shopping carts that include hundreds of order items or more.
  - Setting cache providers
    Starting with HCL Commerce Version 9.1, all caches are automatically configured to use the HCL Cache. However, the cache provider for each cache can be set to use the DynaCache provider, or the WebSphere Extreme Scale DynaCache provider.
  - HCL Cache
    The HCL Cache integrates with DynaCache and improves performance and scalability with features such as remote caching, real-time monitoring, and auto-tuning capabilities.
  - Experiments considerations
    When experiments that you have created in WebSphere Commerce Accelerator are running in the store, the Scheduler launches a job that determines whether any of the current experiments have expired. The job compares the expiration date specified in the experiment to the current system date. When an experiment is identified as expired, its status is updated in the database, and the experiment is prevented from displaying to customers.
  - Website performance tuning
    There are four steps for evaluating performance of an HCL Commerce website that is based on Transaction server.
  - Tuning the price rule object cache
    You can improve performance by changing the size of the cache used to store price rule business objects during storefront runtime.
  - Data Load utility performance tuning
    Scheduled Data Load utility jobs can affect HCL Commerce performance. You can reduce the impact of this process by tuning the data load performance appropriately for your implementation.
  - Workspaces performance tuning
    Workspaces use database views instead of tables to retrieve data. Retrieval of underlying data might be more time-consuming because of the complexity of SQL statements that are used in workspace view definitions.
  - Configuring custom DynaCache objects in WebSphere Liberty
    The WebSphere Liberty profile, can be configured with distributed map for the custom cache objects. To configure the custom cache objects for WebSphere Liberty in Runtime and Development, follow the steps outlined below:
  - Configuring custom DynaCache objects in HCL Commerce
    Define the custom cache in WebSphere Application Server. You can then use the cache name to store and retrieve the cache objects.
  - Preparing HCL Commerce for the peak shopping periods
    When preparing for peak shopping periods, such as the holiday season, use the following best practices to effectively manage your HCL Commerce environment for peak efficiency, and to ensure that your HCL Commerce site is ready to handle the increased load.
  - OneTest Performance sample script for Emerald B2C Store
    HCL OneTest provides software testing tools to support a DevOps approach: API testing, functional testing, UI testing, performance testing and service virtualization. This approach aids in test automation, for earlier and more frequent discovery of errors.
  - Docker performance tuning
    The following performance tuning information can be used to help you configure your containerized HCL Commerce environments for optimal performance.
  - Thread Monitor - Yaml configuration file
    The Thead Monitor tool gathers thread dumps and Javacores at a configured interval, and during events such as high WebContainer/Default_Executor pool thread usage. Yaml configuration file must exist with name /SETUP/support/thread_monitor.yaml, or under the location specified with the THREAD_MONITOR_CFG environment variable.
  - Search health check
    The search health check API is used to regularly check the status of Commerce containers to make sure they are in a healthy state.
  - Elasticsearch performance tuning
    You have numerous options when tuning the performance of NiFi and Elasticsearch. The following guide introduces tools for monitoring performance and validating key tuning parameters, and provides a performance tuning strategy that you can use with the component.
  - Optimizing index build and overall flow
    Optmizations are provided full index builds and for tuning parameters. Potential improvements that can be implimented for Near Real Time (NRT) index updates are not described.
  - Monitoring the metrics
    You can use Grafana and related tools to analyze the performance of the Ingest pipeline, and Kibana to do the same with Elasticsearch.
  - Tunable setup parameters
    How you can modify the values for the tunable parameters, and some default values and how they can be improved in different circumstances.
  - Scaling and hardware requirements
    You can achieve additional capacity by implementing or extending pod clustering on Elasticsearch, NiFi, or both. You can also consider the hardware footprint and key resources that impact the processing and index creation speed.
  - Elasticsearch with dedicated Auth and Live nodes
    For production environments, Elasticsearch is recommended in a clustered configuration for high availability and scalability considerations.
  - Recommended parameter values
    Two configurationsof the NiFi tunable parameter values are presented, a minimal and an optimal value.
  - Measurement
    As each deployment of HCL Commerce is different, a measured approach to modifying your defaults must be taken to successfully tune your site. The following collection of topics provides details on how to measure and troubleshoot site performance.
  - Emerald REST Caching On TS Server for Commerce 9.1
    Emerald Store is powered by the REST framework, and the cache is implemented using a REST servlet.
- Troubleshooting
  Topics in the Troubleshooting section highlight common issues that are encountered with HCL Commerce, and how they can be addressed or mitigated.
- Reference
  Topics in the Reference section contain all of the HCL Commerce reference documentation.

HCL Commerce Version 9.1.13.0 or later

prohibitConcurrentCacheMiss query server configuration

The new prohibitConcurrentCacheMiss has the configuration value true and is enabled by default. It can be disabled by setting it to false in the CrossTransactionCache section in the query server wc-component.json configuration file. When configured as true, the result is a decrease in the burden imposed on the ElasticSearch servers due to not repeatedly executing the same query from the same query server.

When either the CrossTransactionCache/ avoidConcurrentCacheMiss or the CrossTransactionCache/ prohibitConcurrentCacheMiss configuration value is true, a CacheEntryLock (unique for a particular cache id) is acquired before a cache miss is processed. This causes concurrent cache misses for the same cache id in the same query server JVM to wait until the thread holding the lock has finished processing the cache miss. When the waiting thread resumes, it looks in the cache to find the cache entry just placed there by the thread previously holding the lock. The effect is to avoid issuing the same query from the same query server more times than necessary, thus reducing the load placed on the ElasticSearch servers.

The CacheEntryLock can be configured with a maximum number of threads that can be waiting for the lock at any one time, and with a maximum number of seconds a thread can wait to acquire the lock. When either of those two limits is exceeded, a thread will either proceed and process the cache miss (when prohibitConcurrentCacheMiss is false) or terminate the current query server request (when prohibitConcurrentCacheMiss is true). An HTTP response code of 429 will be returned if the thread is terminated.

The CacheEntryLock is configured in the com.ibm.commerce.datatype.CacheEntryLock section of the wc-component.json configuration file.

The threshold configuration specifies the maximum number of threads waiting at any time.

The maxWaitSeconds configuration specifies the maximum number of seconds a thread can wait to acquire the lock.

For more information on the wc-component.json configuration file for the Elasticsearch query server, see Configuring Query services in ZooKeeper.