Sizing SAP Systems

Susanne Janssen, Ulrich Marquard

Contents
1

Introduction

.................................................

Basic Considerations and Assumptions

Sizing Denition ....................................

for Throughput Sizing ............................ 23

The Sizing Principle ................................

Advantages and Disadvantages

Business Management and Technology

of Throughput Sizing ............................. 23

Goals of This Book .................................

Sizing by Reference Installations ........... 23

Target Group and Structure of the

Sizing by Load Tests ...............................

24

Book .......................................................

Conclusion .............................................

24

Related Topics ........................................

3.4 User and Throughput Sizing Models .................

24

Calculating CPU Requirements .............

24

Calculating Memory Requirements .......

25

2.1 Phases of Sizing Projects ...................................

Calculating Disk Requirements ..............

26

2.2 Methods for Initial Sizings ................................

Frontend Network Requirements .........

27

Sizing Methods

...........................................

Hardware Budget Sizings .......................

Conclusion for These Approaches .........

27

Advanced Sizing .....................................

10

3.5 Conclusion ........................................................

27

Expert Sizing ..........................................

10

Standard Tools Even for Experts .......

11

29

Analyzing Customer Data ......................

11

4.1 Rule of Thumb/Reality Check ........................... 29

2.3 Sizings Based on Productive Customer Data ....

12

Bottom-Up Method .............................. 30

13

4.2 T-shirt Sizing ...................................................... 30

Basic Analysis for All Production

Sizings ....................................................

Sizing Tools

...................................................

Top-Down Method ................................ 30

Resizing ..................................................

13

Categories ..............................................

31

Delta Sizing ............................................

14

Pros and Cons ........................................

31

Upgrade Sizing .......................................

15

4.3 Sizing Formula ...................................................

32

Single-Instance Projects .........................

15

4.4 Ofine Questionnaire .......................................

33

2.4 Summary ...........................................................

15

4.5 Summary ...........................................................

33

.....................................

17

...................................................

35

3.1 Factors That Inuence Sizing ............................

Sizing Approaches

17

5.1 Quick Sizer Projects ..........................................

36

3.2 Key Performance Indicators ..............................

18

Creating a Project ..................................

36

Filling Out Sizing Questionnaires ..........

37

3.3 Overview of Different Sizing

Quick Sizer

Approaches .......................................................

20

Determining the Sizing Result ............... 38

Sizing by Users .......................................

20

5.2 Functions ........................................................... 40

Advantages and Disadvantages of

Initial Page .............................................

41

21

Navigation Tree ......................................

41

Sizing by Throughput ............................. 22

Header Bar .............................................

41

User-Based Sizing ..................................

www.sap-press.com

Contents

Questionnaires .......................................

43

Step 5: Acquire Information and Apply

Results Page ...........................................

45

the Methods ..........................................

76

5.3 Average and Peak Sizing .................................... 48

Step 6: Analyze First Results and Adapt

5.4 Summary ........................................................... 50

the Methods .......................................... 77

Step 7: Consolidate the Results and

Performance Monitors and Traces

......

51

6.1 Operating System Monitor ...............................

52

6.2 Database Monitor .............................................

53

Get Conrmation from Stakeholders .... 77

8.4 Summary ...........................................................

78

6.3 Application Monitor .......................................... 54

79

6.4 Single Record Statistics .................................... 56

9.1 Basic Foundations of the SAP Sizing

6.5 Performance Trace .............................................

Sizing Details

...............................................

57

Model ................................................................ 79

6.6 Summary ........................................................... 58

SAP Software Architecture .................... 79

Application Services and Database

Sizing Verication

......................................

59

Services .................................................. 80

7.1 Load Tests ..........................................................

59

Modeling CPU Consumption ................

Phase 0: Preparation ..............................

59

Allocating Sufcient Memory

81

Phase 1: Performing Individual

(or: Modeling Physical Memory) ........... 84

Measurements ....................................... 60

Allocating Sufcient Disk I/O

Phase 2: Analyzing the Transaction

Capabilities (or: Modeling Disk I/O

Design in Single Mode .......................... 60

Requirements) ....................................... 86

Phase 3: Load Tests in Multi-User

Modeling Network Bandwidth .............. 86

Mode .....................................................

61

Measuring Resource Consumption ....... 88

7.2 Verication via Support Services ....................... 63

Benchmark Results ................................ 88

SAP GoingLive Check ............................ 63

Results from a Java Benchmark ............. 90

SAP EarlyWatch Check .......................... 67

9.2 SAP Application Performance Standard ............

SAP GoingLive Functional Upgrade

9.3 Performing Sizing Measurements ..................... 94

Step 1: Dene the Test Case ................. 94

Check ..................................................... 68
7.3 Summary ...........................................................

92

Step 2: Identify the Test System ............ 95

69

Step 3: Create the Test Case in the

Executing Sizing Projects

........................

71

Test System ............................................ 95

8.1 Before the Sizing Project Begins .......................

71

Step 4: Measure the Sizing KPIs ............ 96

Chicken or the Egg? ...............................

71

Step 5: Create Sizing Guidelines Based

