Oracle Apps Performance Testing
During one of my engagements, I was requested to come up with a strategy for performance testing Oracle E-Business suite. Client was major producer and leader of power transmission drives, components and bearings.
Client’s Oracle E-Business Suite is a complete set of business applications that enable the organization to efficiently manage customer interactions, manufacture products, ship orders, collect payments, and more.
Oracle Applications architecture is a framework for multi-tiered, distributed computing that supports Oracle Applications products. In this model, various services are distributed among multiple levels, or tiers. The tiers that compose Oracle Applications are the database tier, which manages the Oracle database; the application tier, which manages Oracle Applications and other tools; and the desktop tier, which provides the user interface display. Only the presentation layer of Oracle Applications is on the desktop tier in the form of a plug-in to a standard Web browser.
To come up with a performance strategy was a challenge to me because of their complex architecture and it was first of a kind in my organization to provide any kind of support for Oracle E-Business Suite.
Test Approach
My approach was to identify the configuration for performance testing in the test environment, for that present production configuration was analyzed to come up with a good approach.
In Production, Application and Database Tiers are present in two separate Solaris boxes and there are 6 instances which are sharing the application tier and 7 instances in DB tier. All the Instances present in the production boxes are oracle applications for different companies (Independent Entities) in that organization and all the hardware resources in the Box like CPU, Memory, and IO are shared across all the instances and the Transactions performed in the several instances are independent to each other.
Test environment which is very much similar to Production was considered for performance testing but Application tier was shared by 14 instances and Database tier was shared by 16 instances which was higher when compared to production.
First recommendation I had given was to the infrastructure team to map the number of instances similar to production in test environment.
I put forward two approaches to the client for the performance test along with the risks
Approach 1
In test environment, create the number of instances similar to prod in both App and DB tier and then analyze the work load model of each and every instance in both application as well as Database tiers and capture the important transactions for all instances and create scripts to replicate the same and execute those transactions in the background such that they utilize the hardware resources in test environment to some extent. Then simulate the work model for our instance and capture and publish the performance metrics
Risks
• Extremely difficult to understand the workload model for all the instances in the production
• Time Consuming and costly.
• Discussion required with multiple stakeholders
Approach 2
Second Approach of the performance test was to ignore the multiple instances and their transactions running in the server and dedicate the maximum amount of Hardware resources Client instance can consume in the test environment with through analysis from the existing production servers such that system utilization should not reach the identified critical level. Based on the analysis, CPU, Memory availability in the test environment should be constrained and Infrastructure Team should help in dedicating the CPU’s and Memory for client’s instance in the test environment for the performance test.
Performance test should then be carried out for the identified transactions in the workload model and capture and publish the performance metrics.
Risks
• Real time performance issues related to multiple instances may not be found
Conclusion
The above two approaches for the performance tests were discussed along with its Pros and Cons. First approach was ideal but given the timeframe available, simulating all the noise for other instances was difficult to implement and also it requires lot of coordination with multiple stakeholders. It was agreed to follow the second approach for the performance test after discussions with infrastructure team.
