There are multiple ways to achieve the desired performance level in OPPM. Your organization can determine this based on the following factors:
- Desired level of performance
- Availability requirements
- Short-term or long-term outlook of system usage
- Number of concurrent users
- Usage of workflows and the complexity of those workflows
- Dependency of workflows decision routes on calculations done by function engine
- Frequency of refresh required for portfolios and OBP
- Number of summary portfolios and summary functions
- Number of actions triggered per hour
- Cells calculation per hour
- The complexity (normal/advance type) of functions
As the demand for the application grows, additional nodes (front-end, secondary back-end, and database RAC node) can be added. An increase in secondary slaves may impact database resources.
A detailed list of data set is available in Appendix A.
Vertical Scaling (Scaling Up)
Vertical scaling involves additional resources or upgrading resources on an existing system. Vertical scaling is typically a good approach if the application bottlenecks are processor and memory-related.
Hardware Upgrade
Desired performance and scalability can be achieved by upgrading the CPU, adding extra cores, adding physical memory, or upgrading to faster I/O devices. Oracle recommends 64-bit hardware.
Operating System Upgrade
The desired performance level can be attained by upgrading to latest version of the operating system and installing the latest patch updates. Oracle recommends using 64-bit software. For the full list of system requirements, applications, and application version levels refer to the Tested Configurations document in the OPPM documentation library.
While vertical scaling is easier to achieve, it does not completely address availability. If the desired level of availability is high, then vertical scaling alone is not sufficient.
Horizontal Scaling (Scaling Out)
As the demand for the applications grows, additional nodes (front-end and secondary back-end) can be added to an existing server cluster to handle the increased system load and processing of functions. For high availability requirements, horizontal scaling is a more favorable option. From our test results it is observed that adding multiple secondary subordinate servers along with adding database server (RAC nodes) has shown optimal performance.
Note: One slave can be used for each CPU core. For example, a quad-core CPU can have up to four subordinates in the secondary server.
Database Scaling and Clustering
Database server scaling options are available and have been widely adopted and implemented. Database clustering enables multiple nodes in a clustered system to mount and open a single database that resides on shared disk storage. This configuration provides high availability in the database environment. Oracle Real Application Clusters (RAC) is an example of database clustering. Similarly, MSSQL server uses Microsoft clustering for resource allocation. You should consult a SQL database expert to discuss how clustering can help with shared resources for increased performance.