The Oracle Business Process Management Suite provides a seamless integration of all stages of the application development life cycle from design-time and implementation to run-time and application management.
This chapter contains the following sections:
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 the 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 Chapter 2, "Top Performance Areas".
This section describes the parameters you should tune when your primary objective is optimizing performance. These parameters can be tuned 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 |
|---|---|---|---|
|
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. |
|
Default: |
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:
You can also consider expanding the size of the |
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 |
|---|---|---|---|
|
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. |
|
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.
Once you have tuned the parameters listed in the previous section, consider using the following strategies to further improve performance.
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 Section 9.2.1, "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 in order 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: |
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 the 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: |
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 the web.xml:
<param-name>org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION</param-name>
<param-value>false</param-value>
|
None. |
Process Analytics uses measurement events to sample the process and publish measurements to registered consumers. In 12c (12.1.3), 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. In order 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 |
|---|---|---|---|
|
Default: |
A distributed measurement topic in a cluster installation is configured by default with |
Change the Forwarding Policy for this parameter to 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 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. |
|
Default: |
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 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. |
|
Defaults: |
Measurement messages cannot be published and fails with j |
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.
|
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. |
|
Default: MessageBuffer size 100000 |
The JMS server is frequently writing message bodies to disk. |
Increase the Message Buffer Size for a given BPMJMSServer. This will 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. |