System Sizing Template

Print-friendly Version

Introduction

System availability and performance play a key role in achieving customer satisfaction. Reliable system sizing helps to ensure these two important criteria are met.

The goal of this template is to increase the efficiency and quality of a system sizing by providing sizing guidelines. The template includes questions, suggestions, and tables that are easily adaptable to meet your particular requirements.

This document includes the following sections:

• Section 1 - Process Overview

  Describes the phases of the sizing process and provides examples of how to:

  1. Perform a sizing study
  2. Prepare the results
  3. Complete sizing for workload requirements
     
     
• Section 2 - Sizing Study Templates

  Provides system sizing study guidelines beginning with the project plan and ending with the results. This section includes an explanation about mapping results to actual workloads.

• Section 3 - Templates for Sizing a Real-World System

  Provides templates for sizing a customer system

Contents

1. Process Overview

There are several steps to sizing a system:

• Definition phase
• Baseline tests
• Scalability tests
• Generalization of rules for other hardware products
• Determination of the required hardware for a given workload

The following overview provides a short description of each step with examples based on a sizing study for the modules "Sales and Distribution" and "Finance" of an ERP system.

2. Sizing Study Templates

Complete the templates provided in this section.

2.1 Sizing Study Goal

The goal of a system sizing study is to determine the system configuration baseline for a given workload.

2.2 Roles and Responsibilities

Define who is responsible for each of the following roles and provide deliverables, where applicable.

2.3 Test Schedule

Define the test schedule based on experience and any information available from similar tests. The following schedule is provided as a sample only. It shows some of the typical milestones in a sizing study project. Actual steps and duration will vary greatly depending on the sizing goals, size of the tests, and the test engineer's expertise.

2.4 Sizing Definition

2.4.1 Define:

• The application (for example, mySAP.com or Baan IV)
  
  
  

  ---

  
  

  ---

  The application component (for example, database, application logic, web, presentation layer, or network)

  ---

  
  

  ---

  The application module (for example, Finance or Warehousing) to be sized

2.4.2 Define the sizing audience. Determine who will consume the results. For example, Field Sales (either Sun's or ISV's).

2.5 Workload Definition

2.5.1 Describe application-level transactions to test (ensure these transactions comprise typical application usage)

2.5.2 Define master data and transactional data for the transactions to test

2.5.3 Define the sizing rules to apply (for example, think time and response time rules)

2.6 Sizing Baseline

Describe the sizing baseline (i.e., the sizing metrics) to use. Examples include:

• Number and type of concurrent users per CPU
• Transaction throughput per CPU

2.7 Product Stack Checklist

If applicable, answer the following questions when completing the Product Stack Checklist table:

• List all the software products, including version numbers required: OS, Volume Manager, database, middleware, application, client, etc.
• Are all these products certified for the application? Do the products support the application?
• Are all these products licensed? If not, who can provide the license?
• What load simulation tool will be used? Is it available for the Solaris Operating Environment?
• Have the simulation tools or scripts been fully developed and tested?
• Are the products or tools instrumented to collect the required metrics, according to the objective?
• Does all the software have documentation, and is it available?
• Have the software support teams been identified and contacted?

2.8 Hardware Test Environment

There might be several layers of your application, such as database, application, web, and presentation layers. Describe the logical architecture of your application. Figure 1 illustrates a sample architecture.

Figure 1: Logical architecture of a sample application (Click image to enlarge.)

Map this logical architecture to the test environment. Figure 2 provides a sample configuration.

Figure 2: Test configuration for a sizing study (example) (Click image to enlarge.)

Answer the following questions and complete the table.

• What configurations and topologies are being tested?
• What systems are required? What is their availability?
• Where will the test take place?

2.9 Evidence of Scalability

2.9.1 Describe configurations of previous tests (Sun hardware or other platforms), if any

2.9.2 Describe any unresolved scalability limits from previous tests

2.9.3 Describe the scalability tests

2.10 Configuration Instructions

Provide hints as to how to make sure the application runs stable, scales, and performs well. For example: adjust buffer sizes and/or other parameters.

2.11 Results

Before completing this section, copy the table for each sizing-relevant component (such as database and application servers) according to your needs.

• Most sizing studies will determine a CPU-user ratio or a CPU-load ratio similar to the data in Figure 3.
  
  

  Figure 3: CPU-user ratio of an application (example) (Click image to enlarge.)

  
  For instance, you can use the CPU Consumption Table to document the CPU consumption of the application.

2.11.1 Describe the conditions for which the values in the table are valid (e.g., response time or CPU utilization)

2.11.2 If available, add sizing information regarding main memory, storage, network, and the like here. For example, you could create a formula to calculate memory usage of an application, such as: 100MB+#Users*15MB.

2.11.3 Explain how to map these results to actual, real-world loads.

3. Templates for Sizing a Real-World System

3.1 Customer Information

Complete the customer data for the system configuration.

3.2 Load Definition for the Customer System

Describe the load for the particular system configuration.

3.3 Configuration of the Customer System

Map the results from Section 2.11 to the described load.

3.4 Additional Requirements

In addition to the system configuration, other sizing topics might be relevant to your particular need:

• Is there only a production system or also development and/or test systems to be configured?
• How does the application being sized collaborate with the existing system landscape?
• What LAN/WAN connections already exist? What are the requirements?
• Are migration/integration services required?
• What peak load is expected when? e.g.: Which are the hours when the maximum number of users are logged in? When is the backup and/or the batch time window planned? How often? Is an online backup necessary?
• How many working days per year are planned?
• Do users reside in more than one time zone? What languages are necessary?
• Is there system downtime planned? How would unplanned downtime be damaging to the business?
• Is high-availability required? What kind of failover is required (manual, automatic)?
• How long can a restore take to be completed?
What kind of disk topology is used (e.g., mirroring, striping, RAID 5)?
• What is the expected database growth?
• What are the printing requirements?
• For which CPU utilization should the configuration be sized? How much headroom for unexpected load should remain?

Additional Resources

Capacity Planning for Internet Services Online Discussion

February 2002