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

■ the rule of thumb is if the application cannot scale on a single instance configuration when the number
of CpUs on the server is increased from two to four to eight, the application will not scale in a raC environment. on the
other hand, due the additional overhead that raC gives, such as latency of interconnect, global cache management, and
so forth, such migration will negate performance.

Caution

Getting to the Obvious
Not always do we have the luxury of troubleshooting the application for performance issues when the code is written
and before it is taken into production. Sometimes it is code that is already in production and in extensive use that
has performance issues. In such situations, maybe a different approach to problem solving may be required. The
application tier could be a very broad area and could have many components, with all components communicating
through the same persistence layer to the Oracle database. To get to the bottom of the problem, namely, performance,
each area of the application needs to be examined and tuned methodically because it may be just one user accessing
a specific area of the application that is causing the entire application to slow down. To differentiate the various
components, the application may need to be divided into smaller areas.

Divide Into Quadrants
One approach toward a very broad problem is to divide the application into quadrants, starting with the most
complex area in the first quadrant (most of the time the most complex quadrant or the most commonly used quadrant
is also the worst-performing quadrant), followed by the area that is equally or less complex in the second quadrant,
and so on. However, depending on how large the application is and how many areas of functionality the application
covers, these four broad areas may not be sufficient. If this were the case, the next step would be to break each of the
complex quadrants into four smaller quadrants or functional areas. This second level of breakdown does not need to
be done for all the quadrants from the first level and can be limited to only the most complex ones. After this second
level of breakdown, the most complex or the worst performing functionality of the application that fits into the first
quadrant is selected for performance testing.
Following the methodology listed previously, and through an iterative process, each of the smaller quadrants and
the functionality described in the main quadrant will have to be tested. Starting with the first quadrant, the various
areas of the application will be tuned; and when the main or more complex or most frequently used component has
been tuned, the next component in line is selected and tuned. Once all four quadrants have been visited, the process
starts all over again. This is because after the first pass, even though the findings of the first quadrant were validated
against the components in the other quadrants, when performance of all quadrants improves, the first quadrant
continues to show performance degradation and probably has room to grow.
Figure 1-2 illustrates the quadrant approach of dividing the application for a systematic approach to performance
tuning. The quadrants are approached in a clockwise pattern, with the most critical or worst performing piece of the
application occupying Quadrant 1. Although intensive tuning may not be the goal of every iteration in each quadrant,
based on the functionality supported and the amount of processing combined with the interaction with other tiers, it
may have room for further tuning or may have areas that are not present in the component of the first quadrant and
hence may be a candidate for further tuning.