28 Capacity Planning

Capacity Planning is the process of determining what type of hardware and software configuration is required to meet application needs. Like performance planning, capacity planning is an iterative process. A good capacity management plan is based on monitoring and measuring load data over time and implementing flexible solutions to handle variances without impacting performance.

Note:

The information contained in this chapter is meant to provide an overview of various techniques that can be used to develop an effective capacity management plan. The steps you take - and the plan you ultimately create - depends on your specific requirements and deployment structure.

The following sections provide an introduction to capacity planning:

Section 28.1, "About Capacity Planning for Oracle Fusion Middleware"
Section 28.2, "Determining Performance Goals and Objectives"
Section 28.3, "Measuring Your Performance Metrics"
Section 28.4, "Identifying Bottlenecks in Your System"
Section 28.5, "Implementing a Capacity Management Plan"

28.1 About Capacity Planning for Oracle Fusion Middleware

While performance tuning can be defined as optimizing your existing system for better performance, capacity planning determines what your system needs (and when it needs it) to maintain performance in both steady-state and peak usage periods.

Capacity Planning involves designing your solution and testing the configuration, as well as identifying business expectations, periodic fluctuations in demand, and application constraints. You need to plan carefully, test methodically, and incorporate design principles that focus on performance. Before deploying any application into a production environment, the application should be put through a rigorous performance testing cycle. Creating an effective Capacity Management plan includes some of the same steps as performance planning:

Step 1:Determining Performance Goals and Objectives
Step 2: Measuring Your Performance Metrics
Step 3: Identifying Bottlenecks in Your System
Step 4: Implementing a Capacity Management Plan

28.1.1 Capacity Planning Factors to Consider

Before you can create a plan, you must have the data to support your deployment strategy. The following list of questions should be asked - and the information you receive should be analyzed carefully - to ensure a successful capacity management plan.

Table 28-1 Capacity Planning Factors to Consider

Capacity Planning Questions	For more information see,
What are your performance goals and objectives?	Section 28.2, "Determining Performance Goals and Objectives"
How many users need to run simultaneously (concurrently?)	Section 28.2, "Determining Performance Goals and Objectives"
Is the simulated workload adequate? (Is the workload likely to increase?)	Section 28.2, "Determining Performance Goals and Objectives"
Is the Oracle Fusion Middleware deployment configured to support clustering and other high availability factors?	Section 28.4.1, "Using Clustered Configurations"
Does the hardware meet the configuration requirements?	Section 28.5.1, "Hardware Configuration Requirements"
Do you have adequate JVMs to support your users?	Section 28.5.2, "JVM Requirements"
Is the database a limiting factor?	Section 28.5.4, "Database Configuration"

28.2 Determining Performance Goals and Objectives

The first step in creating an effective capacity management plan is to determine your network load and performance objectives. You need to understand the applications deployed and the environmental constraints placed on the system. Ideally you have information about the levels of activity that components of the application are expected to meet, such as:

The anticipated number of users.
The number of concurrent sessions.
The number of SSL connections required.
The number and size of requests.
The amount of data and its consistency.
Determining your target CPU utilization.

Performance objectives are limited by constraints, such as

The configuration of hardware and software such as CPU type, disk size versus disk speed, sufficient memory.
The ability to interoperate between domains, use legacy systems, support legacy data.
The security requirements and use of SSL. SSL involves intensive computing operations and supporting the cryptography operations in the SSL protocol can impact the performance of the WebLogic Server.
Development, implementation, and maintenance costs.

You can use this information to set realistic performance objectives for your application environment, such as response times, throughput, and load on specific hardware.

28.3 Measuring Your Performance Metrics

After you have determined your performance criteria in Section 28.2, "Determining Performance Goals and Objectives", take measurements of the metrics you can use to quantify your performance objectives. Benchmarking key performance indicators provides a performance baseline. See Chapter 4, "Monitoring Oracle Fusion Middleware" for information on measuring your performance metrics with Oracle Fusion Middleware applications.

