Tune >

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.

Performance objectives include handling the following types of requests in a timely manner:

• Handle multiple customer requests

• Access data in the WebSphere Commerce database

• Format data as Web pages

• Return responses to the customer's browser

To optimize WebSphere Commerce, consider the following components:

Hardware

Make sure the system meets the minimum system requirements.

In a production environment with a lot of concurrent users, multiple processors will help increase performance. Using a faster processor will generally speed up most operations.

Database

See the IBM Redbooks - DB2 UDB V8 and WebSphere V5 Performance Tuning and Operations Guide for more information about DB2 Database tuning.

Make sure that the maximum database connection pool size is sufficient to handle all concurrent tasks (for example, HTTP connection, scheduler threads, and so on).

WebSphere Commerce

Make sure the server is I/O bound - the WebSphere Commerce system performance might be impacted if a lot of file access or network access is occurring. For example, if all logging and tracing is turned on, the system could spend most of the time writing data to the disk instead of handling the workload.

Use dynamic caching as documented in Dynamic caching.

If you are using server-based session management, see the following topics in the WebSphere Application Server Information Center:

• Tuning session management

• Tuning performance parameter index

WebSphere Application Server

See the Tuning performance parameter index topic in the WebSphere Application Server Information Center.

Connection pool size

When considering the size of the connection pool, include the following items in the calculation:

• Web container threads
• Active schedule threads
• WebSphere Commerce key manager
• WebSphere Commerce audit
• WebSphere MQ listeners
• Other multi-connection threads in the custom code

Other considerations

• WebSphere Datasource (Minimum and Maximum Connection pool size, Statement Cache Size)

• Web site design

• Security (configuration, time outs, authentication, and access control)

• Web server issues (process handling, resource usage, fast response cache accelerator)

• WebSphere engine issues (Java Virtual Machine or JVM, transport queue, the caching of JSP files, EJB container)

• WebSphere Commerce session management (caching, storing sessions in memory or storing sessions in the database)

• WebSphere Application Server session management, (setting for the in-memory session count, allow overflow, timeout interval, and Distributed Environment setting).

• NFS (Network File System) performance tuning (file server tuning)

• 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
  

• Experiments considerations
  

• 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.

+

Search Tips   |   Advanced Search