Setting performance objectives and defining your workloads

Before installing Db2, you should gather design data and evaluate your performance objectives with that information.

About this task

Reasonable performance objectives are realistic, in line with your budget, understandable, and measurable. How you define good performance for your Db2 subsystem depends on your particular data processing needs and their priority.

Mutual agreements about acceptable performance, between the data processing and user groups in an organization, are often formalized and called service level agreements. Service-level agreements can include expectations of query response time, the workload throughput per day, hour, or minute, and windows provided for batch jobs (including utilities). These agreements list criteria for determining whether or not the system is performing adequately. For example a service-level agreement might require that 90% of all response times sampled on a local network in the prime shift be under 2 seconds, or that the average response time not exceed 6 seconds even during peak periods. (For a network of remote terminals, consider substantially higher response times.)

Procedure

To define the workload of the system:

  1. Set your initial performance objectives.
    Typical objectives specify values for the following measurements:
    Acceptable response time
    A duration within which some percentage of all applications have completed.
    Average throughput
    The total number of transactions or queries that complete within a given time.
    System availability
    Which included mean time to failure and the durations of down time.

    Objectives such as these define the workload for the system and determine the requirements for resources, such as processor speed, amount of storage, additional software, and so on. Often, however, available resources limit the maximum acceptable workload, which requires revising the objectives.

  2. Consider the amount of processing that is expected.
    You might define your criteria in terms of the average, the ninetieth percentile, or even the worst-case response time. Your choice can depend on your site's audit controls and the nature of the workloads.

    z/OS® Workload Manager (WLM) can manage to the performance objectives in the service-level agreement and provide performance reporting analysis. The terms used in the service-level agreement and the WLM service policy are similar.

  3. Determine the types of workloads.
    For each type of workload, describe a preliminary workload profile that includes the following information:
    • A definition of the workload type in terms of its function and its volume. You are likely to have many workloads that perform the same general function (for example, order entry through CICS®, IMS, WebSphere® Application Server, or other transaction managers) and have an identifiable workload profile. Other workload types include SPUFI and QMF queries, transactions, utilities, and batch jobs.

      For the volume of a workload that is already processed by Db2, use the summary of its volumes from the Db2 statistics trace.

    • The relative priority of the type, including periods during which the priorities change.
    • The resources that are required to do the work, including physical resources that are managed by the operating system (such as real storage, disk I/O, and terminal I/O) and logical resources managed by the subsystem (such as control blocks and buffers).

What to do next

You should review and reevaluate your performance objectives at all phases of system development.