28.4 Identifying Bottlenecks in Your System

Bottlenecks, or areas of marked performance degradation, should be addressed while developing your capacity management plan. If possible, profile your applications to pinpoint bottlenecks and improve application performance. Oracle provides the following profilers:

Oracle Jrockit Mission Control provides profiling capabilities for processes using Jrockit JVM.

http://www.oracle.com/technology/products/jrockit/missioncontrol/index.html
Oracle Application Diagnostics provides profiling capabilities for java processing using SUN JDK.

http://www.oracle.com/technology/software/products/oem/htdocs/jade.html

The objective of identifying bottlenecks is to meet your performance goals, not eliminate all bottlenecks. Resources within a system are finite. By definition, at least one resource (CPU, memory, or I/O) can be a bottleneck in the system. Planning for anticipated peak usage, for example, may help minimize the impact of bottlenecks on your performance objectives.

There are several ways to address system bottlenecks. Some common solutions include:

Using Clustered Configurations
Using Connection Pooling
Setting the Max HeapSize on JVM
Increasing Memory or CPU
Segregation of Network Traffic
Segregation of Processes and Hardware Interrupt Handlers

28.4.1 Using Clustered Configurations

Clustered configurations distribute work loads among multiple identical cluster member instances. This effectively multiplies the amount of resources available to the distributed process, and provides for seamless fail over for high availability.

For more information see Chapter 29, "Using Clusters and High Availability Features".

28.4.2 Using Connection Pooling

You may be able to improve performance by using existing database connections. You can limit the number of connections, timing of the sessions and other parameters by modifying the connection strings.

See Section 2.7, "Reusing Database Connections" for more information on configuring the database connection pools.

28.4.3 Setting the Max HeapSize on JVM

This is a application-specific tunable that enables a trade off between garbage collection times and the number of JVMs that can be run on the same hardware. Large heaps are used more efficiently and often result in fewer garbage collections. More JVM processes offer more fail over points.

See Section 2.4, "Tuning Java Virtual Machines (JVMs)" for more information.

28.4.4 Increasing Memory or CPU

Aggregating more memory and/or CPU on a single hardware resource allows localized communication between the instances sharing the same hardware. More physical memory and processing power on a single machine enables the JVMs to scale and run much larger and more powerful instances, especially 64-bit JVMs. Large JVMs tend to use the memory more efficiently, and Garbage Collections tend to occur less frequently. In some cases, adding more CPU means that the machine can have more instruction and data cache available to the processing units, which means even higher processing efficiency.

See Section 2.2, "Securing Sufficient Hardware Resources" for more information.

28.4.5 Segregation of Network Traffic

Network-intensive applications can introduce significant performance issues for other applications using network. Segregating the network traffic of time-critical applications from network-intensive applications, so that they get routed to different network interfaces, may reduce performance impacts. It is also possible to assign different routing priorities to the traffic originating from different network interfaces.

28.4.6 Segregation of Processes and Hardware Interrupt Handlers

When planning for the capacity that a specific hardware resource can handle, it is important to understand that the operating system may not be able to efficiently schedule the JVM processes as well as other system processes and hardware interrupt handlers. The JVM may experience performance impacts if it shares even a few of its CPU cores with the hardware interrupt handlers. For example, disk and network-intensive applications may induce performance impacts that are disproportionate to the load experienced by the CPU. In addition, hardware interrupts can prevent the active Java threads from reaching a "GC-safe point" efficiently. Separating frequent hardware interrupt handlers from the CPUs running the JVM process can reduce the wait for Garbage Collections to start.

It may also be beneficial to dedicate sibling CPUs on a multi-core machine to a single JVM to increase the efficiency of its CPU cache. If multiple processes have to share the CPU, the data and instruction cache can be contaminated with the data and instructions from both processes, thus reducing the amount of the cache used effectively. Assigning the processes to specific CPU cores, however, can make it impossible to use other CPU cores during peak load bursts. The capacity management plan should include a determination on whether the CPUs should be used more efficiently for the nominal load, or should there be some extra capacity for a burst of activity.

