Introduction

The performance of an e-commerce system is a key criterion of its market acceptance. End users expect fast response times when visiting a web shop, and the owner of the e-commerce application wants to optimize the costs of administering and operating the site. This concept covers the performance and scalability of an Intershop Commerce Management system. It includes coding guidelines as well as considerations for analyzing and tuning a running application.

References

• Guide - Monitoring Metrics Reference
• Concept - Cache Management
• Concept - Page Cache
• Cookbook - Cache Management
• Cookbook - Monitoring with Prometheus
• Cookbook - Performance
• Video Tutorial - Performance Monitoring (SMC)

Overview

General Considerations

Performance tuning is an overall task of any (more complex) software development process, regardless of the type of development (standard product or customer project). Performance must be considered at every line of code. Consider the interface to your implementation that describes the requirements of your code, the task itself, the responsibility of the class, and how it was implemented. This will reduce the costs of reworking significantly. Think about:

• How many database calls are necessary?
• How large is the result set of a database call?
• What is the complexity of my application server side (e.g. filters) compared to a complex query?
  • Can aspects such as domain containment be resolved before the query is executed?
  • Can complex filters that don't significantly reduce the result set be applied after the query is executed?

Performance monitoring, tuning and bug fixing is an ongoing development task. The highest priority in the Intershop development is the storefront performance, followed by import performance and back office performance. This priority is based on the fact that poor storefront performance has the greatest impact on our customers' business.

The current development process includes automated storefront performance testing of the main branch builds. All other performance testing (including import and back office) is done on demand.

Monitoring

The most important aspect of performance optimization is monitoring of application performance metrics. Do not improve performance in advance by introducing caches or reworking code to minimize effort without measuring the impact. Most performance improvements result in "unreadable" code or unintended side effects, such as when the cache is out of sync.

Intershop Commerce Management provides a set of predefined metrics to measure the behavior of the application, including response times and cache metrics. Guide - Monitoring Metrics Reference provides an overview.

As an implementation partner, you can also introduce metrics for your implemented business logic. See Cookbook - Monitoring with Prometheus for information on how to measure code executions.

Providing metrics is the preferred way over implementing "performance sensors" to monitor/measure the performance of ICM. Prometheus metrics can be read by external tools. These tools can build long-term information or alerts on top of the metric.

It is important to know numbers of metrics under different scenarios: no/low load at night, high load at daily peaks, high load on seasonal peaks. 

Tracing

Metrics can only give you a bird's-eye view on performance numbers. Operations and developers get an idea of whether the application is working well or not. If some requests are identified as possible issue, or if SQL statements are called too often, it is necessary to get a more detailed view on performance than metrics can deliver. APM tracing provides a detailed view inside the application server request.

Pipeline View	Inside Request Tracing

New Relic tracing can be enabled via deployment configuration, see newrelic section at intershop/helm-charts (GitHub). Tracing produces enormous additional data ingest and costs, and should therefore only be enabled in case developers are monitoring it.

Top Level View

This simple top-level view shows three aspects that must be considered when tuning an Intershop Commerce Management system: workload, software and hardware.

• Workload represents the sum of all requests and commands that enter the system, such as storefront HTTP requests, back office requests, service calls, or job executions.
• Software includes all Intershop Commerce Management and third-party software components, the operating systems of the machines used, and all software-related settings.
• Hardware includes all machines and infrastructure hardware that is involved.

All three aspects might cause bottlenecks and all three can be manipulated to achieve better performance. The load, for example, can be reduced by decreasing the number of clicks that are necessary for each storefront use case.

Tuning Levels

Performance tuning involves a complex set of factors. There are critical issues to address at many points in a system. Therefore, performance tuning guidelines must address a variety of issues. Performance tuning for Intershop Commerce Management can be divided into six tuning levels, as shown in the figure above. These levels cover different phases of the project. Consequently, different people may be responsible for tuning tasks at each level. Hardware sizing and hardware extensions are not included in these levels as they are considered separate topics. Extending available hardware cannot compensate for problems introduced at other tuning levels. If a bad design causes a significant slowdown, it may be virtually impossible to get better results by simply adding more hardware.

