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.

Nearly all the performance tuning information can be found in the WebSphere Application Server, Version 8.5.5 documentation (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 that are 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 on the server could potentially be dealing with many requests at any one 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 inWebSphere Application Server. These resources from extraneous threads can be used if freed up.

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 processor utilization could be higher by having extra 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

When you consider the size of the connection pool, include the following items in your calculation:
  • Web container threads
  • Active schedule threads
  • WebSphere Commerce key manager
  • WebSphere Commerce audit
  • IBM MQ listeners
  • Other multi-connection threads in your custom code

Database connection pool

Note: The following sections describe how to allocate a large enough JDBC connection pool that no WebSphere Commerce thread will have to wait for a connection. Alternatively, there is a WebSphere Application Server iFeature that can allow WebSphere Commerce to run with smaller JDBC connection pools. For more information about using this iFeature, see Reducing JDBC connection pool sizes using reserve pool.

WebSphere Application Server documentation states that the database connection pool should be smaller than the web Container thread pool. However, this is not the case for WebSphere Commerce configurations. For WebSphere Commerce configurations, each WebSphere Web Container thread needs at least one database connection to match. In addition, when the WebSphere Commerce Scheduler is used, an additional database connection must be reserved to ensure that the WebSphere Commerce scheduler threads function properly.

Without enough database connections in the pool, not enough threads can be used to serve requests. As a result, the application server processor might not be used completely and the throughput is not as high as it could be.

Data source connection pool size

When you consider the size of the connection pool, include the following items in your calculation:
  • Web container threads
  • Work manager threads (four groups for scheduler, one 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. Browse to Work manager.
    3. Each WebSphere Commerce work manager is listed under the WebSphere Commerce category.
    4. After you click a work manager, you can enter the value for the Maximum number of threads property under Thread pool properties.
    5. Save your 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, Open the WebSphere Integrated Solutions 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 IBM MQ, schedule monitoring thread, and WebSphere Commerce audit. If you have updated the number of threads that are allowed for WebSphere Commerce IBM MQ listeners, the WebSphere Commerce reserved thread pool size and database connection pool size must be updated accordingly.

  • WebSphere Commerce key manager uses one connection
  • Other threads started by your custom code using database connections
Important: If your custom code requires database connections, or if you change the default number of connections of any of the above options, you must increase the database connection pool size:
  1. Open the WebSphere Application Server Administration Console.
  2. Browse to Resources > JDBC > Data sources > WebSphere Commerce > db_type > DataSource > instance_name > 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 you added to all of the above options combined.
  4. Save your changes.

Scheduler thread groups

The scheduler thread groups are defined in the <applicationType> element. There are two attributes:
applicationName
The identifier of the thread pool. When you schedule a job in the Administration Console, the identifier is displayed after you select the application type.
maxNumofThreads
The maximum number of threads that are allowed for the thread pool.

Prepared statement cache

According to the WebSphere Application Server documentation, 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 theWebSphere 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.