28.5 Implementing a Capacity Management Plan

Once you have defined your performance objectives, measured your workload, and identified any bottlenecks, you must create and implement a capacity management plan. The goal of your plan should be to meet or exceed your performance objectives (especially during peak usage periods) and to allow for future workload increases. To achieve your performance objectives, you must implement your management plan and then continuously monitor the performance metrics as discussed in Chapter 4, "Monitoring Oracle Fusion Middleware".

Since no two deployments are identical, its virtually impossible to illustrate how a capacity management plan would be implemented for all configurations. Capacity planning is an iterative process and your plan must be calibrated as changes in your workload or environment change. The following section provides key factors that should be addressed in the plan:

28.5.1 Hardware Configuration Requirements

There is no single formula for determining your hardware requirements. The process of determining what type of hardware and software configuration involves assessment of your system performance goals and an understanding of your application. Capacity planning for server hardware should focus on maximum performance requirements.

The hardware requirements you have today are likely to change. Your plan should allow for workload increases, environment changes (such as added servers or 3rd party services), software upgrades (operating systems, middleware or other applications), network connectivity and network protocols.

28.5.1.1 CPU Requirements

Your target CPU usage should not be 100%, you should determine a target CPU utilization based on your application needs, including CPU cycles for peak usage. If your CPU utilization is optimized at 100% during normal load hours, you have no capacity to handle a peak load. In applications that are latency sensitive and maintaining the ability for a fast response time is important, high CPU usage (approaching 100% utilization) can reduce response times while throughput stays constant or even increases because of work queuing up in the server. For such applications, a 70% - 80% CPU utilization recommended. A good target for non-latency sensitive applications is about 90%.

28.5.1.2 Memory Requirements

Memory requirements are determined by the optimal heap size for the applications you are going to use, for each JVM co-located on the same hardware. Each JVM needs up to 500MB in addition to the optimal heap size; the actual impact to performance depends on the JVM brand, and on the type of application being run. For example, applications with more Java classes loaded need more space for compiled classes. 32-bit JVMs normally cannot exceed a limit of approximately 3GB on some architecture when a limit is imposed by the hardware architecture and the Operating System. It is recommended to reserve some memory for the Operating System, IO buffers and shared-memory devices.

28.5.2 JVM Requirements

The number of users/processes that a single Java Virtual Machine (JVM) can handle varies widely on the types of requests and the type of JVM you are running. As part of your performance monitoring and benchmarking procedures, you should determine how many and what kinds of processes are executed and determine if your hardware meets the requirements for your specific JVM.

28.5.3 Managed Servers

Using multiple managed servers across multiple nodes in a clustered configuration is recommended for both high performance and reliability. It is important to note, however, that having multiple managed servers may mean using more memory which can enable some applications to optimize certain operations in-memory, therefore reducing impact of disk, database and network latency.

For more information on using clustered configurations, see "Understanding Managed Servers and Managed Server Clusters" in Oracle Fusion Middleware Administrator's Guide.

28.5.4 Database Configuration

To maintain sustained performance, you must ensure that your existing database can scale with the increases in capacity planned for the application server tier. Tuning the database parameters and monitoring database metrics during peak usage, can help you determine if the existing database resources can scale to handle increased loads. You may need to add additional memory or upgrade the database hardware configuration. For more information on tuning an Oracle database, see the Oracle Database Performance Tuning Guide.

In some cases, however, you may find that the database is still not able to effectively manage increases in load, even after increasing the memory or upgrading the CPU. In these situations, consider deploying an Oracle Real Application Cluster (Oracle RAC) environment to handle the increases. Oracle RAC configurations not only provide enhanced performance, but they can also improve reliability and scalability. For more information on Oracle RAC, see Oracle Real Application Clusters Administration and Deployment Guide.