DB2 UDB V8 and WebSphere V5. Performance Tuning and Operations Guide2004

1.3 Key areas of performance

Performance is the way a computer system behaves given a particular workload. Performance is measured in terms of system response time, throughput, and availability. Performance is also affected by the resources available in your system and how well those resources are used and shared.

In general, you tune your system to improve its cost-benefit ratio. Specific goals could include:

• Processing a larger, or more demanding, work load without increasing processing costs; for example, to increase the work load without buying new hardware or using more processor time.

• Obtaining faster system response times, or higher throughput, without increasing processing costs.

• Reducing processing costs without degrading service to your users.

Translating performance from technical terms to economic terms is difficult. Performance tuning certainly costs money in terms of user time as well as processor time, so before you undertake a tuning project, weigh its costs against its possible benefits. In the following sections we discuss a few key areas of performance tuning.

1.3.1 Hardware

A balanced system is a system that has a sensible set of CPU, memory, disks, and network connections. There should be no bottleneck, which would make the other components ineffective. All parts of a balanced system are used appropriately during normal business operation workloads. When you acquire the hardware, please consider the following:

• Type of workload and the CPU power required for the various transactions

• Expected size of the database data

• The maximum number of concurrently connected users

• The maximum number of concurrent jobs

• Number of transactions within a certain period of time

1.3.2 Operating system

Diagnosing some problems related to memory, swap files, CPU, disk storage, and other resources requires a thorough understanding of how a given operating system manages these resources. At a minimum, defining resource-related problems requires knowing how much of that resource exists, and what resource limits may exist per user.

Here is some important configuration information that you need to obtain:

• Operating system patch level, installed software, and upgrade history

• Swap and file cache settings

• User data and file resource limits and per-user process limit

• Inter-Processor communication (IPC) resource limits (message queues, shared memory segments, semaphores)

1.3.3 Application Server and WebServer

By tuning application server settings, you can control how an application server provides services for running applications and their components. WebSphere Application Server contains interrelated components that must be harmoniously tuned to support the custom needs of your end-to-end e-business application. Below are few important areas of consideration.

JVM

The application server, being a Java process, requires a Java virtual machine (JVM) to run, and to support the Java applications running on it. As part of configuring an application server, you can fine-tune settings that enhance system use of the JVM.

Web container

One of the parts of each WebSphere Application Server is a Web container. To route servlet requests from the Web server to the Web containers, the product establishes a transport queue between the Web server plug-in and each Web container. The Web container is initially created with default property values suitable for simple Web applications. However, these values might not be appropriate for more complex Web applications.

EJB container

One of the parts of each application server in WebSphere Application Server is an EJB container. An EJB container is automatically created when you create an application server. After the EJB container is deployed, you can change the parameters to make adjustments that improve performance.

Data sources

A data source is used to access data from the database. Certain parameters reveal how the number of physical connections within a connection pool can change performance.

Object Request Broker

An Object Request Broker (ORB) manages the interaction between clients and servers, using the Internet InterORB Protocol (IIOP). It supports client requests and responses received from servers in a network-distributed environment.

Session management

IBM WebSphere Application Server session support has features for tuning session performance and operating characteristics, particularly when sessions are configured in a distributed environment. These options support the administrator flexibility in determining the performance and failover characteristics for their environment.

1.3.4 Database manager

When a DB2 UDB instance or a database is created, a corresponding configuration file is created with default parameter values. You can modify these parameter values to improve performance.

• Use sufficient agents for the workload.

• Do not allow DB2 UDB to needlessly close and open files.

• Do not allow extended lock waits.

• Manage DB2 sort memory conservatively and do not mask sort problems with large SORTHEAPs.

• Analyze table access activity and identify tables with unusually high rows read per transaction or overflow counts.

• Analyze the performance characteristics of each tablespace, and seek to improve the performance of the tablespaces with the slowest read times, longest write times, highest physical I/O read rates, worst hit ratios, and access attributes that are inconsistent with expectations.

• Create multiple buffer pools, and make purposeful assignments of tablespaces to buffer pools such that access attributes are shared.

• Examine DB2 UDB SQL statement Event Monitor information to discover which SQL statements are consuming the largest proportions of computing resources, and take corrective actions.

• Reevaluate configuration and physical design settings once high-cost SQL is eliminated.

1.3.5 Application programs

Whether the program is new or purchased, small or large, the developers, the installers, and the prospective users have assumptions about the use of the program, such as:

• Who is going to use the program

• Situations in which the program will be run

• How often those situations will arise and at what times of the hour, day, month, or year

• Whether those situations will also require additional uses of existing programs

• Which systems the program will run on

• How much data will be handled, and from where

• Whether data created by or for the program will be used in other ways

Unless these ideas are elicited as part of the design process, they will probably be vague, and the programmers will almost certainly have different assumptions than the prospective users. Even in the apparently trivial case in which the programmer is also the user, leaving the assumptions unarticulated makes it impossible to compare design to assumptions in any rigorous way. Worse, it is impossible to identify performance requirements without a complete understanding of the work being performed.