Fusion Middleware Tuning Performance Guide
Contents
Page 23 of 30

16 Tuning Oracle Business Process Management

You can tune Oracle Business Process Management to optimize its performance in providing a seamless integration of all stages of the application development life cycle from design-time and implementation to run-time and application management.
Parent topic: SOA Suite Components

16.1 About Oracle Business Process Management

The Oracle Business Process Management Suite provides an integrated environment for developing, administering, and using business applications centered around business processes. Oracle Business Process Management is layered on the Oracle SOA Suite and shares many of the same product components, including Business Rules, Human Workflow, and Oracle Adapter Framework for Integration.

For more information on using Oracle Business Process Management, see Oracle Fusion Middleware User's Guide for Oracle Business Process Management.

For more information on tuning Oracle Business Process Management with your other Oracle Fusion Middleware components, see Top Performance Areas.

16.2 Tuning Business Process Management Parameters

You can tune BPM performance parameters in the Enterprise manager, via the SOA Administration in BPMN properties.

To tune the performance of the Oracle Business Process Management engine, you can reduce resource demands to reduce latency and increase system capacity to enable greater scalability.

To reduce resource demands, you can tune the parameters listed in Table 16-1:

Table 16-1 Essential Business Process Management Tuning to Reduce Resource Demands

Parameter Problem Tuning Recommendation Trade-offs

largedocumentthreshold

Default: 10000 (100 kilobytes)

Instances are being processed slowly because you are storing large BPMN Data objects.

Decrease the maximum size (in kilobytes) of this parameter to limit the size of BPMN Data Objects. If they surpass this limit, they are stored in a separate location from the rest of the instance scope data.

This property is applicable to both durable and transient processes.

The overflow data will be stored in an external append-only table. This adds to overall database size and can increase the overall workload when loading instances from the database.

auditLevel

Default: Inherit from Infrastructure

You are seeing frequent database inserts into the audit_trail table. These are caused by audit events being logged by a process.

Reduce or disable audit. You can switch to any of the following settings:

  • Off to log no events or audit events

  • Minimal to log only events

  • Error to log only serious problems

You can also consider expanding the size of the AuditKeyExtents.

You lose granular error reporting that you could use to diagnose problems later. Always choose the audit level according to your business requirements and use cases.

For more information on how to use audit trails for monitoring, see Monitoring BPMN Process Service Components and Engines in Administering Oracle SOA Suite and Oracle Business Process Management Suite.

You can also try to purge completed instances as allowed by business requirements and add indexes for any flex fields.

Increasing system capacity should only be done based on analysis of performance testing results. Adjustments should not be made unless testing indicates that they are a constraint on scale. To increase system capacity, you can tune the parameters listed in Table 16-2:

Table 16-2 Essential Business Process Management Tuning to Increase System Capacity

Parameter Problem Tuning Recommendation Trade-offs

DispatcherEngineThreads

Default: 2 threads

System dispatcher messages are general clean-up tasks that are typically processed quickly by the server (for example, releasing stateful message beans back to the pool). Typically, only a small number of threads are required to handle the number of system dispatch messages generated during run time. You may need to tune this parameter if you have either of the following problems:

You do not have enough threads. CPU utilization remains low

OR

You have too many threads. Context switching drives up CPU use but does not increase throughput.

Increase the thread pool sizes for the respective workload based on thread pool usage.

If you see a backlog of requests and additional CPU capacity, then consider increasing the number of threads.

Increasing the size of the thread pools will increase CPU utilization and garbage collection. However, if there are other application that share the same platform and expect to have access to additional CPU capacity, then that could cause a conflict.

DispatcherInvokeThreads

Default:20 threads

Invocation dispatcher messages are generated for each payload received and are meant to instantiate a new instance. You may need to tune this parameter if you have either of the following problems:

Threads are busy but CPU utilization remains low.

OR

You have too many threads. Context switching drives up CPU use but does not increase throughput.

Increase the thread pool sizes for the respective workload based on thread pool usage.

If you see a backlog of requests and additional CPU capacity, then consider increasing the number of threads.

Increasing the size of the thread pools will increase CPU utilization. However, if there are other application that share the same platform and expect to have access to additional CPU capacity, then that could cause a conflict.

You can also try to increase the size of connection pools and optimize the use of connections.

16.3 Using Other Tuning Strategies

Once you have tuned the parameters listed in Tuning Business Process Management Parameters, consider using the following strategies to further improve performance.

16.3.1 Tuning Oracle Workspace Applications

Database performance and session state management are the primary drivers for performance. Effective database tuning and configuration of HTTP session timeout are important.

Application design is the next largest factor, especially if there are additional data controls used to render contextual data on task forms. In those cases, it is important to optimize data access from those data controls and when possible defer retrieving additional data unless it is needed. For more details on tuning ADF, see Oracle ADF Faces Configuration and Profiling.

The following parameters can be changed in the web.xml descriptor in the OracleBPMWorkspace web application. Once they have been modified, you may have to redeploy.

Parameter Problem Tuning Recommendation Trade-offs

HTTP Session Timeout

Default: 15 minutes

Memory is being allocated for users who may no longer be actively using the system.

To better manage resource usage, decrease the session timeout value, in minutes, to the smallest value that preserves the expected user experience. This allows the system to reclaim any resources associated with unused sessions as soon as possible.

