How to Mitigate Business Risks with Oracle EBS Continuous Performance Testing?

How organizations mitigate business risks with Oracle EBS using performance & load tests? Why is there a renewed focus on load testing when it comes to Oracle EBS upgrades? Know about the proven solutions that can de-risk performance issues with Oracle EBS

You might be using Oracle EBS for Order management, financial, supply chain, payments, or all of these which, usually running your high value transactions which affect your organizations revenue flow. Any change / modification in any one of the modules will surely have a chance to disrupt the normal flow for the business users. This might have significant revenue and operational loss unless tackled with appropriate preventive measures / tests to avoid any untoward disruption.

Performance Testing / Load Tests checks the behaviors of the system when it is under significant load. These tests are nonfunctional and can have various forms to evaluate the reliability, stability and availability of the platform. It can also serve to investigate, measure, validate or verify other quality attributes of the system, such as scalability, reliability and resource usage. Performance testing determines the:

• Speed – Determines whether the Oracle EBS responds quickly
• Scalability – Determines the maximum user load the Oracle EBS can handle.
• Stability – Determines if the Oracle EBS is stable under varying loads

It can also serve different purposes, and demonstrate that the system meets performance criteria, can compare two systems to find which performs better for the application, and also measure which parts of the system or workload cause the system to perform badly. Hence it is highly advisable to undertake Oracle EBS Continuous Testing

Reasons for Undertaking Performance Testing

1. Upgrades of Oracle, change in EBS Application, patches and fixes, changes on the infrastructure, migration to cloud, changes in firewall settings, changes in cyber security infrastructure architecture changes, changes in global network load balancer settings, load balancer policy changes, front end middle or back end. These have potential impact on critical high-volume sessions. When do you realize the change has an impact on on Month end, quarter end, year-end also puts excessive load on systems.
2. Another important use case to apply functional and load tests is during Mergers and Acquisitions. Change in additional user or infrastructure scenarios. Best practice is to add another 20% of load to the current systems to run the tests.
3. Before you move to a cloud environment a performance test will help establish base lines for the new environment. This information is very important to the migration team before the move has been applied.

There is never a constant scenario hence performance testing becomes imperative for the organization.

Questions to Ask While Planning Oracle EBS Performance Tests

It is important to ask relevant questions in planning your Performance Testing. Few of them are:

• What is the performance test scope of work & which modules of Oracle EBS do you intend to run it on? What subsystems, interfaces, components, etc. are in and out of scope for this test?
• For the user interfaces (UIs) involved, how many concurrent users are expected for each (specify peak vs. nominal)?
• What does the target system (hardware) look like (specify all server and network appliance configurations)?
• What is the Application Workload Mix of each system component? (for example: 20% log-in, 40% search, 30% item select, 10% checkout).
• What is the System Workload Mix? [Multiple workloads may be simulated in a single performance test] (for example: 30% Workload A, 20% Workload B, 50% Workload C).
• What are the time requirements for any/all back-end batch processes (specify peak vs. nominal)?

Elements of a Performance Testing Project

Tasks to perform such a test would include:

• Decide whether to use internal or external resources to perform the tests, depending on inhouse expertise (or lack of it). Important to note would be to engage with Oracle Expert partners who would have script-less, Low-code, No code solutions to accelerate the project along with repeating the same process multiple times in the most cost effective manner.
• Gather performance requirements (specifications) from users and/or business analysts.
• Develop a high-level plan (or project charter), including requirements, resources, timelines, and milestones.
• Develop a detailed performance test plan (including detailed scenarios and test cases, workloads, environment info, etc.).
• Choose test tool(s) which best fit to cater to maximum use cases and different applications covered by the same tool.
• Specify test data needed and charter effort (often overlooked, but vital to carrying out a valid performance test).
• Develop proof-of-concept scripts for each application/component under test, using chosen test tools and strategies.
• Develop a detailed performance test project plan, including all dependencies and associated timelines.
• Install and configure injectors/controllers.
• Configure the test environment (ideally identical hardware to the production platform), router configuration, quiet network (we don’t want results upset by other users), deployment of server instrumentation, database test sets developed, etc.
• Dry run the tests – before actually executing the load test with predefined users, a dry run is carried out to check the correctness of the script.
• Execute tests – probably repeatedly (iteratively) in order to see whether any unaccounted-for factor might affect the results.
• Analyze the results – either pass/fail, or investigation of critical path and recommendation of corrective action.

Cost of running a performance test is marginal than risking it out on your critical applications.

Various Types of Performance Tests

Load testing: The simplest form of performance testing, usually done to understand the behavior of the system under a specific expected load. This load can be the expected concurrent number of users on the application performing a specific number of transactions within the set duration. This test will give out the response times of all the important business critical transactions. The database, application server, etc. are also monitored during the test, this will assist in identifying bottlenecks in the application software and the hardware that the software is installed on.

Stress Testing: Normally used to understand the upper limits of capacity within the system. This helps application administrators to determine if the system will perform sufficiently if the current load goes well above the expected maximum.

Endurance Test: Also known as Soak testing. The memory league test typically runs for a longer duration. It is run when you introduce some core changes made on your own instead of your application provider. Usually done to determine if the system can sustain the continuous expected load. During soak tests, memory utilization is monitored to detect potential leaks. Also important, but often overlooked is performance degradation, i.e., to ensure that the throughput and/or response times after some long period of sustained activity are as good as or better than at the beginning of the test. It essentially involves applying a significant load to a system for an extended, significant period. The goal is to discover how the system behaves under sustained use.

Best Practices for Performance Testing

1 Ensure you have an infra-architecture diagram ready, along with a Test Environment where you want to run these. Which is the closest replica to your production environment. If not, it is highly advisable for you to engage an expert to help you create one. Inputs from all relevant teams such as application, database, network, security will need to be given inputs.

2 Workload modeling – A snapshot on the volume of transactions that use the system during a 1-year period. If historical 1 year is not available with the database administrators? Then a 3-month period should be the bare minimum to look at. When you look at the max peaks in the workload model, this becomes inputs to take key decisions for a performance test solutioning.

3 Next steps will be to reach out to the business users for advice on changes that they expect to happen in the next 3, 6, 12 months that should be taken into account while building a performance testing solution. Are you onboarding new customers, geographies etc. e.g ERP upgrade, infrastructure changes, merger or acquisition, expansion plans etc.

Performance testing as a part of Oracle EBS Continuous testing? Is it advisable? Packaged solutions like Oracle eBS may not be advisable, until you anticipate an upcoming change as stated above. Get it done on demand.