Methodology - Expert Oracle RAC Performance Diagnostics and Tuning - page 3

4. The peak time for report back transactions is from midnight to 2 AM.

5. Peak times for input transactions are Monday and Friday afternoons from 3 PM to 5 PM.

6. The number of smart cards is estimated to double in 3 years.

Based on an 18-hour day (peak time = 5 times average rate), today 3.5 messages are processed per second. This is
projected to increase over the next 2 years to 69 messages per second.
Table 1-1 gives a few requirements that help in

1. sizing the database (Requirement 1 and 6);

2. planning on the layout of the application to database access (Requirement 5); and

3. allocation of resources (Requirements 4 and 5).

These requirements with the expected transaction rate per second helps the performance engineer to work
toward a goal.
It's a truism that errors made during requirements definition are the most expensive to fix in production and
that missing requirements are the hardest requirements errors to correct. That is, of all the quality defects that might
make it into a production system, those that occur because a requirement was unspecified are the most critical. To
avoid these surprises, the methodology should take into consideration testing the application code in iterations from
complex code to the least complex code and step-by-step integration of modules when the code is optimal.
Missing detailed requirements lead to missing test cases: if we don't identify a requirement, we are unlikely to
create a performance test case for the requirement. Therefore, application problems caused by missing requirements
are rarely discovered prior to the application being deployed.
During performance testing, we should create test cases to measure performance of every critical component
and module interfacing with the database. If the existing requirements documents do not identify the performance
requirements for a business-critical operation, they should be flagged as “missing requirement” and refuse to pass the
operation until the performance requirement is fully identified and is helpful in creating a performance test case.
In many cases, we expect a computer system to produce the same outputs when confronted with the same
inputs—this is the basis for most test automation. However, the inputs into a routine can rarely be completely
controlled. The performance of a given transaction will be affected by

• The number of rows of data in the database

• Other activity on the host machine that might be consuming CPU, memory, or performing

disk input/output (I/O)

• The contents of various memory caches—including both database and operating system (O/S)

cache (and sometimes client-side cache)

• Other activity on the network, which might affect network round-trip time

Unless there is complete isolation of the host that supports the database and the network between the
application client (including the middle tier if appropriate), you are going to experience variation in application
performance.
Therefore, it's usually best to define and measure performance taking this variation into account. For instance,
transaction response times maybe expressed in the following terms:

1. In 99% of cases, Transaction X should complete within 5 seconds.

2. In 95% of cases, Transaction X should complete within 1 second.

The end result of every performance requirement is to provide throughput and response times to various user
requests.