The following sections document the parameters that the Oracle Policy Automation team tune as part of their internal performance testing. The aim of this list is to provide you with an overview of the areas to tune before deploying your application into production, or when performance problems arise. We have deliberately avoided providing any actual values for these parameters, as rulebase design, server configuration, network configuration and general environmental factors can all affect performance differently, meaning that the parameters used will more than likely differ for each customer.
We recommend measuring the affect of each change, so that it can be determined whether or not the change is having a negative or positive impact on performance. It is also recommended that before deploying your application into production, general performance testing is carried out so that the overall performance of the application is known, and you can plan your resources accordingly.
For information regarding performance tuning in Oracle Policy Automation, go to:
Tune the performance of the JVM, Application Server and HTTP Server
Tune the performance of the Operating System
For suggestions regarding the performance tuning of specific applications, refer to the following topics:
Tune the performance of Web Determinations
Tune the performance of Determinations Server
Tuning the JVM settings will most likely improve overall Oracle Policy Automation performance by increasing the effectiveness of how the JVM and garbage collector operate, therefore decreasing application response times and CPU usage while increasing throughput. When tuning the JVM performance, the following should be considered:
Depending on the size and complexity of the rulebase or rulebases being used as well as the type of JVM used, increased JVM performance can be achieved by tuning the garbage collection scheme. For example a small rulebase with a large number of calculations may perform better after switching the garbage collection scheme from “generational concurrent” to “parallel” or vice versa.
Tuning the Application Server can improve Oracle Policy Automation performance by allowing an increased amount of connections to service incoming requests, resulting in a higher throughput. If the logging settings and ratio of managed servers to CPUs are optimal, it will also allow for a higher number of transactions to be processed by the application server before the requests are queued or the server returns an error when overloaded. When tuning the application server’s performance, the following should be considered:
OPA applications are 'warmed-up' after restarting / recycling the application server pool:
Whenever the application server pool is restarted or recycled, it is recommended that OPA applications are 'warmed up' before being placed under load. This will ensure there is no adverse impact on performance. To 'warm up' an OPA application, send a single request to the server to bootstrap the application and wait for a response. Once this first response has been received successfully, the application is ready to be placed under load. Failing to 'warm-up' the application prior to high load may result in an out of memory exception, because the memory requirements could be beyond those experienced under normal load for the same number of users.
If performance is not as expected and it is applicable, one area to look at early in the diagnostic process is the HTTP Server. Firstly, if possible attempt to bypass the HTTP Server by pointing the URL or endpoint directly at the managed servers and check if the performance has improved.
If bypassing the HTTP server resulted in improved performance, then you may need to tune the HTTP server settings such as KeepAlive, MaxKeepAliveRequests, KeepAliveTimeout, ThreadsPerChild, MaxClients, and MaxRequestsPerChild in the httpd.conf file, to increase performance. If tuning these settings does not improve the performance, then the problem is most likely not related to the HTTP Server and further diagnostics will be required to find the root cause.
Tuning the operating system's TCP and file descriptor settings can have a positive impact on Oracle Policy Automation performance by allowing an increased amount of throughput to the application before the system return errors and requests get queued or rejected due to overload which then causes application performance to degrade.
On Windows (2000, XP and Server 2003), there is a limitation where TCP connections from ports that are greater than 5000, result in the error message:
“An operation on a socket could not be performed because the system lacked sufficient buffer space or because the queue was full.”
A workaround for this issue has been explained in the Microsoft Knowledge Base article KB196271 (http://support.microsoft.com/kb/196271).
On AIX it is recommended that the TCP settings are tuned to increase performance; the following is a list of settings to start with initially:
Note: This is not a definitive list; it is recommended that the effect of each setting is measured so that it is known whether adjusting it has a positive or negative impact on performance. In addition to the TCP settings, some settings on the network adapter (via the chdev command) may also result in performance gains; these settings are:
Check the ulimit settings; they should be set to unlimited where applicable.
The TCP settings that should be changed from their default on Solaris systems are:
Again this is not a definitive list. It is recommended that the effect of each setting is measured so it is known whether adjusting it has a positive or negative impact on performance.
Check the ulimit settings; they should be set to unlimited where applicable (core file size, data seg size, file size, cpu time and virtual memory).