Tune > Performance

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.

Nearly all the performance tuning information can be found in the WebSphere Application Server V7 Information Center (all topics by feature; monitoring and troubleshooting; tuning performance). There are several WebSphere commerce specific minor deviations that we discuss in the following sections.

Web Container thread connection pool

Unlike the threads used by the Web server, which requires many of them to handle large quantities of relatively simple requests in a short period of time (that is, serve a .jpg file), the Application server's requests are fewer in number, more complex, and take longer to process.

WebSphere Application Server allows users to customize both the minimum and maximum size of the Web Container thread pool. The belief that having a high number of threads improves both throughput and the ability to handle a high number of concurrent users is simply not true.

In reality, with too many Web Container threads running, each processor (CPU) on the server could potentially be dealing with a large number of requests at any given time. This may result in the operating system having to spend a significant amount of time managing and switching between threads instead of processing the actual requests. Also, each additional thread consumes resources such as memory and database connections in WebSphere Application Server. These resources from extraneous threads can be used more valuably if freed up.

Of course, if the Web Container threads value is set too low, the WebSphere Application Server will not have enough workload, so the CPU will always be under utilized.

A good rule of thumb is to set the maximum value to at least 10 threads. If you have multiple processors, start with 5 threads for each CPU when configuring the Application server. For example, in a 4-way system, 20 Web Container threads should be used. Increase the maximum number of threads only when you believe CPU utilization could be higher by having additional concurrent workload.

The minimum size should be the same as the maximum size; then the application server does not need to destroy and create threads

Database connection pool

Unlike the recommendation in WebSphere Application Server's Information Center, which states that the database connection pool should be smaller than the Web Container thread pool - for WebSphere Commerce configurations, each WebSphere Web Container thread needs at least one database connection to match. In addition, when Commerce Scheduler is being used, an additional database connection needs to be reserved to ensure that the WebSphere Commerce scheduler threads function properly.

Without enough database connections in the pool, not enough threads can be utilized to serve requests, and as a result, Application Server's CPU may not be utilized completely and the throughput will not be as high as it could be.

Data source connection pool size

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

• Web container threads

• Work manager threads (4 groups for scheduler, 1 reserved group for other WebSphere Commerce tasks)

  To view and edit the WebSphere Commerce work managers:

  1. Open the WebSphere Application Server Administration Console.

  2. Navigate to Work manager.

  3. Each WebSphere Commerce work manager is listed under the WebSphere Commerce category.

  4. After clicking a work manager, you can enter the value for the Maximum number of threads property under Thread pool properties.

  5. Save the changes.

  To determine the connection pool size, this is the sum of all maximum numbers of threads in all thread pools, including work managers, web containers, and the WebSphere Commerce key manager.

  To see a list of the WebSphere Commerce work managers, launch the WebSphere Application Server Administration Console and expand Resources > Asynchronous beans and click Work Managers.

• Default thread pool

  The WebSphere Commerce reserved thread pool enables up to 10 threads by default. Within the default threads, there are threads reserved, for example, for store publishing, Listener for WebSphere MQ, schedule monitoring thread, and WebSphere Commerce audit. If you have updated the number of threads allowed for WebSphere Commerce MQ listeners, the WebSphere Commerce reserved thread pool size and database connection pool size must be updated accordingly.

• WebSphere Commerce key manager uses 1 connection

• Other threads started by the custom code using database connections

If the custom code requires database connections, or if you change the default number of connections of any of the above options, increase the database connection pool size:

1. Open the WebSphere Application Server Administration Console.

2. Navigate to Resources > JDBC > Data sources > WebSphere Commerce > db_type > DataSource > instance > Connection pool properties.

   Where db_type is either DB2 or Oracle.

3. Increase the database connection pool size by the same number of connections that have been added to all of the above options combined.

4. Save the changes.

Scheduler thread groups

The scheduler thread groups are defined in the <applicationType> element. There are two attributes:

applicationName

The identifier this thread pool. When scheduler a job in the Administration Console, this identifier will show up when you choose the application type.

maxNumofThreads

The maximum number of threads allowed for this thread pool.

Prepared statement cache

According to the WebSphere Application Server Information Center, a 10% to 20% performance improvement can be observed with the use of this parameter. To determine the right setting, the Tivoli Performance Viewer is often used to observe the behavior and minimize cache discards. However, for WebSphere Commerce, it is not an efficient mechanism because of the high number of SQL statements that are run internally.

The only reliable way to determine the optimal setting for the prepared statement cache is with an actual performance measurement in a controlled environment with repeatable workloads. The recommended initial value for the prepared statement cache is 150, and it should be increased in intervals of 50, until no more performance increase is observed.

To set the Prepared Statement Cache Size, open the WebSphere Application Server administrative console and follow these steps:

1. Select Resources.

2. Click JDBC Providers.

3. Click your_commerce_data_source.

4. Set the value for Statement Cache Size.

Related concepts

Scheduler configuration parameters

Related tasks

Define multiple threads for serial and parallel listeners

+

Search Tips   |   Advanced Search