TABLE 19 – JMX SETTINGS FOR BUSINESS APPLICATION SERVER

SETTING CONTENTS

JMX Enablement System Userid Userid used for logging onto JMX Mbeans

JMX Enablement System Password Password to be used for JMX Enablement System Userid

RMI Port for JMX Business Port number to allocate to the JMX for the Business Application Server

This information is added to the spl.properties file in the etc/conf/service

subdirectory for the environment, for the Business Application Server. An example of the applicable settings is shown below:

spl.runtime.management.rmi.port=… spl.runtime.management.connector.url.default=service:jmx:rmi:// /jndi/rmi://host:…/oracle/ouaf/ejbAppConnector ouaf.jmx.com.splwg.ejb.service.management.PerformanceStatistics =enabled jmx.remote.x.password.file=scripts/ouaf.jmx.password.file jmx.remote.x.access.file=scripts/ouaf.jmx.access.file The following settings are important to the JMX monitor:

• The spl.runtime.management.connector.url.default is the JMX url to be

used in the JMX console or JMX browser.

• The jmx.remote.x.password.file and jmx.remote.x.access.file are

the default security setup for the JMX. These are for basic security setup. For more information about the files and alternative security setups refer to http://java.sun.com/javase/6/docs/technotes/guides/management/agent.html.

• The ouaf.jmx.* settings enable individual beans at startup time. These may be enabled at

runtime.

Once the Business Application Server component is started; the JMX Mbeans defined in this configuration are started and a JSR160 compliant JMX console or JMX browser can be used to connect to the JMX Mbeans. The remote URL and credentials are provided as configured above. The only Mbean available with the Business Application Server is the PerformanceStatistics

Mbean. This Mbean collects object performance data for analysis. For customer familiar with the Oracle Tuxedo product, this facility is similar to the txrpt facility available for performance analysis.

The statistics are collected by the Mbean from the time the Mbean is enabled until the environment statistics are reset. By default, the Mbean is enabled at startup time but may be disabled (or re-enabled) at any time using the disableMbean or enableMbean operations from the

PerformanceMbeanController Mbean.

When using this Mbean there are a few recommendations:

• The completeExecutionDump operation returns a CSV of the performance statistics of

individual application services to the JMX console or JMX browser. This represents the current state of the statistics at that time.

• The reset operation resets the statistics within the Mbean to start collection. This operation

is handy to ensure performance over a selected period.

• There are other operations and attributes that return individual value information that may of interest. Refer to the Server Administration Guide

Note: No confirmation (i.e. Are You Sure?) dialog is provided with most JMX consoles or JMX browser so care should be taken when issuing commands.

provided with your product for a detailed description of what statistics are available.

Replicating the txrpt statistics

One of the features customers of past releases of V1.x of Oracle Utilities Customer Care And Billing used to use to gather performance data was the txrpt facility within Oracle Tuxedo. The utility

would take performance data gathered from every service call and produce summary statistics per hour. The statistics were the number of calls and the average response time for each defined service. The

txrpt utility collected the statistics from log files that were enabled in the Oracle Tuxedo

configuration. This information was useful in tracking the performance of individual services within the product against a sites's SLA.

With the advent of Oracle Utilities Application Framework V2.x and the removal of Oracle Tuxedo from the architecture meant that this information was not available for collection as easily as originally. In Oracle Utilities Application Framework the implementation of the PerformanceStatistics

Mbean allows for collection of performance information in a similar fashion txrpt. To achieve the

• On the hour boundary the completeExecutionDump operation must be executed by

your JMX console or JMX browser to extract and save the CSV information to a file. The file should have the date and time of the collection for reference reasons.

• After collection of the statistics has been completed, the reset operation should be

executed from your JMX console or JMX browser.

• The information in the files can be collated according to the desired analysis required by your site to summarize the information. The CSV can be loaded into a database for analysis or into your sites preferred spreadsheet or analysis tool. Remember that the date and time of the collection is not recorded in the data only the data itself.

Note: While this process can be manually done using a JMX console such as jconsole, it is recommended that the JMX console or JMX browser automate the collection of the process in the background. Refer to the documentation of the JMX console and JMX browser to configure your console or browser to achieve this.

This facility is flexible for a number of reasons:

• The time period for collection is not limited to hourly as txrpt was. The time collection

