Performance tuning
- Performance
WebSphere Commerce is a complex interaction between a number of products. Each product has its own performance characteristics and within the interaction of the various components, there are a number of places where performance can be affected by incorrect configuration or insufficient resources.
- Disable summary tables
This feature is used to optimize the performance of WebSphere Commerce searching. If search feature is not used, do the following to save some database resource and disable the summary tables:
- Performance monitoring using the WebSphere Commerce PMI module
You can monitor the performance of the WebSphere Commerce system by using the WebSphere Application Server Performance Monitoring Infrastructure (PMI). When users administer WebSphere Commerce, they can monitor the system based on the infrastructure provided by WebSphere Application Server and can monitor URLs and task commands by checking additional WebSphere Commerce counters.
- JVM performance tuning
For improved performance, JVM settings require careful tuning. You might need to tune the 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 WebSphere Commerce as a starting point.
- Database (DB2) performance considerations
The database is usually one of the potential areas for bottlenecks that makes WebSphere Commerce unable to scale and perform well. It is therefore crucial that the database be tuned appropriately for the implementation.
- Database (Oracle) performance considerations
The database is typically one of the potential areas for bottlenecks that makes WebSphere Commerce unable to scale and perform well. It is therefore crucial that the database is tuned appropriately for the implementation.
- Operating system considerations
Here are some of the performance considerations at the moment of tuning any Commerce Web site from the operating system level.
- Performance methodology
There are four steps for evaluating performance of a WebSphere Commerce site based on WebSphere Commerce Server.
- Web server considerations
Even though the Web server is a very mature technology, it can still be tuned to get better performance, especially on large Web sites. This section covers the common performance considerations for all the Web servers, and is platform independent.
- WebSphere Commerce considerations
Surprisingly, WebSphere Commerce by itself does not have too many performance tuning knobs. It makes a lot of sense if you treat WebSphere Commerce just like a J2EE application that consists of business logic and relies on WebSphere Application Server to provide the core function to make WebSphere Commerce performs well.
- 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 will improve the performance of WebSphere Commerce.
- Statistics considerations
Operational marketing statistics are gathered and stored in the database by the RaiseECEvent scheduled job which is run by the Scheduler at a set interval. By default, this job runs every 5 minutes. If decrease the frequency of this job to reduce any performance impact it might have, you can increase the interval between the jobs.
- Experiments considerations
When experiments are running in the store, the Scheduler launches a job that determines whether any of the current experiments have expired. The job simply 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.
- Optimistic locking
Optimistic locking allows you to lower the isolation level that you use in an application so that fewer locks are placed on the database assets. It allows more applications to run concurrently against the database, and potentially increase the throughput of the applications.
- Recover from transaction failures due to optimistic locking
There are three main strategies that you can use to recover from failing transactions if there are collisions in the database due to optimistic locking: Serialization, Retry, Do nothing. These strategies are contingent on the relative importance or criticality of the transaction in question.
- Install and configuring Composite Application Manager for WebSphere, v6.1 to monitor WebSphere Commerce
IBM Tivoli Composite Application Manager for WebSphere monitors WebSphere Application Server-based J2EE applications. This topic describes how to deploy Tivoli Composite Application Manager to monitor a WebSphere Commerce site.
- Management Center search tables
The Management Center is a search intensive application, and you can tune the database to improve search performance if you know the tables and columns it uses.
- Improve performance affordably with WebSphere eXtreme Scale V7.0
WebSphere eXtreme Scale is IBM's next generation distributed caching solution based on an in-memory grid that dynamically processes, partitions, replicates, and manages data and business logic across hundreds of servers to support the most demanding business applications.