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.
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:
Performance monitoring, tuning and bugfixing 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.
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.
ICM 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.
This simple top-level view shows three aspects that must be considered when tuning an Intershop Commerce Management system: workload, software and hardware.
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.
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.
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).
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:
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:
<iscache …> tag exists in the ISML template.
<wainclude …> tags.
A page is delivered from the page cache if the following conditions are met:
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.
The application server caches several object instances to reduce the number of database queries and file accesses.
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:
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.
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.
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.
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:
The application server settings are divided into two main areas: JVM settings and application server properties.
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.
|helm values location
|Declares the ratio of memory used for the JVM from given limits of the container/pod
|heap dump options
Enables heap dump on OOM
|Enables GC log to get detailed information from GC
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.
BETA - JobServer
With the new Job Server concept, which executes jobs assigned to the "JOB" server group in separately started scheduled K8s jobs, it is also possible to adjust the deployment configuration for the job server.
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.