Application architecture and application design have the highest impact. Performance tuning is not just about changing settings - it is primarily about architecture and design. Mistakes made at these "higher" levels cannot be corrected or resolved by changes at a lower level.

Tuning at levels A and B is important for software engineers and Web designers who develop Intershop Commerce Management-based Web sites or Intershop Commerce Management extensions such as cartridges. Tuning at levels C, E, and F should be performed by a system administrator or someone who is experienced in configuring distributed environments. Level D tuning deals with typical database tuning and must be handled by the database administrator.

The main sections of this document describe tuning at levels A, B, C and E in detail. Database and OS (operating system) tuning is a broad topic that is not covered in this document.

Application Architecture

The primary goal of optimizing the application architecture is to reduce the workload of different parts of the Intershop Commerce Management system. The following picture shows the most general parts of the system (web layer, application server layer and data storage layer):

The upper layers provide caching capabilities to reduce the load on the lower layers. I.e., the web layer provides a page cache to reduce the load on the application server layer, and the application server layer uses caches (e.g., the ORM cache) to reduce the load on the data storage layer (e.g., the database).

It is essential for a good performance and scalability to use caches appropriately (high cache hit ration / avoid cache misses and low effort to clear caches).

Page Cache

The most important measure to achieve optimal performance is to cache as many pages or page snippets as possible. This can be done by including the <iscache ...> tag in the corresponding ISML templates. It is also advisable to choose the longest acceptable caching time for each template.

Using the page cache is the key to high performance. Typically, the page cache can deliver 10 to 100 times as many pages compared to the pages dynamically generated by the Intershop Commerce Management application server. The number of simultaneous sessions that can be served increases by the same factor.

To achieve the best results using the page cache, consider following points:

• Separate aspects that have different times to live, e.g. separate product availability or prices from static content like name, description and images.
• Avoid "personalized" page caches (which use the PGID as an additional parameter) or try to separate personalized from non-personalized snippets. This will:
  • Minimize the required disk space,
  • Improve the cache-hit ratio, since all users can use the same content snippet.

It is often possible to cache pages even if they contain information that changes from time to time. For example, if product information changes frequently and changes must be propagated quickly, the product pages can still be cached if the page lifetime is set to a sufficiently short interval, such as a few minutes. Often there is an acceptable propagation delay, and the cache hit rate is still high for the most frequently accessed products.
In production environments, a Web Adapter can typically deliver about 100 to 300 pages per second from the page cache. The achievable page rate depends on factors such as page size, number of different pages, access patterns, and hardware used.

The following conditions have to be met to write a response page into the page cache:

• A valid <iscache …> tag exists in the ISML template.
• The HTTP request method is GET.
• The status code of the application server response is HTTP 200 (OK) and the response does not contain application error headers (X-Error...).
• The page cache directory is accessible and enough disk space is available.
• Page caching is enabled for this site.
• The pipeline XML file does not contain an Interaction Continue node.
• The application server response does not contain any invalid <wainclude …> tags.

A page is delivered from the page cache if the following conditions are met:

• There is a file in the page cache that exactly matches the request URL (the session ID is ignored); the components that have to match depend on the Intershop Commerce Management version and can include:
  • Protocol (HTTP, HTTPS)
  • Hostname
  • Port
  • Path (server group, site, locale, currency, pipeline, start node)
  • Parameters and values
  • PGID
  • Site status (maintenance, disabled, live)
• The file is still valid (the file modification time is greater than the current time).
• The HTTP request method is GET.
• Page caching is enabled for this site.
• The request does not contain cache-control HTTP headers or the acceptance of these headers is switched off in the webadapter.properties.
• There is no error during opening and reading the file.
• There is no hash conflict (a hash conflict occurs if two URLs have the same MD5 hash value that leads to the same page access key; the probability for such a conflict is extremely low; hash conflicts are detected and handled by the Web Adapter).