Project Scope .........................................

71

on the Measurements ........................... 98

Stakeholders in a Sizing Project ............. 72

9.4 Summary ........................................................... 99

Denition of a Sizing Project ................. 72

8.2 Project Team ...................................................... 73
8.3 Methodical Procedure ......................................

Step 1: Dene Project Contents and

Goals ......................................................

74

Step 2: Determine Performance-Critical

Processes ................................................

10 Summary and Outlook

............................ 101

74

Frequently Asked Questions

................. 103

A.1 Sizing Approaches ............................................. 103

A.2 Quick Sizer ........................................................ 104

75

A.3 Sizing Projects ................................................... 104

75

Step 3: Decide on the Approaches and

Methods to Be Used ..............................

Literature and Links

.................................. 105

Step 4: Dene Milestones and Prepare

a Detailed Schedule ...............................

Galileo Press 2007. All rights reserved.

76

Index

............................................................... 107

2 Sizing Methods

Sizing projects are carried out at very different stages of

sizing). Moreover, we are using several custom develop-

an SAP project. They represent an iterative process that

ments. How should we carry out a sizing project?

depends closely on the amount of information that is

This question refers to a specic component in

available to you at a certain point in time to make reliable

accounting and is therefore more detailed. Perhaps

statements on the actual hardware requirements.

this customer has already carried out sizing projects

Accordingly, in each sizing project, you will often face

for other SAP applications and wants to perform

new situations that you must react to with different meth-

another one for this particular application. In addi-

ods and, consequently, using different tools. This chapter

tion, the customer wants to know how sizing can be

focuses on these different methods.

done for proprietary developments.

2.1

We are planning to consolidate our seven data centers

into one. Can we simply add up existing sizings?

Phases of Sizing Projects

This question (which comes from an existing SAP

SAP regularly receives information requests like the fol-

customer) refers to a system consolidation process

lowing:

in which additional hardware requirements must be

We are a large customer in the consumer goods indus-

taken into account if the different existing systems

try with 30,000 business partners and 60,000 sales

are combined. System consolidation and single-

orders containing 50 line items per month. How much

instance concepts, which are used to check whether

hardware do we need for our SAP application?

all systems can be globally integrated with one data-

This is a rather general question. The customer needs

information about hardware for a rst estimate. The

base, are currently red-hot issues with our customers.

We are currently running Release SAP R/3 4.6C and

question itself does not indicate why this is a large

want to upgrade to SAP ERP 6.0. What are the upgrade

customer. Perhaps the customer is only looking for a

factors?

partial solution since the volumes mentioned indicate

This customer uses a specic release that he wants

that this customer is a large medium-sized company.

to upgrade across multiple releases in one step and

The business partners represent master data and are

therefore wants to know if new hardware needs to be

not yet relevant to sizing because they do not gener-

purchased for that.

ate any load during live operation. In contrast, the

sales orders and sales order items are much more

By further analyzing these kinds of requests, we ulti-

critical to CPU sizing since they represent transac-

mately get to the different phases in which you can per-

tion data. In terms of revenue, an average of 2,000

form sizing projects (see Table 2.1). The informational

sales orders per day is quite considerable; however,

value of the sizing project can vary, depending on the

from the point of view of software, this is not a high

different phases. In addition, you should note that not

throughput volume. SAP has several customers who

all the phases described in Table 2.1 have to occur in an

process more than a million sales order items per day.

SAP project.

We cant nd any guidelines for the FIN-FSCM-TRN

