Performance tuning WebLogic Server and your WebLogic Server application is a complex and iterative process. The following sections provide a tuning roadmap and tuning tips for you can use to improve system performance:
The following steps provide a roadmap to help tune your application environment to optimize performance:
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. See Appendix B, "Capacity Planning."
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.
After you have determined your performance criteria in Understand Your Performance Objectives, take measurements of the metrics you will use to quantify your performance objectives. The following sections provide information on measuring basic performance metrics:
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 many ORDER BY clauses used in your application that are affecting the database CPU. See Chapter 4, "Operating System Tuning".
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.
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. See Operating System Tuning.
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.In this step, 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. For the scope of this document, this includes (from most important to least important):
To quote the authors of Oracle WebLogic Server: Optimizing WebLogic Server Performance: "Good application performance starts with good application design. Overly-complex or poorly-designed applications will perform poorly regardless of the system-level tuning and best practices employed to improve performance." In other words, a poorly designed application can create unnecessary bottlenecks. For example, resource contention could be a case of poor design, rather than inherent to the application domain.
For more information, see:
Your database can be a major enterprise-level bottleneck. Database optimization can be complex and vender dependent. See DataBase Tuning.
The WebLogic Server uses a number of OOTB (out-of-the-box) performance-related parameters that can be fine-tuned depending on your environment and applications. Tuning these parameters based on your system requirements (rather than running with default settings) can greatly improve both single-node performance and the scalability characteristics of an application. See Chapter 7, "Tuning WebLogic Server".
The Java virtual machine (JVM) is a virtual "execution engine" instance that executes the bytecodes in Java class files on a microprocessor. See Chapter 5, "Tuning Java Virtual Machines (JVMs)".
Each operating system sets default tuning parameters differently. For Windows platforms, the default settings are usually sufficient. However, the UNIX and Linux operating systems usually need to be tuned appropriately. See Chapter 4, "Operating System Tuning".
Performance tuning is an iterative process. After you have minimized the impact of bottlenecks on your system, go to Step 2, Measure Your Performance Metrics and determine if you have met your performance objectives.
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.