Performance Tuning Part - 2

Performance tuning WebLogic Server and your WebLogic Server application is a complex and iterative process. 

Tuning allows you to adjust resources to achieve your performance objectives.

The following sections provide a tuning roadmap and tuning tips for you can use to improve system performance.

****************************************************************************************************

1.  Understand Your Performance Objectives

2.  Measure Your Performance Metrics

      2.1. Monitor Disk and CPU Utilization

      2.2. Monitor Data Transfers Across the Network

3.  Locate Bottlenecks in Your System

4.  Minimize Impact of Bottlenecks

• Tune Your Application
• Tune your DB
• Tune WebLogic Server Performance Parameters
• Tune Your JVM
• Tune the Operating System
• Tuning the WebLogic Persistent Store

5.  Capacity Planning

****************************************************************************************************

Understand Your Performance Objectives

To determine your performance objectives, you need to understand the application deployed and the environmental constraints placed on the system. Gather information about the levels of activity that components of the application are expected to meet, such as:

§  The anticipated number of users.

§  The number and size of requests.

§  The amount of data and its consistency.

§  Determining your target CPU utilization.

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%.

Performance objectives are limited by constraints, such as

§  The configuration of hardware and software such as CPU type, disk size vs. disk speed, sufficient memory.

There is no single formula for determining your hardware requirements. The process of determining what type of hardware and software configuration is required to meet application needs adequately is called capacity planning. Capacity planning requires assessment of your system performance goals and an understanding of your application. Capacity planning for server hardware should focus on maximum performance requirements.

• The ability to interoperate between domains, use legacy             systems, support legacy data.

§  Development, implementation, and maintenance costs.

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

Measure Your Performance Metrics

After you have determined your performance criteria as described above take measurements of the metrics you will use to quantify your performance objectives.

Monitor Disk and CPU Utilization

Run your application under a high load while monitoring the:

§  Application server (disk and CPU utilization)

§  Database server (disk and CPU utilization)

The goal is to get to a point where the application server achieves your target CPU utilization. If you find that the application server CPU is under utilized, confirm whether the database is bottle necked. If the database CPU is 100 percent utilized, then check your application SQL calls query plans. For example, are your SQL calls using indexes or doing linear searches? Also, confirm whether there are too manyORDER BY clauses used in your application that are affecting the database CPU. 

If you discover that the database disk is the bottleneck (for example, if the disk is 100 percent utilized), try moving to faster disks or to a RAID (redundant array of independent disks) configuration, assuming the application is not doing more writes then required.

Once you know the database server is not the bottleneck, determine whether the application server disk is the bottleneck. Some of the disk bottlenecks for application server disks are:

§  Persistent Store writes

§  Transaction logging (tlogs)

§  HTTP logging

§  Server logging

The disk I/O on an application server can be optimized using faster disks or RAID, disabling synchronous JMS writes, using JTA direct writes for tlogs, or increasing the HTTP log buffer.

Monitor Data Transfers Across the Network

Check the amount of data transferred between the application and the application server, and between the application server and the database server. This amount should not exceed your network bandwidth; otherwise, your network becomes the bottleneck.

Locate Bottlenecks in Your System

If you determine that neither the network nor the database server is the bottleneck, start looking at your operating system, JVM, and WebLogic Server configurations. Most importantly, is the machine running WebLogic Server able to get your target CPU utilization with a high client load? If the answer is no, then check if there is any locking taking place in the application. You should profile your application using a commercially available tool (for example, JProbe or OptimizeIt) to pinpoint bottlenecks and improve application performance.

Tip: Even if you find that the CPU is 100 percent utilized, you should profile your application for performance improvements.

Minimize Impact of Bottlenecks

you tune your environment to minimize the impact of bottlenecks on your performance objectives. It is important to realize that in this step you are minimizing the impact of bottlenecks, not eliminating them. Tuning allows you to adjust resources to achieve your performance objectives.

Tune Your Application

Tune your DB

Tune WebLogic Server Performance Parameters

Tune Your JVM

Tune the Operating System

 Capacity Planning

The process of determining what type of hardware and software configuration is required to meet application needs adequately is called capacity planning. Capacity planning is not an exact science. Every application is different and every user behavior is different. 

Capacity Planning Questions	For Information, See:
Is WebLogic Server well-tuned?	Assessing Your Application Performance Objectives
How well-designed is the user application?	Database Server Capacity and User Storage Requirements
Is there enough bandwidth?	Network Load
How many transactions need to run simultaneously?	Concurrent Sessions
Is the database a limiting factor? Are there additional user storage requirements?	Database Server Capacity and User Storage Requirements
What is running on the machine in addition to WebLogic Server?	Network Load
Do clients use SSL to connect to WebLogic Server?	SSL Connections and Performance
What types of traffic do the clients generate?	RMI and Server Traffic
What types of clients connect to the WebLogic Server application?	Programmatic and Web-based Clients
Is your deployment configured for a cluster?	Clustered Configurations

Tuning Tips

This section provides tips and guidelines when tuning overall system performance:

§  Performance tuning is not a silver bullet. Simply put, good system performance depends on: good design, good implementation, defined performance objectives, and performance tuning.

§  Performance tuning is ongoing process. Implement mechanisms that provide performance metrics which you can compare against your performance objectives, allowing you to schedule a tuning phase before your system fails.

§  The object is to meet your performance objectives, not eliminate all bottlenecks. Resources within a system are finite. By definition, at least one resource (CPU, memory, or I/O) will be a bottleneck in the system. Tuning allows you minimize the impact of bottlenecks on your performance objectives.

§  Design your applications with performance in mind:

·       Keep things simple - avoid inappropriate use of published patterns.

·       Apply Java EE performance patterns.

·       Optimize your Java code.