component in your sizing area (http://service.sap.com/

Thus, if the system GoLive is still way down the road

and you as a customer are not yet very familiar with

www.sap-press.com

2 Sizing Methods

Phase

Point in Time

Description

Orientation phase
(Phase A)

18 to 12 months
prior to GoLive

You familiarize yourself with the software functionality and want to know what the range
of expenses is for the new hardware. Accordingly, you will certainly know which processes
you want to map using the software, and you also know the approximate amount of data
that is supposed to be processed. However, you are not familiar with the SAP jargon, nor
are you interested in specic releases.

Blueprint phase (Phase B)

12 to 6 months
prior to GoLive

The rst business blueprints have been created, and now you need reliable information on
the scope of hardware you have to order because you must make sure you meet all your
deadlines. You know how to implement the relevant processes, have become more familiar
with SAP products and SAP terminology, and know which release you want to use.

Implementation phase
(Phase C)

6 to 0 months
prior to GoLive

You have ordered the hardware or are just about to do so, and you want to be absolutely
sure that sizing is correct. For example, you are able to measure core processes using the
performance monitors.

Consolidation phase
(Phase D)

System is
operational

The system is operational and is supposed to be consolidated. Region 1, for instance, has
gone live with a specic software, and Region 2 is now supposed to go live on the same
system.

Extension phase
(Phase E)

System is
operational

The system is operational and you want to add new functions. For example, your live system runs the SAP ERP applications, and you want to add CRM applications now.

Upgrade phase
(Phase F)

System is
operational

The system is operational and you want to perform an upgrade. For example, the system
runs on SAP R/3 Enterprise and you want to upgrade it to SAP ERP 6.0.

Table 2.1 Phases in Which Sizing Can Be Performed

the software, you will probably have only basic informa-

ings in phases B and C, resizings in phase D, delta sizings

tion on how you are going to use it so that you can at

in phase E, and upgrade sizings in phase F.

least make a rough estimate of the costs involved. During

the course of the implementation project, you can rene
your initial assumptions by using standard sizing rules in
order to take a closer look at the critical issues.

2.2 Methods for Initial Sizings

Initial sizings are sizings that refer to new installations,

If an installations complexity differs too much from

that is, installations in which you use SAP software for

the standard, you can, for instance, measure customer

the rst time. That is also the case if, for instance, you

processes in order to create customer-specic sizings.

want to use SAP SRM for the rst time while SAP ERP

All these different phases require different sizing meth-

is already running in your companys production system

ods. In this context, we generally distinguish between ini-

at least the sizing for SAP SRM will be considered as

tial and production sizings. Figure 2.1 provides an over-

being initial.

view of the available sizing methods, with initial sizings

Depending on the project phases, we differentiate ini-

being shown in the upper section and production siz-

tial sizings into hardware budget sizings (budget sizings

ings in the lower one. Expert sizing is marked as a hybrid

for short), advanced sizings, and expert sizings. Usually,

because under certain circumstances, some processes can

budget sizings and advanced sizings are based on tools,

be mapped using standard methods while, at the same

whereas expert sizings are a mixture of tools and addi-

time, customer-specic data can be analyzed.

tional rules or measurements.

The following sections describe the characteristics of

these different sizings in greater detail. At this point it is

Hardware Budget Sizings

important to know that sizings can be performed within

The main characteristic of budget sizings is that they

several phases of a project: Sizing is an iterative process.

dont require much information from the customer and

Budget sizing, for example, could be done in phases A

they contain many assumptions (i.e., values provided by

and B, advanced sizings in phases A through C, expert siz-

SAP based on experience). For example, if the only infor-

Galileo Press 2007. All rights reserved.

2.2 Methods for Initial Sizings

Hardware Budget Sizing

Smaller Companies

Advanced Sizing

Expert Sizing

GoLive

Large/Complex Projects

Medium to Large Companies

Very simple algorithms

Throughput estimates

Additional guidelines

Assumptions, likelihoods

Questionnaires, formulas

Custom calculations

Level setting of project

Usage of standard tools

Analysis of custom coding

Risk identification

Focus on core business

processes

Custom sizing guidelines

Initial Sizings

Resizing

Delta Sizing

Upgrade Sizing

All Projects

All Projects

All Projects

SAP system monitors

SAP system monitors

SAP system monitors

Goal: Extend an existing system

by load (e.g., by volume, 100
additional users who will do the
same as the current productive
ones)

Goal: Extend an existing system

by functions (by different
functions, e.g., you are live with
CRM and want to add SCM)

SAP Notes

Goal: Upgrade SAP software

Post GoLive Sizings

Figure 2.1 Overview of Sizing Approaches and Methods
1

mation you have is that 100 users will use SAP CRM, but

Budget Sizings Help in Estimating the Entire Size

you dont know the other applications they will use and

Lets suppose a budget sizing determines 4,000 SAPS

what will be their average activity, you can certainly per-

(SAP Application Performance Standard1). Currently,

form the sizing, but in the long run, the informational

4,000 SAPS correspond more or less to a dual-core

value provided by the result of the sizing process will be

machine (server) with two processors, which has a list

too restricted.

price of $15,000. Now you can make up your mind

For this reason, budget sizings are usually performed

whether it makes sense to tackle a rather intensive siz-

way ahead of the GoLive phase (most of the time in

ing process or whether you want to take one of the

Phase A) if the goal is to estimate the approximate scope

following two risks:

of hardware.

For budget sizings, you can use the user-based sizing

Result Is Too High

This means the server will not be fully utilized dur-

function in SAPs Quick Sizer (see Chapter 5, Quick Sizer).

ing live operations. A result that is too high often

Alternatively, you can use T-shirt sizings (see Section 4.2,

occurs because the initial estimates are usually too

T-shirt Sizing), which have the advantage of requiring you

conservative.

to answer only a few questions. Of course, the disadvan-

Result Is Too Low

tage is that the rough categorization into S through XL

This means that you must buy additional hard-

provides only limited informational value. Occasionally,

ware. In this case, the question is whether you can

such sizings can be sufcient, depending on the specic

afford to use the wrong assumptions. Lets sup-

situation.

pose your initial estimate is wrong by 100%. You

For this reason, it makes a lot of sense to compare the

time and effort you want to invest into a sizing project
with the potential hardware costs.

1 See Section 9.2, SAP Application Performance Standard, for a

more detailed description of SAPS.

www.sap-press.com

2 Sizing Methods

as the size of these objects. If you have times of peak

would then have to pay (in the above example)

load, you can, of course, specify them.

an additional $15,000 $20,000 for a correspondingly bigger server. There are some customers for
whom expenses in this range are critical, since the
implementation of a new production server also
involves the purchase of new quality assurance
systems and testing landscapes.

Throughput-based sizing enables you to determine

in greater detail in which areas and at what time
the CPU peak load occurs (for example, in the week
before Christmas or New Years). Especially with
regard to background-oriented processes such as
those relevant to controlling or year-end settlements,
this information is critical and cannot be taken care

Advanced Sizing

of by user-based sizing.

If youre in a situation in which theres a high risk of misjudging the requirements by several 100 percents, you

The drawback of advanced sizing is that you have to

should rene your budget sizing by using what is referred

familiarize yourself with the core business processes in

to as advanced sizing. For example, if the range of CPU

order to obtain the appropriate information from the

power youre dealing with is between 8 and 16 cores, a

user departments for the Quick Sizer questionnaire. This

more detailed sizing makes a lot of sense because it pro-

certainly takes more time than asking for the number of

vides a higher degree of reliability. To do that, you can use

users (as is done, for instance, in a budget sizing process),

additional functions of Quick Sizer, such as its through-

but it is much more accurate.

put-based functionality, which allows you to determine

Note that advanced sizing is still a tool-based process.

the CPU load on average as well as by peak load (see Sec-

An XL category in Quick Sizer represents a large cat-

tion 5.3, Average and Peak Sizing).

egory in the tool-controlled area, but not necessarily in

Usually, advanced sizing occurs in phases B and C. In

the entire sizing context. For example, in Quick Sizer, the

these phases, the rst business blueprints have already

largest category (XXL) starts at 30,000 SAPS. A number

been created so that important and sizing-relevant infor-

of large customers operate on 40,000 to 100,000 SAPS;

mation about the business software applications is avail-

a few other customers operate in the range of 300,000

able to you. This information could include, for instance,

SAPS and higher.

a PC vendors decision about which important materials are imperative that an availability check be performed

Expert Sizing

for (processors, for example). An availability check locks

For ranges of 30,000 SAPS and higher, SAP therefore rec-

an object and can become a performance bottleneck

ommends that its customers not rely exclusively on one

because all other requests have to wait until the object is

sizing tool but rather that they analyze the core processes

released again.

and, above all, the customer processes in great detail via

Thus, in an advanced sizing process, you focus more

expert sizing.

on the core business processes. Quick Sizer is able to map

This method is particularly suited for complex busi-

the key processes of the SAP Business Suite and tries to

ness transactions, in-house developments, and large-

break down the complex business scenarios into the most

scale installations. Complex business transactions may

important transactions and objects. In addition, Quick

also occur in smaller installations, such as in the supply

Sizer provides the option to ne-tune the CPU sizing in

chain or in retailing systems. Global installations, which

that it distinguishes between the average CPU utilization

are not only dened by their size, are also eligible can-

(average sizing) and the utilization at peak times (peak siz-

didates for expert sizing because of the time differences

ing):

that must be taken into account.

For processor requirements, you can perform an

average sizing in such a way that you specify the
number of objects that are processed per year as well

10

Galileo Press 2007. All rights reserved.

To be able to perform an expert sizing process, you

must have:

2.2 Methods for Initial Sizings

Identied all processes that are critical for performance.

Used standard tools for the core processes.

Determined the performance-critical areas in which

your processes deviate from the standard.

Simplied Example of Expert Sizing

A company uses SAP CRM applications to enter sales
orders and uses SAP ERP for sales order fulllment and
HR. The sales order processing functions in the ERP
system have been custom-coded.
For this reason, a mixed approach is used in expert

Expert sizings are performed just before the system

GoLive, that is, when the functionality has been clearly
dened and perhaps even been implemented. In most
cases, expert sizing represents an iteration on a previously performed budget or advanced sizing so that you
can use the data of these previous processes as a basis
and simplify it, if necessary.

sizing in such a way that core processes are mapped

through the standard as much as possible, while the
other processes are approached step by step:

standard sizing for sales order entry in SAP CRM.

ERP system, a certain amount of extra capacity is

mixture of standard sizing and performance tools, and on

added to the sending system, that is, SAP CRM,

the other, of additional procedures and analyses. We can

The full utilization of the sizing tools functionality (in

according to the corresponding sizing rules.

that the orders are transferred through an inter-

requirements at least in part.

face does not negatively affect the performance

The analysis and performance monitoring of core

of the ERP system (on the contrary, it has, rather,

processes in the customer system.

a positive effect because there is no user interaction). This sizing represents the basic structure of

The following sections provide an overview of how you

can use standard tools in expert sizing to obtain useful
information, at least about parts of your system.

the ERP sizing.

cessing will be, it performs performance measurements that show that, because of the extension

Whenever you have identied business transactions as

made in the customer system, the same process

being close to the standard, you can use Quick Sizer (see

that was mapped in Quick Sizer now needs more

Chapter 5). That is, you can use Quick Sizer for partial
Another option for using Quick Sizer in expert sizing is
that you can use it for optimizing process ows from the
point of view of sizing. For example, if you use overlapping, performance-critical process chains, you can use the
24-hour load prole provided by Quick Sizer to ascertain

Because the company does not know up front

what the impact of extending the sales order pro-

Standard Tools Even for Experts

sizings.

The sizing of SAP ERP is mapped in Quick Sizer on

the basis of the total number of orders. The fact

particular, Quick Sizers) so that they meet specic

Because the sales orders that have been entered

in the CRM system are further processed in the

Basically, this method consists, on the one hand, of a

roughly subdivide these two parts into:

First the company uses Quick Sizer to create a

resources.

The customer is now able to increase the ERP

result for sales order processing by 30% in such
a way that the customer multiplies the Quick
Sizer result by a factor of 1.3. Other results (for
instance, in HR) are not affected by this.

whether it is possible to perform moves (see also Section

5.3, Average and Peak Sizing). Quick Sizer enables you to

Analyzing Customer Data

map and document additional loads which, for example,

One of the most important tasks of expert sizing consists

have been caused by custom coding.

of analyzing specic customer processes. Typical cases in

which it makes sense to analyze the performance gures
on the basis of custom data because of the strong inherent customer-specic nature include the following:

www.sap-press.com

11

2 Sizing Methods

Variant conguration that evaluates complex object

Sizing Measurement Versus Performance Analysis

dependencies: Its runtime can hardly be anticipated

Note that sizing measurements reect only the actual

in the standard, if at all.

status. Based on sizing measurements, you can deter-

Each custom extension.

mine whether a business transaction is scalable. In

this context, scalability means that the resource con-

To analyze customer data, the following two methods are

sumption increases linearly with the number or size

available: single-user analysis and the load test.

of the processed projects. If a process is not scalable,

Single-user Analysis

you must analyze and resolve the problem in a perfor-

Single-user analysis is based on a relatively simple

mance subproject.

principle: As soon as integration tests can be performed (i.e., when business processes can be functionally mapped in a system), you use the standard

The advantages of expert sizing over other sizing meth-

performance monitors of the SAP system to mea-

ods are found in the higher degree of accuracy and reli-

sure the CPU time, memory consumption, or data-

ability of the information. If you manage a sizing project

base growth on your hard disk, depending on your

for a complex or large customer, you should denitely

requirements. You can then use this data in a rule of

consider aspects from expert sizing, even though the col-

three to create the sizing forecast.

lection and analysis of the information takes more time.

Table 2.2 provides an overview of the procedure to

be applied in a single-user analysis, from dening an
appropriate test case to applying the customer-specic sizing rule. Chapter 6, Performance Monitors and

2.3 Sizings Based on Productive Customer

Data

Traces, contains detailed information on sizing-based

Sizing is an iterative process that is, even operational

performance measurements.

installations can be subject to change processes that

affect the resource requirements, as the following exam-

Step

Description

Dene test case

Identify test system

Create test case in test system

Measure sizing KPIs

Implement measurement results in sizing method

system (for example, by installing a CRM system on a

Apply sizing rule

server that already hosts an ERP system).

Table 2.2 Steps in Creating a Sizing Rule

ples will show:

scape (for example, by merging all your international

subsidiaries on one server).

You want to add additional functions to an existing

You want to upgrade Release X to Release Y.

Load Test

All these situations can affect the hardware and require

Load tests are occasionally used in the context of

a more or less comprehensive sizing project. The major

expert sizings and make sense when a single-user

advantage of sizings that are based on a production sys-

analysis does not provide sufcient information about

tem is that you can use your own data and settings as a

the locking procedure or memory requirements.

basis. In other words, you do not need to rely on assump-

In the sizing environment, load tests have a hybrid

tions made by SAP.

nature: On the one hand, you can use them as a siz-

Regarding production sizings, we distinguish between

ing tool. On the other hand, you can use them to

the following three methods, which pursue different

verify sizing results. Because customers usually use

goals:

them to verify sizing results, you can nd detailed

information on them in Section 7.1, Load Tests.

12

You want to consolidate your existing system land-

Galileo Press 2007. All rights reserved.

Resizing
In a resizing project, the throughput or user volume

2.3 Sizings Based on Productive Customer Data

changes, but not the processes (or customizing or

it can also be projects or calls. Alternatively, you can also

parameter settings, and so on).

use the number of activities or sales orders, depending,

Delta Sizing

on the one hand, on which unit is best suited to reect

In a delta sizing project, you add new functionality.

the respective business activity, but also, on the other, on

Upgrade Sizing

how easily it can be determined.

An upgrade sizing involves a change of the SAP

release.

Sample Analysis of a Production System

The following example forms the basis for the descrip-

Common to all these sizing methods is that you must rst

tion of individual sizing methods. A customer uses

analyze the status of the existing system before you can

strategic procurement in the SRM environment. The

plan the new hardware requirements.

analysis of the current utilization provides the following result:

Production System Sizings Versus Quick Sizer

CPU

The unbeatable advantage of sizing on the basis of pro-

Utilization of the database server is 34%; that of

duction data is that you can take your own data, pro-

the two application servers is 56%.

cesses, and settings into account. Quick Sizer has been

designed for new installations and contains assump-

213GB out of 512GB are occupied with a monthly

tions about the productive operation. For this reason,

we recommend Quick Sizer for initial sizings only.

Database
growth of 7GB.

Memory
26GB out of 32GB are being consumed.

Basic Analysis for All Production Sizings

By using a system monitor, the customer has found

For all production sizings, you must rst identify the uti-

out that approximately 1,254 named users out of a

lization of the sizing-relevant components in the exist-

total of 1,567 have been active during the period ana-

ing system. Using the appropriate monitors, which are

lyzed. Based on this information, you can now deter-

described in detail in Chapter 6, you can determine the

mine whether the existing hardware is sufcient or

following information:

whether it must be extended.

CPU Utilization
What is the actual utilization of the CPU? Can the

Resizing

existing hardware compensate for the future load?

A basic prerequisite for resizing is that only the through-

Here, you must distinguish between the utilization of

put and user volumes can change, but not the function-

the application server and that in the database.

ality. Based on the current load situation and the new

Memory Consumption

information, you can easily determine future require-

How much room for maneuver do you have regard-

ments using a rule of three.

ing the memory requirement: Will it increase or stay

Typical resizings occur in system consolidations or in

the same?

what is referred to as phased rollouts, in which customers

Database Space

install new software in different phases in their business

Take a look at the 30 biggest tables and indexes, and

units or international subsidiaries.

make a note: How quickly did they grow during the

last several months?

Resizing a Production System

Based on the above example (see previous box, Sam-

Once you have determined the current utilization or the

ple Analysis of a Production System), a resizing could

database growth and the increasing memory require-

look as follows: You want to add another 200 named

ments using the various vendor-specic monitors or the

users to the 1,567 existing ones. We assume that the

SAP monitors, you should relate this information to a

ratio between named users and active users is identical

simple business key gure. Usually this is the users, but

www.sap-press.com

13

2 Sizing Methods

among the new users and that they will do the same
as the existing users, so that we can make the following calculations:

Active Users
The ratio between 200 and 1,567 is 12%, which
means that the number of active users will probably increase by 12%.

CPU Database Server

34% + 12% corresponds to 34% 1.12 = 38.1%
A utilization of 38% is sufcient for a database
server. Many customers plan a target utilization of
25% to 50% for the database server.

CPU Application Server

56% + 12% corresponds to 56% 1.12 = 62.7%
The application servers can absorb a utilization of
62.7% quite well. However, many customers plan
a target utilization of 30% to 50% for the application servers, which is why an extension is at least

value, which can be specied by the hardware vendors at

any time and for each release. Based on this information
(available SAPS, software release, CPU utilization, new
SAPS), you can easily calculate whether the hardware will
be sufcient by using a rule of three.
Delta Sizing of a Production System
The above customer (see previous box, Resizing a Production System) has created a sizing for a new application. According to the sizing, the application will
require 1,200 SAPS (240 database SAPS and 960 application SAPS). What needs to be done now is easy: The
SAPS values must be added up, and the target utilization must be determined.
The existing hardware is evaluated as follows:

tions: 2,800 SAPS each

3,700 SAPS at the application level (i.e., 66% of

Main Memory

5,600 SAPS)

26GB (out of 32): 26GB 1.12 ~= 29GB

29GB out of 32GB of allocated memory might be
a bit tight. It is therefore advisable to extend the
memory.

Database Space
7GB of growth corresponds to 7GB 1.12 = 8GB per
month

For the database, this would mean the following: 1,360

SAPS + 240 SAPS = 1,600 SAPS which represents a
future utilization of 40%. The application servers reach
4,660 SAPS and a utilization of 83%, which could lead
the customer to the conclusion that it would make
sense to add another application server.
If you have followed the above descriptions of tools

Currently, 312GB out of 512GB are being used. If

the database grows by 96GB (8GB 12 months)
per year, bottlenecks can occur in a very short
time. Thus, the disk space should be extended.

The current net SAPS consumption for the database is 1,360 SAPS (i.e., 34% of 4,000 SAPS) and

conceivable here.

Database server: 4,000 SAPS; the two applica-

and methods closely, you will have noticed that SAP

calculates the standard sizings with a target utilization of 65% and you should therefore only use net
amounts. However, you should also take into account
that the delta is based on standard assumptions as

Delta Sizing

well, and the 65% factor could be a useful buffer.

But if you want to base your calculations on net

Because delta sizing can be performed only when new

functions are added to an existing software application,

amounts, you can do so as follows:

the procedure is similar to that of initial sizing, the only

The net requirement of the new application is 780

difference being that the sizing results are applied to the

SAPS (1,200 SAPS 0.65 target utilization). 160

current utilization.

SAPS out of the 780 SAPS are allocated to the

database, 620 SAPS to the application level.

However, there is one special characteristic you should

be aware of: The SAPs standard sizing rules specify the

Consequently, this means that we can expect a

CPU requirements in terms of SAPS and a target utili-

growth of approximately 10% for the database

zation of 65%. As we will demonstrate in Section 9.2,

and approximately 20% on the application side.

SAP Application Performance Standard, each hardware

conguration in the SAP environment has its own SAPS

14

Galileo Press 2007. All rights reserved.

2.4 Summary

Upgrade Sizing

Single-Instance Projects

In upgrade projects, customers usually implement numer-

From the point of view of sizing, the majority of single-

ous changes, which include the SAP software, database,

instance projects in which companies change from a best-

operating system, and an exchange of hardware. It often

of-breed strategy2 to a single-instance strategy (one soft-

happens that the conguration and parameter settings are

ware vendor, all data in one system) represent a mixture

changed as well. All this can have an impact on the num-

of resizing and delta sizing, sometimes also upgrade siz-

ber of work processes, buffer settings, or other things.1

ing. Note that an upgrade sizing must be performed rst

Upgrade sizing refers to the additional requirements

to make sure that identical conditions apply.

of SAP software. SAP uses regression tests to check the

resource consumption of the most important transactions

Considerations in the Context of a

and to create a delta. This information is made available

Single-Instance Study

to all customers in SAP Notes, such as SAP Note 901070,

A customer uses several SAP and legacy systems in

which describes the resource consumption between

Europe. This customer now wants to consolidate its

SAP ERP Core Component (SAP ECC) 5.0 and SAP ERP

European and American systems. Consequently, this

6.0. The SAP Notes provide information about the delta

means the following:

regarding the number of database calls, CPU require-

If the SAP software has different release versions,

an upgrade sizing must be performed rst. The rel-

ments, memory requirements, and database space.

evant factors will be upgraded so that all systems

Because these SAP Notes provide standardized infor-

have the same version.

mation about different transactions, they carry the risk of

you currently using a transaction that is counterbalanced

The next step involves resizing the SAP software

based on the same release version; that is, the cur-

by other transactions.

rent consumptions of existing SAP systems must

Sample Upgrade Sizing

be analyzed and totaled.

A (ctitious) SAP Note on delta resource consumption

Finally, a delta sizing must be performed for the

states that the resource consumption in the memory

legacy software. Ultimately, the additional require-

increases by 5% on average. Transactions A and F do

ments for the new software are added to the exist-

not show any additional consumption, whereas Trans-

ing load.

action G consumes an additional 30%. The CPU and

database consumptions remain unchanged.
If you as the customer now use Transaction G

2.4 Summary

extensively, this could cause problems when calculating the main memory. The best thing to do is to calcu-

Because SAP software shows a high degree of scalabil-

late a best case and a worst case.

ity, you can consider a linear change in consumption as

Memory (Best Case)

a given fact. The same applies to hardware: If you want

26GB (out of 32): 26GB 1.05 ~= 27.3GB

to extend the processing power of application servers,

Memory (Worst Case)

you can add more servers, replace the CPU, or add more

26GB 30% = 33.8GB

CPUs, depending on your specic production model.

Probably, the future memory requirement will be

within that range.

However, a new application server affects the databases memory requirements because it involves the
addition of new database users. A higher volume generally means an increase in read and write activities, which,

Since this is a very complex subject, SAP provides the SAP

GoingLive Functional Upgrade Check service as part of the
standard service coverage (see also Section 7.2, Verication
via Support Services). The SAP GoingLive Functional Upgrade
Check includes a sizing process.

in turn, may have an impact on the disk subsystem.

2

In a best-of-breed strategy, you always choose the product from the best vendor for each (technological) area. The
different products are then connected with each other via
interfaces.

www.sap-press.com

15

2 Sizing Methods

The sizing method used essentially depends on the initial

certain limitations. These limitations primarily depend on

position youre in. Basically, there are different methods

the way in which business processes and the associated

for an initial sizing, which can be mapped via standard

application software interact with each other. For this

tools, and for a production sizing, which uses production

reason, the following chapter, Sizing Approaches (Chap-

data as a basis for forecasting.

ter 3), describes how you can convert user-based and

In this chapter, we have mentioned several times that

although sizing tools are very useful, they are subject to

16

Galileo Press 2007. All rights reserved.

throughput-based sizings into algorithms, and discusses

the pros and cons of different sizing approaches.

Index

2-tier implementation 47

Computing Center Management System

3-tier implementation 47
80/20 rule 35

(CCMS) 51, 65, 68

Concurrent user 21
Consolidation phase 8

Core 18

A/P (Average and Peak) 44

Active user 21
Advanced sizing 10
Analysis
of customer data 11
of customer processes 11
performance monitor 51
transaction design 60
Application monitor (ST07) 54
Application profile 71

Core process
business 10, 65, 75
Core team 73

Extension phase 8

F
Frontend network 19, 21, 57

G
Garbage in, garbage out 32, 76

CPU 3, 15, 18, 66

GLC SAP GoingLive Check (GLC)

CPU load 24

GoLive 8

CPU time 3, 12, 23, 30, 57

CPU utilization 13

Custom development 8

Hardware budget planning 4, 71

Customer data

Hardware budget sizing 8

analyzing 11

Hardware costs 4, 71

Customer reference installation 23

Hardware vendor 35, 42, 71

Customizing 13, 17, 65

high-volume load tests 24

Average CPU sizing 49

Average load 48

Database 18, 39, 53

I/O (input/output)

Application server 14, 19, 46, 55

Application team 73
Archiving object 45

Database monitor 53

Database server 13

Baseline test 62
Benchmark result 30, 36
BI Accelerator Business Intelligence
Accelerator
Blank installation 46, 47
Blueprint phase 8
Business Intelligence Accelerator (BI
Accelerator) 18

Database space 13, 39

Data Dictionary 58

Implementation phase 8, 71, 76

Disk I/O operations 19, 39

Implementation project 27, 71, 74

Disk space

Initial sizing 8, 63, 75

database 14, 39, 47

DPU Logical Deployment Unit (DPU)

Chief Process Innovation Officer (CPIO) 4

Coding
custom 11, 59, 62

3-tier 47

Disk growth 53

Cache 27

Chief Information Officer (CIO) 4, 74

2-tier 47

Disclaimer 42

C
System (CCMS)

(IAS)
Implementation

Delta sizing 13, 14

Dual-stack installation 26

CCMS Computing Center Management

per second 39
IAS International Accounting Standard

Input error 41, 43

International Accounting Standard (IAS)
33
IT team 73

Employee Self-Services 75

Evaluation phase 74

Java-based

EWC SAP EarlyWatch Check (EWC)

Expert sizing 10, 29, 51, 76

application 25, 47
Java Virtual Machine (JVM) 57

Expressiveness
of sizing project 7

www.sap-press.com

107

Index

K
Key performance indicator 12, 17, 31

Physical memory 18

Single record statistics (STAD) 56

Processor 18

Sizing

Product availability 5

approach 17

Product Availability Matrix (PAM) 5, 18

by throughput 22

Production sizing 8, 12, 53, 67

by users 4, 20

Landscaping 6, 72, 78

Programming guidelines 30

definition 3

Latency 19

Project team 73

expressiveness 7

liveCache 18
Load test 12, 59
analysis 60
multi-user mode 61

formula 32

informational value 31
initial 8

Quick Sizer 35

methods 7, 8, 11, 16, 27

average CPU sizing 37

performing 61

measurement 12

CPU peak sizing 45, 48

planning 59

object 45

design principles 35

toolkit 24

principle 3

documentation 36, 41, 42

tools 60

production 8, 51, 63

functions 36, 40

Local area network (LAN) 17, 73

production sizing 13

navigation 41

Logged-on user 21

result 40, 46

peak CPU sizing 37

Logical Deployment Unit (DPU) 46

scope 20

project 36, 41, 47

questionnaires 37, 41, 47

Master data sizing 22, 26

Save function 41

Maximum Extended Memory in Transac-

sizing element 38, 44, 47, 48

throughput-based 38, 44
tool 11, 29, 51

result 38

tion 57

user-based 20, 38
verification 59, 63
Sizing project 71

application team 73

Reference database 23

definition 72

reference installations 23

documentation 74, 77

Residence time 19, 27

execution 71, 74

Resizing 12, 13, 63

goal 74

Resource consumption 15, 24

Named user 20

IT team 73

Rule of thumb 29

planning 71

procedure 74

Memory consumption 13
Memory requirement 40, 52, 56, 57
Methods 7
Minimum requirement 5

core team 73

Network load 19
Network traffic 32
Non-disclosure policy 23

project scope 71
stakeholders 72

SAP Application Performance Standard

success factors 71

(SAPS) 10, 38, 40, 50

SAP EarlyWatch Check (EWC) 67

Software architecture 31

Offline questionnaire 33

SAP GoingLive Check (GLC) 63

Status 42

Online Analytical Processing 29

SAP GoingLive Functional Upgrade Check

System consolidation 13, 15

Operating system monitor 52

Orientation phase 8

15, 63, 68

System GoLive 63, 67

SAP NetWeaver

System integration 65

Business Intelligence 21, 40, 58

Portal 21, 44

PAM Product Availability Matrix (PAM)

Process Integration 4

T-shirt sizing 9, 30

Peak load 48, 49

SAPS 40

Target utilization 14, 50

Peak sizing 49

SAP Solution Manager 64

Throughput-based CPU sizing 45

Performance analysis (ST30) 12

SAP Standard Application Benchmarks

Throughput sizing 22, 23

Performance monitor 51

23

Throughput sizing model 23

Performance trace (ST05) 51, 57

Scalability 3, 61

Throughput volume 7

Phased rollout 13

Sessions 21

Total cost of ownership (TCO) 4

Phases

Single-instance project 15

Trace tool 51, 57

Single-user analysis 12

Transaction DB02 53

of sizing projects 7

108 Galileo Press 2007. All rights reserved.

Index

Transaction ST05 57

active 21

Transaction ST06 52

concurrent 21

Transaction ST07 54

interaction step 52, 57

Transaction STAD 56

logged-on 21

U
Upgrade phase 8
Upgrade sizing 13, 15, 63, 67, 75

named 20
User-based sizing 20, 38
User interaction step 57

Usage type 47

User

Verification 77

of sizings 59, 63

W
Wide area network (WAN) 17, 73
Work days
in Quick Sizer 42

www.sap-press.com

109