|Oracle® Fusion Middleware Performance and Tuning Guide
11g Release 1 (11.1.1)
Part Number E10108-04
|PDF · Mobi · ePub|
This chapter describes how to tune the Oracle Business Activity Monitoring (BAM) dashboard application for optimal performance. Oracle BAM provides the tools for monitoring business services and processes in the enterprise.
This chapter discusses useful parameters that can be modified to enhance the overall performance of BAM:
Oracle Business Activity Monitoring (BAM) provides the tools for monitoring business services and processes in the enterprise. It allows correlating of market indicators to the actual business process and to changing business processes quickly or taking corrective actions if the business environment changes. Oracle BAM also provides the necessary tools and run-time services for creating dashboards that display real-time data inflow and define rules to send alerts under specified conditions.
For more information see Oracle Fusion Middleware User's Guide for Oracle Business Activity Monitoring.
The following sections provide Oracle BAM tuning considerations that can be used to address performance issues:
The following tuning configurations can be used to improve performance of the BAM Server:
ViewSetSharing parameter can be set to
FALSE in the BAM server configuration file. This parameter enables view set sharing when possible. Typically a particular view set can be shared with other users if they are trying to access the same dashboard, if the view sets are not dissimilar due to factors like row level security or prompts/parameters tied to filters.
Consider setting the
ViewSetSharing parameter to
TRUE so that Active Data Cache (ADC) can reuse the same viewset and snapshot and avoid creating more viewsets. This reduces the BAM server resource usage and improves user response time.
If this parameter is turned on, it does not always guarantee that ADC can reuse the existing viewset. If there have been too many changes to the underlying snapshot for the existing viewset, ADC may choose to create new viewset instead.
The ReportCache parameter used to determine if there have been too many changes is
ElementsCountLimit. This defines the number of changes to the snapshot used by Report Cache to do the determination. In cases where the active data comes in at a fast rate, try to set this parameter to a large number so that ADC can use view sharing at the expense of more server CPU usage. The default value of
ElementsCountLimit is 50.
During periods of higher active data rates, the browser uses more memory. To prevent potential impacts to performance, consider providing more memory on the client machine. To do this, set the
UseAsynchServlet=TRUE for the BAM dashboard application.
The BAM dashboard application uses the Async servlet feature so that the BAM server does not bind a specific thread to a specific user request. This provides for better server-side system resource usage.
This parameter can be turned off by adding
UseAsynchServlet=FALSE in the server configuration file. During debugging, consider turning it off to make the process easier.
Otherwise this should always be turned on, which is the default.
See "Creating the Dashboard View" in Oracle Fusion Middleware User's Guide for Oracle Business Activity Monitoring.
This section provides information on tuning the BAM dashboard for performance.
The Active Data Retrieval Interval parameter controls the rate in milliseconds at which the Oracle BAM Active Data Cache (ADC) pushes events to the Oracle BAM Report Server. This is one of the factors that can affect the frequency of viewing active events on the dashboard page. Increasing this interval reduces the load on the Oracle BAM Server. Note that larger intervals increase the likelihood of multiple updates in the dashboard collapsing into a single update.
ADCPushInterval value is 1 second. You can override the default
ADCPushInterval value within a particular report using the Active Data Retrieval Interval property in Active Studio.
For more information on using Active Studio, see "Getting Started With Oracle BAM Active Studio" in Oracle Fusion Middleware User's Guide for Oracle Business Activity Monitoring.
To achieve the best performance for Oracle Business Activity Monitoring, consider maintaining a database on its own hardware dedicated to the Oracle Business Activity Monitoring system. General database administration practices, as described in the Oracle Database Performance Tuning Guide, also apply to a database dedicated to Oracle Business Activity Monitoring.
For more information on general database configurations, see Section 2.6, "Tune Database Parameters".
This section provides performance tuning configurations for Internet browsers:
BAM sends active data in <script> blocks to the browser over a persistent connection. In some cases, the browser does not free up the memory used by the <script> blocks. This can impact dashboard performance over time.
iActiveDataScriptsCleanupFactor parameter provides a solution for these memory issues. A periodic browser refresh is forced after receiving the specified number of characters. The issue may become apparent when active data is being sent to the dashboard at a fast pace. You may need to increase this value further for particularly high rates of data such as when active data is coming to the dashboard at a rate of 25 events per second or greater. Ultimately the value you set depends on factors like your data, number of views, number of viewsets, ADCPushinterval, and so on). You can monitor the browser's memory consumption to help determine an appropriate value.
If performance continues to be an issue, consider increasing the value for this parameter. For example, set the value to 2 or 3 times the default value if active data is predicted to increase. The default value for this parameter is 1048576 bytes. The default value often prevents frequent reconnects and prevents CPU/memory on the client machine from creeping up too high.
BAM Enterprise Message Source (EMS) provides inbound JMS connectivity to BAM. After setup, a BAM EMS instance can monitor JMS queues/topics and read data from them. Each EMS instance is configured to publish data to a single Data Object in BAM Server. The Enterprise Message Source supports four types of operations: Insert, Update, Upsert, or Delete. Two types of JMS messages are supported: MapMessage and TextMessage.
The EMS batching process clubs messages into one single message before it is sent to BAM EMS. This feature enables the sender to send all messages in one batch over JMS. The batching process can improve network performance by limiting the number of round trips from the sender to JMS server to BAM EMS.