Testing for Scalability - Expert Oracle RAC Performance Diagnostics and Tuning - page 102

# of DB Servers : How many database servers were involved in the test? Remember, this is a
scalability test, and it is important to understand the number of users to server ratio.

# of App Servers : Similar to the number of database servers, it's good to record the number
of application servers involved in the test.

Test : What is the goal of this test? What should the expected resultsbe from this test?

Description : Details of the findings and or errors are noted in this column.

Status : The results noted in this column should be relative to the goal of the test listed in the
“Test” Column. For example, the first test is to capture a baseline based on the performance
numbers and business requirements. If the number of users could withstand the duration
of the test and the test was able to provide the required response time, the result will be
“Success.”

Step 4
From our previous tests, we have several baselines; however, these baselines are not close in comparison to the
baseline of the current production environments. Normally we would like to see performance and response times
equal to or better from the new servers. If this is not the case, there should be sufficient justification for moving
to the new configuration, such as cost saving, for example, migrating from a HP Superdome to a multinode Linux
configuration.
As illustrated in Table 4-6 , the test failed 10 minutes after start. Based on the number of users and the number of
database servers used in this test, the results were as expected.

Table 4-6. RAP Phase VII—Load Test on One Server

Test # Date & Time # of Users Test

Duration

# of Db
Servers

# of App
Servers

Description Status

1 10-Aug-xxxx

10:00 am

40 60 minutes.

Failed @ 10
minutes

1 6 Slow performance. Failed

after 10 users. System
saturated with overworked
CPU.

FAILED

Step 5
The hardware configuration determined during capacity planning exercises for this production hardware was
a 4-node, 4*4 servers to map to one HP superdome. Although it was a good idea to see how the one server will
withstand the workload, should all the remaining servers in the new production server fail,in fact it may be worth
testing with 1, 2, and 3 nodes to determine the business impact if this were to happen after implementing the new
hardware into production.
Continuing with the scalability testing, the cluster was changed to a 4-node configuration. Table 4-7 illustrates
the test and the results from the 4-node configuration test.