WebSphere Commerce Payments performance tuning parameters

WebSphere Commerce Payments contains tuning parameters that allow you to control WebSphere Commerce Payments internal resource allocation.

Attention:

These parameters should only be modified by an administrator who is very familiar with WebSphere Commerce Payments. Setting either of these parameter values too high could cause performance degradation or an outright failure of WebSphere Commerce Payments at startup time.

It is highly recommended that you:

• Make changes in small increments only.

• Change only one parameter at a time; then measure the effect before making another change.

• Thoroughly test changes on a non-critical system before using them on a production system.

WebSphere Commerce Payments manages the following sets of thread pools:

Protocol thread pool

The threads in this pool are assigned the task of processing server-side protocol-specific messages within a cassette. There is one such pool for each cassette that defines its own ComPoints.

(i5/OS) The property, wpm.ppoolsize, changes the protocol thread pool size.

The pool size can be changed by completing the following steps in the WAS Administrative Console

1. Expand Servers.

2. Click Application Servers>wpm Commerce Payments Server>Process Definition>Java Virtual Machine>Custom Properties>wpm.ppoolsize.

3. Type the desired Value. The default is 8.

4. Click Apply.

Given the nature of the processing that is typically involved with server-side protocol messages (increased levels of network communication), these threads are typically held for a long time for each given request. Therefore, a cassette that relies on protocol threads to process protocol messages should be configured with a large enough protocol thread pool to accommodate a typical number of concurrent transactions involving the significant protocol messages.

Service thread pool

The threads in this pool are used by cassettes as well as the framework to perform current or future tasks in the background. The default number of threads in this pool is 6.

(i5/OS) The property wpm.spoolsize changes the Service thread pool size.

You can change the pool size by doing the following in the WAS Administrative Console.

1. Expand Servers.

2. Click Application Servers>wpm Commerce Payments Server>Process Definition>Java Virtual Machine>Custom Properties>wpm.spoolsize.

3. In the Value field, specify the desired pool size. The default is 6.

4. Click Apply.

Initially, the most common uses for service threads were to process tasks that were scheduled to execute at some point in the future. Examples of such tasks are retried transactions with the cassette's back end processor, as well as periodic maintenance tasks.

wpm.disableDuplicateOrderCheck

This parameter instructs WebSphere Commerce Payments to bypass duplicate order checking when processing a new order and eliminate access to the database. This results in higher transaction throughput. IBM recommends to use this parameter only if your merchants will not be generating duplicate order numbers. Doing so causes these orders to fail. To enable this parameter, complete the following steps through the WAS Administrative Console:

1. Expand Servers.

2. Click Application Servers>wpm Commerce Payments Server>Process Definition>Java Virtual Machine>Custom Properties.

3. Click New.

4. In the Name field, type the parameter name wpm.disableDuplicateOrderCheck.

5. Type 1 for the Value.

6. Click Apply.

Tip: Your database product may limit the number of concurrent connections that you can establish to your database at a given time. This may either be a technical limit or one imposed by the license agreement under which you purchased the database product. These factors must be considered while adjusting the preceding parameters. If you exceed such a limit by setting either of these parameters too high, the Payment Servlet initialization will fail. Related reference

• WebSphere Commerce Payments - tuning for high-performance environments