Take into account that a different URL parameter order and different URL parameter combinations lead to different page access keys and, therefore, multiple cached pages. This applies, for example, if a particular URL parameter is sometimes omitted and sometimes not. Try to reduce the possible number of these URL variations.

Pages or parts of pages can often be cached, even if the page contains some dynamic or session-specific data elements.

Application Server Caches

The application server caches several object instances to reduce the number of database queries and file accesses.

ORM Cache

All ORM objects which are referenced within the application server are collected in the ORM engine cache. The ORM cache is not limited by the number of items, only by the size of the VM.

By default, the cache usually holds soft references to the ORM objects. The reference type can be configured for each ORM class. The following types are possible:

• HARD - the objects are not removed by the Garbage Collector (GC).
• SOFT - (default) the GC will remove instances only on GC events.
• WEAK -  the GC will remove the instance if there is no other HARD reference (e.g. held by variables).
• NONE - the ORM engine will not store the instance in the cache.

Clearing references is defined by the Java garbage collector and follows the implementation rules of a particular Java VM.

The ORM engine defines two types of caches. One cache references existing ORM objects by primary or alternate key. Optionally, there can be miss caches for each ORM object of a configurable size. The miss caches are LRU lists. If many DB misses occur for a particular ORM object, a miss cache can significantly improve system performance.

Business Caches

To increase the performance, not only for retrieving the objects from the database, ICM provides a cache API for registering, configuring, monitoring, and maintaining caches (synchronizing and clearing cache entries on different application servers) at the business logic layer.

Details how to create, use, and synchronize business caches can be found at Cookbook - Cache Management | Recipe: Introduction of an ObjectCache Using Guava. 

Application Design

This section discusses Intershop Commerce Management design and coding guidelines to meet high performance and stability requirements. The goal of performance tuning at the design level is to make pipelines and ISML templates as efficient as possible.
The basic principle is to keep things simple. This applies to both, design and coding. There is usually a way to simplify an algorithm, to shorten a code sequence, or to avoid a database access. If a required feature causes to a significant slowdown, it should be reconsidered. Also, in many cases, eliminating just a small amount of functionality can result in much better performance.

The important thing to remember is that there is always a way to build a feature for optimal performance. If you are not sure what the best performing solution is, build a small prototype and load test it with multiple parallel requests.

Configuration Adjustments

In many cases, it is better to use several smaller machines for the Intershop Commerce Management application servers, instead of one large machine. The advantage is that the Intershop Commerce Management components can be distributed to increase the availability of the cluster in case of a machine failure. However, there are also cases where larger JVMs improve performance, for example, when performing mass data imports.
Intershop recommends to install the Web Adapters, the application servers, and the Oracle database server on separate, dedicated machines to simplify resource monitoring, tuning, troubleshooting, and hardware extensions. It is also highly recommended to separate the web and application servers for performance and security reasons.
Here are a few other things to consider:

• Use separate page caches, one for each web server machine. This eliminates the overhead of shared file systems.
• Use enough RAM on the Web server/Web Adapter machines. This allows the operating system to use a sufficient amount of RAM as a file cache to cache the most frequently accessed pages.

Application Server Settings

The application server settings are divided into two main areas: JVM settings and application server properties.

JVM Settings

JVM settings are made in the deployment configuration (helm - values, see section jvm/options) for each installation. Of course, these options depend on the JVM version used.

Besides the memory settings, the GC settings are the most important.

Application Server Properties

The application server can be tuned by many configurations. The configuration can be defined by several configuration providers and can be adjusted for a specific configuration context. For details, see Concept - Configuration.

Since ICM 11, each cartridge can distribute the configuration declaration (formerly configuration.xml), allowing the implementation partner to extract the configuration to external configuration providers too.

Since ICM 7.10 each cartridge can define or override global or application specific configuration, see Concept - Cartridge for the location of configuration files.

Database Server Tuning

In general, database server tuning is done by the database administrator. Development teams can only provide meaningful defaults.

See Database cookbooks for various types of suggestions and options.