period can be increased or decreased according to your site standards. For example, you might want to collect the data every 10 minutes.

• The statistics are live and can be queried regardless of the collection process.

• The level of information is higher than the original txrpt. The following additional

information is collected and summarized:

• The data is now also summarized by the type of transaction that is performed. This will allow the site to assess the performance of reads, updates, deletes, inserts etc… separately.

• The last transaction recorded is detailed including the user. This information is useful for checking against other statistics to assess where the performance is at the present moment.

• Statistics are already calculated by the utility prior to analysis. The txrpt utility only

collected the average. This facility collects the average, minimum (best case) and maximum (worst case) performance statistics in the collection period.

Database Connection Management

Hibernate, c3p0 ( ) and UCP ( ) are used to provide a pool of connections to the database for the various components of the product. A separate pool exists for online , XAIApp and background processes. The size of the pool can be set in the hibernate.properties.

The size of the pool can vary from mode of component to component with the following guidelines: • The minimum pool size of the product should be set to the average number of connections

needed for the mode of access. By default it is set to one (1) which is sufficient for non- production, but for each new connection required for the traffic the database connection needs to be established prior to use. The establishment of an individual database connection can cause delays to the transaction using the connection as it waits for the connection to be established. This negates the benefit of pooling connections. Track the number of connections used at normal traffic load and specify that as the minimum. This will establish the connections at startup time and avoid the overhead of creating connections on the fly. Ideally you want to avoid creating connections on the fly unnecessarily.

• The maximum pool value should be set to cover any peak load you may experience. Initially the values can be artificially inflated but after monitoring the number of connections open at peak times can optimize the value.

• The total number of database connections from all pools connecting to an individual database should not exceed the number of configured users/connections for that database. Exceeding the number of configuration users can cause database connection failures and delays in transactions.

• Typically customers have indicated that a good rule of thumb to use is that at any time one third of the defined users are active for normal traffic and two thirds are active at peak.

Note: This is a rule of thumb and may NOT apply to the traffic patterns at your site. It is recommended to start with an agreed value and then monitor to optimize the values as necessary.

Refer to the Batch Operations and Configuration Guide/Batch Server Administration Guide and Operations and Configuration Guide/Server Administration Guide

XPath Memory Management

for your product for additional advice on this facility.

Note: This facility is available for Oracle Utilities Application Framework V2.2 and above after installing patches 11885007 (for V2.2) or 12357553 for (V4.1).

With the popularity of the Configuration Tools facility within the product for customer extension the increase load of XPath may cause memory issues under particular user transaction conditions (in particular high volume patterns). As with most technology in the Oracle Utilities Application Framework, the XPath statements used in the Configuration Tools are cached for improved

To minimize this the Oracle Utilities Application Framework has introduced two new settings in the

spl.properties file for the Business Application Server, where the dimensions of the XPath

statement cache are defined. These settings allow the site to optimize the control the XPath cache to support caching of commonly used XPath statements but allowing for optimal specification of the cache size (to help prevent memory issues).

The settings are shown in the table below: TABLE 20 – XPATH CACHE SETTINGS

SETTING USAGE

com.oracle.XPath.LRUSize Maximum number of XPath queries to hold in cache across all threads. A zero (0) value indicates no caching, minus one (-1) value indicates unlimited or other positive values indicate number of queries stored in cache. Cache is managed on a Least Reused7

com.oracle.XPath.flushTimeout

basis. For memory requirements, assume approximately 7k per query). The default in the template is 2000 queries.

The time, in seconds, when the cache is automatically cleared. A zero (0) value indicates never auto-flush cache and a positive value indicates the number of seconds. The default in the template is 86400 seconds (24 hours).

Note: The templates provided with the product have these settings commented out. To use the settings uncomment the entries in the generated configuration files.

In most cases the defaults are sufficient but can be altered if the following is guidelines are:

• If there are memory issues (e.g. out of memory) then decreasing the LRUSize or decreasing

the flushTimeout may result in a reduction in memory issues. LRUSize has a greater

impact on memory than flushTimeout.

• If decreasing value the value of the LRUsize causes performance issues, consider changing

the flushTimeout initially only and ascertain if that works for your site.

There are no strict guidelines on the value for both parameters as cache performance is subject to the user traffic profile and the amount and types of XPath queries executed. Experimentation will assist in determining the right mix of both settings for your site.