This parameter is edited in the in the web.xml file. The following is a sample snippet of web.xml:

<session-config>
    <session-timeout>
       5
    </session-timeout>
</session-config>

A short timeout value may mean users will have to login ore often if they let the time expire. They also may potentially lose session data.

ADF Client State Token

Default: 15

The default value may consume too much memory.

Decrease the value to 3 to minimize the memory footprint.

Through this setting, you can control the number of pages users can navigate using the browser Back button without losing information. To reduce CPU and memory usage, you can decrease the value in the web.xml file.

The following is a sample snippet of web.xml:

<context-param>
   <param-name>       
org.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS
   </param-name>
   <param-value>
      3
   </param-value>
</context-param>

If the user clicks on the 'Back' button more than 3 times, there will be no session data stored for that page.

If the value is too small, users will get an error using the back button.

Compress_View_State Token

Default: True

Slow performance on slower/higher latency networks.

Keep the default to keep zipping enabled.

This setting controls whether or not the page state is compressed. Zipping greatly reduces the memory being taken up by page state in the session object.

The following is a snippet of web.xml:

<param-name>org.apache.myfaces.trinidad.COMPRESS_VIEW_STATE</param-name>
 <param-value>true</param-value>

There is an additional CPU cost to zipping and unzipping the view state.

DISABLE_CONTENT_COMPRESSION

Default: False

Slow initial load of pages.

In production environments, make sure you remove the DISABLE_CONTENT_COMPRESSION parameter from the web.xml file or set it to FALSE. By default, style classes that are rendered are compressed to reduce page size.

The following is a snippet of web.xml:

<param-name>org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION</param-name>
 <param-value>false</param-value>

None.

16.3.2 Tuning Process Measurement

Process Analytics uses measurement events to sample the process and publish measurements to registered consumers. In 12c (12.2.1.1), these measurements can be enabled by setting the DisableAnalytics parameter to False in the BPM Enterprise Manager's Analytics Configuration MBean.

The two supported consumers for measurements in 12c are BAM 11g Monitor Express and BAM 12c Process Metrics. They can enabled or disabled using the DisableProcessMetrics and DisableMonitorExpress attributes of the AnalyticsConfig mbean.

Note:

Only data that is useful should be published. The process design specifies what data (dimensions, measure, counters) should be published and at what point(s). If data is being generated that is not useful, then it could be adding unnecessary load to the system.

Measurement events are published on the JMS Topic: MeasurementTopic, and consumed by registered Action MDBs. To tune JMS for Measurements, consider changing the parameters listed in Table 16-3, as needed, in a high volume environment:

Table 16-3 Essential JMS Resource Tuning for BPM

JMS Resource Problem Tuning Recommendation Trade-offs

dist_MeasurementTopic_auto

Default: Forwarding Policy Replicated

A distributed measurement topic in a cluster installation is configured by default with FORWARDING POLICY REPLICATED even though this is not the best performance option for BPM analytics.

Change the Forwarding Policy for this parameter to PARTITIONED.

This parameter can be altered in the WebLogic console. You can find it from the front page with the following options: JMS Modules -> BPMJMSModule -> dist_MeasurementTopic_auto. You will need to restart all SOA BPM cluster nodes for the changes to take effect.

A distributed topic with a Partitioned policy generally outperforms the FORWARDING POLICY REPLICATED.

For more information on distributed topics versus other topic types, see Supported Topic Types in Developing Message-Driven Beans for Oracle WebLogic Server.

For more information on partitioned and replicated forwarding policies, see Configuring Partitioned Distributed Topics in Administering JMS Resources for Oracle WebLogic Server.

MeasurementTopicConnectionFactory

Default: Send Timeout 200000

You have a high volume environment and you are receiving frequent resource allocation exceptions from message producers.

For more information, see Defining a Send Timeout on Connection Factories in Tuning Performance of Oracle WebLogic Server.

Increase the Send Timeout for this parameter to 240000 in a high volume environment.

The numerical value represents the maximum length of time in milliseconds.

This parameter can be altered in the WebLogic console. You can find it from the front page with the following options: JMS Modules -> BPMJMSModule --> MeasurementTopicConnectioNFactory --> Default Delivery.

You may create a message backlog that consumes memory and resources.

MeasurementQuota

Defaults: Message Maximum 1000000 and Bytes Maximum 800000000

Measurement messages cannot be published and fails with javax.jms.ResourceAllocationException thrown.

Set the Message Maximum and Bytes Maximum for this parameter equal to the amount of system memory available after you have accounted for the rest of your application load.

MeasurementQuota attributes can be altered in the WebLogic console. You can find it from the front page with the following options: JMS Modules -> BPMJMSModule -> MeasurementQuota.

Increasing this value consumes more memory. Message delivery may still fail if the aggregate size of messages pushed to the consumer is larger than the current protocol's maximum message size.

For more information about measurement quotas, see Tuning for Large Messages in Tuning Performance of Oracle WebLogic Server.

BPMJMSServer

Default: MessageBuffer size 100000

The JMS server is frequently writing message bodies to disk.

Increase the Message Buffer Size for a given BPMJMSServer.

Note that the BPMJMSServer uses Paging File and JMSFileStore.

This parameter can be altered in the WebLogic console. You can find it from the front page with the following options: JMS Servers_auto_number.

The JMS server will use more memory.