Home
User Guide
The information contained in this section applies to WebSphere Commerce Version 8. The documentation also applies to all subsequent releases and modifications until otherwise indicated in a newer section.WebSphere Commerce is a single, unified e-commerce platform that offers the ability to do business directly with consumers (B2C), directly with businesses (B2B), and indirectly through channel partners (indirect business models). WebSphere Commerce is designed to be a customizable, scalable, and high availability solution that is built to leverage open standards. 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.
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 WebSphere Commerce deployment.
Measurement
As each deployment of WebSphere 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.
Performance Measurement tool
As a developer, you can use the Performance Measurement tool to gather performance data on a running application to help you identify any performance bottlenecks. You can use this tool in both your development environment to test operation performance, and in your production environment to analyze the actual performance of an operation. When you run this tool, you can generate different reports to help you identify operations that impact performance and determine how to improve caching performance.
Caller reports
You can use the Performance Measurement tool to generate caller reports, which identify the source of the calls to run an operation. With these reports, you can analyze operations and identify the sources for numerous calls for the operation to run.

User Guide
The information contained in this section applies to WebSphere Commerce Version 8. The documentation also applies to all subsequent releases and modifications until otherwise indicated in a newer section.WebSphere Commerce is a single, unified e-commerce platform that offers the ability to do business directly with consumers (B2C), directly with businesses (B2B), and indirectly through channel partners (indirect business models). WebSphere Commerce is designed to be a customizable, scalable, and high availability solution that is built to leverage open standards. 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.
- Planning
  Creating a custom implementation of a WebSphere Commerce store requires a significant amount of planning. From gathering client needs, to deploying the live solution, much work is needed to successfully deploy a custom client store. Use the resources in here to help you plan every phase of store creation.
- Installing
  Review the following sections for information about installing the WebSphere Commerce product, associated maintenance, and WebSphere Commerce enhancements.
- Migrating
  Before you migrate to WebSphere Commerce Version 8.0, review this information to help plan and execute your migration.
- Deploying
  The topics in this section describe how to publish stores to either a test or production environment, and how to deploy customized code.
- Operating
- Integrating
  Topics in the Integrating category highlight the tasks that are commonly performed for using WebSphere Commerce in combination with other products.
- Administering
- Tutorials
  WebSphere Commerce provides many tutorials to help you customize and understand your WebSphere Commerce instance and stores.
- Samples
- Developing
  The topics in the Developing section describe tasks performed by an application developer.
- Compliance
  The following section describes how you can leverage WebSphere Commerce features and functionality to help your site be compliant with different privacy and security standards.
- Securing
  These topics describe the security features of WebSphere Commerce and how to configure these features.
- Performance
  - Performance enhancements
    Learn about the new features and functions that are offered by WebSphere Commerce Version 8 to improve your 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 WebSphere 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.
    - Operating system considerations
      Make sure that your system meets the minimum operating system requirements. In a production environment with numerous concurrent users, multiple processors help increase performance. In addition to using faster processors to speed up most operations, there are other areas to consider when you want to improve operating system performance.
    - 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.
    - WebSphere Application Server considerations
      WebSphere Commerce Server is ultimately another Java 2 application that runs on top of WebSphere Application Server. As a result, WebSphere Application Server acts as the operating system for WebSphere Commerce. Having the WebSphere Application Server properly optimized improves the performance of WebSphere Commerce.
    - Tuning
      A WebSphere 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.
    - Measurement
      As each deployment of WebSphere 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.
      - Performance Measurement tool
        As a developer, you can use the Performance Measurement tool to gather performance data on a running application to help you identify any performance bottlenecks. You can use this tool in both your development environment to test operation performance, and in your production environment to analyze the actual performance of an operation. When you run this tool, you can generate different reports to help you identify operations that impact performance and determine how to improve caching performance.
        Using the Performance Measurement tool
        Use the Performance Measurement tool to generate reports to help you analyze your cache settings and performance. By generating and analyzing these reports, you can change your caching to improve your cache performance.
        Performance reports
        You can use the Performance Measurement tool to generate performance reports for operations. You can use performance reports to measure the impact that your caching practices have on your system performance. You can then analyze these reports to help you adjust your caching to improve performance.
        Stack reports
        You can use the Performance Measurement tool to generate stack reports. Stack reports include the measurements for the stack of operations that are used when you run a sample operation.
        Execution reports
        You can use the Performance Measurement tool to generate execution reports. Execution reports include the measurements for a single execution stack.
        Caller reports
        You can use the Performance Measurement tool to generate caller reports, which identify the source of the calls to run an operation. With these reports, you can analyze operations and identify the sources for numerous calls for the operation to run.
      - Data recording; improving runtime performance
        Two options are provided which can improve runtime performance regarding the recording of user behavior data.
- Troubleshooting

Caller reports

You can use the Performance Measurement tool to generate caller reports, which identify the source of the calls to run an operation. With these reports, you can analyze operations and identify the sources for numerous calls for the operation to run.

Each caller node within a caller report contains the following information:

<caller
call-count="20"
average-call-count="1.00"
operation-name="child"
average-duration-ms="25"
average-size="1577"
unique-caller-count="4.0">

Where,

call-count: The number of times that this operation executes and results in a call to the identified operation.
average-call-count: The number of times that the operation is called during each execution of the parent caller operation.
operation-name: The operation name. For example, "child".
average-duration-ms: The average duration of the operation.
average-size: The average result size of the operation.
unique-caller-count: The number of unique executions of the identified operation. This number is usually a fraction of the call-count value. For instance, in this sample, out of 20 execution of the operation, 4 of executions used a unique combination of key and value parameters. This number means that 16 executions could potentially result in cache hits.

Sample

The following code is a sample caller report.

<caller call-count="20" average-call-count="1.00" operation-name="child">
<caller call-count="10" average-call-count="1.00" operation-name="parent-1" />
<caller call-count="5" average-call-count="2.00" operation-name="parent-2" />
</caller>

This sample identifies that the following operation calls occurred:

The "child" operation was called 20 times in total.
The "child" operation was called 10 times by the operation "parent-1" with a relationship of 1 to 1.
The "child" operation was called 10 times by the operation "parent-2" with a relationship of 2 to 1. This result means that on average, each execution of the "parent-2" operation resulted in 2 executions of the "child" operation.