Sizing SAP Systems

Susanne Janssen, Ulrich Marquard

Contents
1 Introduction

.........................................3

Basic Considerations and Assumptions

Sizing Defi nition................................... 3

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

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

Advantages and Disadvantages

Business Management and Technology 4

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

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

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

Target Group and Structure of the

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

Book ......................................................5

Conclusion ..........................................24

Related Topics ........................................5

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

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

2 Sizing Methods

......................................7

Calculating Memory Requirements .... 25

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

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

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

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

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

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

Advanced Sizing ..................................10

3.5 Conclusion................................................. 27

Expert Sizing....................................... 10
Standard Tools Even for Experts.......11

4 Sizing Tools .............................................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

Basic Analysis for All Production

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

Sizings.................................................... 13

4.2 T-shirt Sizing................................................ 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 Offl ine Questionnaire................................... 33

2.4 Summary ......................................................15

4.5 Summary ......................................................33

3 Sizing Approaches

5 Quick Sizer

................................17

..............................................35

3.1 Factors That Infl uence Sizing......................... 17

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

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

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

3.3 Overview of Different Sizing

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

Approaches.................................................. 20

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

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

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

Advantages and Disadvantages of

Initial Page.......................................... 41

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

Navigation Tree ....................................41

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

Header Bar ..........................................41

www.sap-press.com 1

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

6 Performance Monitors and Traces

... 51

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

Get Confi rmation from Stakeholders

77

8.4 Summary ......................................................78

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

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

9 Sizing Details

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

9.1 Basic Foundations of the SAP Sizing

........................................79

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

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

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

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

Application Services and Database

7 Sizing Verifi cation

.................................59

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

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

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

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

Allocating Suffi cient Memory

Phase 1: Performing Individual

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

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

Allocating Suffi cient 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 Verifi cation 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 .........92

SAP GoingLive Functional Upgrade

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

Check ..................................................68

Step 1: Defi ne the Test Case................ 94

7.3 Summary ......................................................69

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

Step 3: Create the Test Case in the

8 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

Defi nition of a Sizing Project............... 72

8.2 Project Team .................................................73

10 Summary and Outlook

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

8.3 Methodical Procedure................................... 74

Step 1: Defi ne Project Contents and
Goals ......................................................74

A Frequently Asked Questions

Step 2: Determine Performance-Critical

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

Processes ..............................................75

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

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

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

Step 3: Decide on the Approaches and

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

B Literature and Links

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

Step 4: Defi ne Milestones and Prepare

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

Galileo Press 2007. All rights reserved.

Index

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

2 Sizing Methods
the
sales orders and sales order items are much more
critical to CPU sizing since they represent transaction data. In terms of revenue, an average of 2,000
sales orders per day is quite considerable; however,
from the point of view of software, this is not a high
throughput volume . SAP has several customers who
process more than a million sales order items per day.

Sizing projects are carried out at very different

stages of

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

an SAP project. They represent an iterative process

that

depends

closely

on

the

amount

of

information that is available to you at a certain

point in time to make reliable statements on the
actual hardware requirements.
Accordingly, in each sizing project, you will often
face new situations that you must react to with
different methods and, consequently, using different tools. This
chapter focuses on these different methods .

2.1 Phases of Sizing Projects

SAP regularly receives information requests like
the following:
We are a large customer in the consumer goods
industry with 30,000 business partners and 60,000
sales
orders containing 50 line items per month. How
much
hardware do we need for our SAP application?
This is a rather general question. The customer
needs
information about hardware for a fi rst estimate.
The
question itself does not indicate why this is a
large
customer. Perhaps the customer is only looking
for a
partial solution since the volumes mentioned
indicate
that this customer is a large medium-sized
company.
The business partners represent master data and
are
not yet relevant to sizing because they do not
generate any load during live operation. In contrast,

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

informational
value of the sizing project

can vary, depending on

the
different phases. In addition, you should note that
not
all the phases described in Table 2.1 have to occur in
an
sizing). Moreover, we are using several custom developments. How should we carry out a sizing

SAP project.
Thus, if the system GoLive is still way down the
road

project?

and you as a customer are not yet very familiar

This question refers to a specifi c

with

component in
accounting and is therefore more detailed.
Perhaps this customer has already carried

www.sap-press.com 7

out sizing projects for other SAP

applications and wants to perform another
one for this particular application. In addition, the customer wants to know how
sizing can be done for proprietary
developments.
We are planning to consolidate our seven
data centers
into one. Can we simply add up existing
sizings?
This question (which comes from an existing
SAP
customer) refers to a system consolidation
process
in which additional hardware requirements
must be
taken into account if the different existing
systems
are combined. System consolidation and
singleinstance concepts, which are used to check
whether
all systems can be globally integrated with
one database, are currently red-hot issues with our
customers.
We are currently running Release SAP R/3
4.6C and
want to upgrade to SAP ERP 6.0. What are
the upgrade
factors?
This customer uses a specifi c release that he
wants to upgrade across multiple releases in
one step and therefore wants to know if
new hardware needs to be purchased for
that.
By

further

analyzing

these

kinds

of

requests, we ultimately get to the different phases in which

you can perform sizing projects

(see Table

2.1). The

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 specifi c releases.

Blueprint phase (Phase B) 12 to 6 months

prior to GoLive

The fi 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 specifi c 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

time, customer-specifi c data can be

analyzed.
the software, you will probably have only basic
information on how you are going to use it so that you
can at least make a rough estimate of the costs
involved. During the course of the implementation
project, you can refi ne your initial assumptions by
using standard sizing rules in order to take a closer
look at the critical issues.
If an installations complexity differs too much
from
the standard, you can, for instance, measure
customer

The following sections describe the

characteristics of
these different sizings in greater detail.
At this point it is
important to know that sizings can be
performed within
several phases of a project: Sizing is an
iterative process.
Budget sizing, for example, could be
done in phases A
and B, advanced sizings in phases A
through C, expert siz-

processes in order to create customer-specifi c

sizings.
All these different phases require different sizing
methods. In this context, we generally distinguish
between initial and production sizings

. Figure 2.1 provides an

overview of the available sizing methods, with initial

sizings
being shown in the upper section and
production sizings in the lower one. Expert sizing is marked as a
hybrid
because under certain circumstances, some
processes can
be mapped using standard methods while, at the
same

Galileo Press 2007. All rights reserved.

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

in phase E, and upgrade sizings in phase F.

2.2 Methods for Initial Sizings

Initial sizings are sizings that refer to new installations,
that is, installations in which you use SAP software for
the fi rst time. That is also the case if, for instance, you
want to use SAP SRM for the fi rst time while SAP ERP
is already running in your companys production system
at least the sizing for SAP SRM will be considered as
being initial.
Depending on the project phases, we differentiate initial sizings into hardware budget sizings (budget sizings for
short), advanced sizings, and expert sizings. Usually, budget
sizings and advanced sizings are based on tools, whereas
expert sizings are a mixture of tools and additional rules or measurements.
Hardware Budget Sizings
The main characteristic of budget sizings is that they
dont require much information from the customer and
they contain many assumptions (i.e., values provided by
SAP based on experience). For example, if the only infor-

2.2 Methods for Initial Sizings

Hardware Budget Sizing

Smaller Companies
_

Very simple algorithms

Assumptions,

likelihoods

Advanced Sizing
Medium

to

Large

Companies
_

Throughput estimates
Questionnaires,

Level setting of project

formulas

Risk identification

Usage

of

Expert Sizing

Live Go-

Large/Complex Projects
_

Additional guidelines

Custom calculations

Analysis of custom coding

Custom sizing guidelines

standard

tools

Initial Sizings

Focus on core business

processes

Resizing

All Projects

All Projects
_

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)

Upgrade Sizing

Delta Sizing
All Projects
_

SAP system monitors

SAP Notes

Goal: Upgrade SAP software

SAP system monitors

Goal: Extend an existing

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

Post GoLive Sizings

Figure 2.1

Overview of Sizing Approaches and Methods

1

tage is that the rough categorization into S through XL

mation you have is that 100 users will use SAP CRM,
but
you dont know the other applications they will
use and
what will be their average activity, you can
certainly perform the sizing, but in the long run, the
informational
value provided by the result of the sizing process
will be
too restricted.
For this reason, budget sizings are usually
performed way ahead of the GoLive phase
(most of the time in Phase A) if the goal is to
estimate the approximate scope of hardware.
For budget sizings, you can use the user-based
sizing
function in SAPs Quick Sizer (see Chapter 5, Quick
Sizer).
Alternatively, you can use T-shirt sizings

(see

Section 4.2,
T-shirt Sizing), which have the advantage of
requiring you
to answer only a few questions. Of course, the
disadvan-

provides only limited informational value. Occasionally,

such sizings can be suffi cient, depending on the specifi c
situation.
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.

Budget Sizings Help in Estimating the Entire Size

Lets suppose a budget sizing determines
4,000 SAPS
(SAP Application Performance Standard 1).
Currently,
4,000 SAPS correspond more or less to a
dual-core
machine

(server)

with

two

processors,

which has a list

price of $15,000. Now you can make up
your mind
whether it makes sense to tackle a rather
intensive sizing process or whether you want to take
one of the following two risks:
Result Is Too High
This means the server will not be fully
utilized during live operations. A result that is too
high often
occurs because the initial estimates are
usually too
conservative.
Result Is Too Low
This means that you must buy additional
hardware. In this case, the question is
whether you can
afford to use the wrong assumptions.
Lets suppose your initial estimate is wrong by
100%. You
1
See Section 9.2, SAP Application Performance
Standard, for a
more detailed description of SAPS.

www.sap-press.com 9

2 Sizing Methods

locks
an

object

and

can

become

performance bottleneck
because all other requests have to wait
would then have to pay (in the above example)

until the object is

an additional $15,000

released again.

- $20,000

for a

correspond-

Thus, in an advanced sizing process,

ingly bigger server. There are some customers

you focus more

for

on the core business processes . Quick Sizer

whom expenses in this range are critical,

is able to map

since the

the key processes of the SAP Business

implementation

of

new

production

Suite and tries to

server also involves the purchase of new

break

quality

scenarios into the most

assurance

systems

and

testing

landscapes.

down

the

complex

business

important transactions and objects. In

addition, Quick
Sizer provides the option to fi ne-tune the

Advanced Sizing
If youre in a situation in which theres a high risk
of misjudging

the

requirements

by

several

100

percents, you
should refi ne your budget sizing by using what is
referred
to as advanced sizing. For example, if the range of
CPU
power youre dealing with is between 8 and 16
cores, a
more detailed sizing makes a lot of sense because
it pro-

CPU sizing in
that it distinguishes between the average
CPU utilization
(average sizing) and the utilization at peak
times (peak sizing):
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

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

can use
additional functions of Quick Sizer, such as its
throughput-based functionality, which allows you to
determine
the CPU load on average as well as by peak load (see
Section 5.3, Average and Peak Sizing).
Usually, advanced sizing occurs in phases B and
C. In
these phases, the fi rst business blueprints have
already
been created so that important and sizing-relevant
information about the business software applications is
available to you. This information could include, for
instance,
a PC vendors decision about which important
materials are imperative that an availability check be
performed
for (processors, for example). An availability check

10 Galileo Press 2007. All rights reserved.

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

load, you can, of course, specify them.
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
of by user-based sizing.
The drawback of advanced sizing is that you have to
familiarize yourself with the core business processes in
order to obtain the appropriate information from the
user departments for the Quick Sizer questionnaire. This
certainly takes more time than asking for the number of
users (as is done, for instance, in a budget sizing process), but it
is much more accurate.
Note that advanced sizing is still a tool-based process.
An XL category in Quick Sizer represents a large category in the tool-controlled area, but not necessarily in
the entire sizing context. For example, in Quick Sizer, the
largest category (XXL) starts at 30,000 SAPS. A number
of large customers operate on 40,000 to 100,000 SAPS;
a few other customers operate in the range of 300,000
SAPS and higher.
Expert Sizing
For ranges of 30,000 SAPS and higher, SAP therefore recommends that its customers not rely exclusively on one
sizing tool but rather that they analyze the core processes
and, above all, the customer processes in great detail via
expert sizing.
This method is particularly suited for complex business transactions, in-house developments, and largescale installations. Complex business transactions may also
occur in smaller installations, such as in the supply chain or
in retailing systems. Global installations, which are not only
defi ned by their size, are also eligible candidates for expert sizing because of the time differences that
must be taken into account.
To be able to perform an expert sizing process, you must
have:

2.2 Methods for Initial Sizings

have been caused by custom coding .

Identifi ed 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.
Expert sizings are performed just before the
system GoLive, that is, when the functionality has
been clearly defi ned 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.
Basically, this method

consists, on the one

hand, of a mixture of standard sizing

and

performance tools, and on the other, of additional

procedures

and

analyses.

We

can

roughly

the

sizing

tools

subdivide these two parts into:

The

full

utilization

of

functionality (in particular, Quick Sizers) so that

they meet specifi c requirements at least in
part.
The analysis and performance monitoring of
core processes in the customer system.
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.
Standard Tools Even for Experts
Whenever

you

have

identifi

ed

business

transactions as
being close to the standard, you can use Quick
Sizer (see
Chapter 5). That is, you can use Quick Sizer for
partial
sizings.
Another option for using Quick Sizer in expert
sizing is that you can use it for optimizing process
fl 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 profi le provided by Quick
Sizer to ascertain whether it is possible to perform
moves (see also Section 5.3, Average and Peak
Sizing). Quick Sizer enables you to map and
document additional loads which, for example,

extension
made in the customer system, the same
process
that was mapped in Quick Sizer now needs
Simplifi ed Example of Expert Sizing

more

A company uses SAP CRM applications to

resources.

enter sales

The customer is now able to increase the

orders and uses SAP ERP for sales order fulfi

ERP

llment and

result for sales order processing by 30% in

HR. The sales order processing functions in

such

the ERP

a way that the customer multiplies the

system have been custom-coded.

Quick

For this reason, a mixed approach is used

in expert

Sizer result by a factor of 1.3. Other results

(for instance, in HR) are not affected by this.

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:
First the company uses Quick Sizer to
create a
standard sizing for sales order entry in
SAP CRM.
Because the sales orders that have been
entered

Analyzing Customer Data

One of the most important tasks of expert sizing
consists
of analyzing specifi c customer processes . Typical
cases in
which it makes sense to analyze the performance fi
gures
on the basis of custom data because of the strong
inherent customer-specifi c nature include the following:

in the CRM system are further processed

in the
ERP system, a certain amount of extra
capacity is
added to the sending system, that is,
SAP CRM,
according to the corresponding sizing
rules.
The sizing of SAP ERP is mapped in Quick
Sizer on
the basis of the total number of orders.
The fact
that the orders are transferred through
an interface does not negatively affect the
performance
of the ERP system (on the contrary, it
has, rather,
a positive effect because there is no user
interaction). This sizing represents the basic
structure of
the ERP sizing.
Because the company does not know up
front
what the impact of extending the sales
order processing will be, it performs performance
measurements that show that, because of the

www.sap-press.com 11

2 Sizing Methods

about
the locking procedure or memory
requirements.
In the sizing environment, load tests

Variant confi guration that evaluates complex

object

have a hybrid
nature: On the one hand, you can use

dependencies: Its runtime can hardly be

them as a siz-

anticipated in the standard, if at all.

ing tool. On the other hand, you can

Each custom extension.

use them to
verify sizing results. Because customers

To analyze customer data, the following two

usually use

methods are available: single-user analysis and the

them to verify sizing results, you can fi

load test .

nd detailed

Single-user Analysis

information on them in Section 7.1, Load

Single-user analysis is based on a relatively

Tests.

simple
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
performance monitors of the SAP system to
measure the CPU time , memory consumption, or
database growth on your hard disk, depending on
your requirements. You can then use this data
in a rule of three to create the sizing forecast.
Table

2.2

provides

an

overview

of

the

procedure to
be applied in a single-user analysis, from defi
ning an
appropriate test case to applying the customerspecifi c sizing rule. Chapter 6, Performance
Monitors
information

and

Traces,

on

contains

sizing-based

detailed

performance

measurements.
Step

Description

Defi ne test case

Identify test system

Create test case in test system

Measure sizing KPIs

Implement measurement results in sizing method

Apply sizing rule

Table 2.2

Steps in Creating a Sizing Rule

Load Test
Load tests are occasionally used in the context
of
expert sizings and make sense when a single-user
analysis does not provide suffi cient information

12

Galileo Press 2007. All rights reserved.

Sizing Measurement Versus Performance Analysis

Note that sizing measurements refl ect only the actual
status. Based on sizing measurements, you can determine whether a business transaction is scalable. In
this context, scalability means that the resource consumption increases linearly with the number or size
of the processed projects. If a process is not scalable,
you must analyze and resolve the problem in a performance subproject.

The advantages of expert sizing over other sizing methods are found in the higher degree of accuracy and reliability of the information. If you manage a sizing project
for a complex or large customer, you should defi nitely
consider aspects from expert sizing, even though the collection and analysis of the information takes more time.

2.3 Sizings Based on Productive Customer

Data
Sizing is an iterative process that is, even operational
installations can be subject to change processes that
affect the resource requirements, as the following examples will show:
You want to consolidate your existing system landscape (for example, by merging all your international
subsidiaries on one server).
You want to add additional functions to an existing system
(for example, by installing a CRM system on a server that
already hosts an ERP system).
You want to upgrade Release X to Release Y.
All these situations can affect the hardware and require a
more or less comprehensive sizing project. The major
advantage of sizings that are based on a production system is that you can use your own data and settings as a
basis. In other words, you do not need to rely on assumptions made by SAP.
Regarding production sizings , we distinguish between
the following three methods, which pursue different
goals:
Resizing
In a resizing project, the throughput or user volume

2.3 Sizings Based on Productive Customer Data

Once you have determined the current utilization or the

database growth and the increasing memory requirements using the various vendor-specifi c monitors or the
changes, but not the processes (or customizing
or
parameter settings, and so on).
Delta Sizing
In a delta sizing project, you add new
functionality. Upgrade Sizing
An upgrade sizing involves a change of the
SAP release.
Common to all these sizing methods is that you
must fi rst analyze the status of the existing
system before you can plan the new hardware
requirements.
Production System Sizings Versus Quick Sizer
The unbeatable advantage of sizing on the basis
of production data is that you can take your own
data, processes, and settings into account. Quick Sizer has
been
designed for new installations and contains
assumptions about the productive operation. For this
reason,
we recommend Quick Sizer for initial sizings only.
Basic Analysis for All Production Sizings
For all production sizings, you must fi rst identify
the utilization of the sizing-relevant components in the
existing system. Using the appropriate monitors,
which are described in detail in Chapter 6, you
can determine the following information:
CPU Utilization
What is the actual utilization of the CPU? Can
the existing hardware compensate for the future
load? Here, you must distinguish between the
utilization of the application server and that in
the database.
Memory Consumption
How much room for maneuver do you have
regarding the memory requirement: Will it increase
or stay the same?
Database Space
Take a look at the 30 biggest tables and indexes,
and make a note: How quickly did they grow
during the last several months?

SAP monitors, you should relate this information to a

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

Based on the above example (see previous box,

Sample Analysis of a Production System), a resizing
it can also be projects or calls. Alternatively, you can also
use the number of activities or sales orders,
depending, on the one hand, on which unit is
best suited to refl ect the respective business
activity, but also, on the other, on how easily it
can be determined.

could
look as follows: You want to add another 200
named
users to the 1,567 existing ones. We assume that
the
ratio between named users and active users is
identical

Sample Analysis of a Production System

The following example forms the basis for
the descrip-

www.sap-press.com 13

tion of individual sizing methods. A

customer uses
strategic procurement in the SRM
environment. The
analysis of the current utilization provides
the following result:
CPU
Utilization of the database server is
34%; that

of the

two application

servers is 56%.
Database
213GB out of 512GB are occupied with
a monthly growth of 7GB.
Memory
26GB out of 32GB are being consumed.
By using a system monitor, the customer
has found
out that approximately

1,254 named

users out of a
total of 1,567 have been active during the
period analyzed. Based on this information, you can
now determine whether the existing hardware is
suffi cient or whether it must be extended.
Resizing
A basic prerequisite for resizing is that only
the throughput and user volumes can change, but not
the functionality. Based on the current load situation
and the new information, you can easily
determine future requirements using a rule of three.
Typical

resizings

consolidations
phased rollouts,

occur

in

system

or in what is referred to as
in which customers install

new software in different phases in their

business units or international subsidiaries.
Resizing a Production System

2 Sizing Methods

sizing results are applied to the current

utilization.
However,

there

is

one

special

characteristic you should

among the new users and that they will do the
same

be aware of: The SAPs standard sizing

as the existing users, so that we can make the

CPU requirements in terms of SAPS and

follow-

rules specify the

a target utili-

ing calculations:

zation of 65%. As we will demonstrate

Active Users
The ratio between 200 and 1,567 is 12%,
which means that the number of active
users will prob-

in Section 9.2,
SAP Application

Performance

Standard,

each hardware
confi guration in the SAP environment has

ably increase by 12%.

its own SAPS

CPU Database Server

34% + 12% corresponds to 34% 1.12 =
38.1% A utilization of 38% is suffi cient 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 conceivable here.
Main Memory
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
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.

Delta Sizing
Because delta sizing can be performed only when
new functions are added to an existing software
application, the procedure is similar to that of
initial sizing, the only difference being that the

14 Galileo Press 2007. All rights reserved.

value, which can be specifi ed 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
suffi cient 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:
Database server: 4,000 SAPS; the two applications: 2,800 SAPS each
The current net SAPS consumption for the database is 1,360 SAPS (i.e., 34% of 4,000 SAPS) and
3,700 SAPS at the application level (i.e., 66% of
5,600 SAPS)
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
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
well, and the 65% factor could be a useful buffer.
But if you want to base your calculations on net
amounts, you can do so as follows:
The net requirement of the new application is 780
SAPS (1,200 SAPS 0.65 target utilization). 160 SAPS
out of the 780 SAPS are allocated to the
database, 620 SAPS to the application level.
Consequently, this means that we can expect a
growth of approximately 10% for the database
and approximately 20% on the application side.

2.4 Summary

and database consumptions remain unchanged.

If you as the customer now use Transaction G
extensively, this could cause problems when calculatUpgrade Sizing
In upgrade projects, customers usually implement
numerous changes, which include the SAP software,
database,
operating system, and an exchange of hardware. It
often
happens that the confi guration and parameter

ing the main memory. The best thing to do is to calculate a best case and a worst case.
Memory (Best Case)
26GB (out of 32): 26GB 1.05 ~= 27.3GB
Memory (Worst Case)
26GB 30% = 33.8GB
Probably, the future memory requirement will be
within that range.

settings are
changed as well. All this can have an impact on the
number of work processes, buffer settings, or other
things.1
Upgrade sizing refers to the additional
requirements
of SAP software. SAP uses regression tests to check
the
resource consumption of the most important
transactions
and to create a delta. This information is made
available
to all customers in SAP Notes, such as SAP Note
901070,
which describes the resource consumption
between
SAP ERP Core Component (SAP ECC) 5.0 and SAP
ERP
6.0. The SAP Notes provide information about the
delta
regarding the number of database calls, CPU
requirements, memory requirements, and database space.
Because these SAP Notes provide standardized
information about different transactions, they carry the
risk of
you currently using a transaction that is
counterbalanced
by other transactions.
Sample Upgrade Sizing
A (fi ctitious) SAP Note on delta resource
consumption
states that the resource consumption in the
memory
increases by 5% on average. Transactions A and
F do
not show any additional consumption, whereas
Transaction G consumes an additional 30%. The CPU

1 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, Verifi cation
via Support Services). The SAP GoingLive Functional Upgrade
Check includes a sizing process.

you want
to extend the processing power of application
servers,
you can add more servers, replace the CPU , or add

Single-Instance Projects
From the point of view of sizing, the majority
of singleinstance projects in which companies change
from a bestof-breed strategy2 to a single-instance strategy
(one software

vendor,

all

data

in

one

system)

represent a mixture of resizing and delta

sizing, sometimes also upgrade sizing. Note that an upgrade sizing must be
performed fi rst to make sure that identical
conditions apply.
Considerations in the Context of a
Single-Instance Study
A customer uses several SAP and legacy
systems in

more
CPUs, depending on your specifi c production model.
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,
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.

Europe. This customer now wants to

consolidate its
European

and

American

systems

Consequently, this
means the following:
If the SAP software has different release
versions,
an upgrade sizing must be performed fi
rst. The relevant factors will be upgraded so that all
systems
have the same version.
The next step involves resizing the SAP
software
based on the same release version; that
is, the current

consumptions

of

existing

SAP

systems must
be analyzed and totaled.
Finally, a delta sizing must be performed
for the
legacy

software.

Ultimately,

the

additional requirements for the new software are added to

the existing load.

2.4 Summary
Because SAP software shows a high degree of
scalability, you can consider a linear change in
consumption as
a given fact. The same applies to hardware: If

www.sap-press.com 15

2 Sizing Methods

16 Galileo Press 2007. All rights reserved.

The sizing method used essentially depends on the

initial
position youre in. Basically, there are different
methods for an initial sizing, which can be
mapped via standard tools, and for a production
sizing, which uses production data as a basis for
forecasting.
In this chapter, we have mentioned several
times that
although sizing tools are very useful, they are
subject to

certain limitations. These limitations primarily depend on

the way in which business processes and the associated
application software interact with each other. For this
reason, the following chapter, Sizing Approaches (Chapter

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

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

(CCMS) 51, 65, 68

80/20 rule 35

Concurrent user 21

Consolidation phase 8
Core 18

A/P (Average and Peak) 44

Core process

Active user 21

business 10, 65, 75

Advanced sizing 10
Analysis
of customer data 11
performance monitor 51
transaction design 60

Application server

Average CPU sizing 49

Average load 48

Hardware budget planning

Accelerator

Business

Intelligence

Data Dictionary 58
Delta sizing 13, 14

Disk I/O operations 19, 39

Blueprint phase 8
Business Intelligence Accelerator
(BI

Disk space
database 14, 39, 47
DPU

Accelerator) 18

Logical Deployment Unit

(DPU)
Dual-stack installation 26

C
Computing

Center

Management
System (CCMS)
Chief Information Officer (CIO) 4, 74
Chief Process Innovation Officer (CPIO)
4
Coding
custom 11, 59, 62

per second 39
IAS

International

Accounting

Standard
(IAS)
Implementation
2-tier 47
3-tier 47
Implementation phase 8, 71, 76
Implementation project

27, 71,

74
Initial sizing 8, 63, 75
Input error 41, 43
International

Cache 27
CCMS

high-volume load tests 24

Disk growth 53

Blank installation 46, 47

35, 42,

71

I/O (input/output)

Disclaimer 42

Accelerator

Hardware vendor

Database space 13, 39

Benchmark result 30, 36

Hardware costs 4, 71

Database 18, 39, 53

Database server 13

4,

71 Hardware budget sizing 8

D
Database monitor 53

Baseline test 62
BI

CPU utilization 13

23 Customizing 13, 17, 65

Archiving object 45

SAP GoingLive Check (GLC)

CPU time 3, 12, 23, 30, 57

Customer reference installation

55 Application team 73

Garbage in, garbage out 32, 76

GoLive 8

analyzing 11

14, 19, 46,

G
GLC

Customer data

54 Application profile 71

Frontend network 19, 21, 57

CPU 3, 15, 18, 66

Custom development 8

Application monitor (ST07)

Core team 73
CPU load 24

of customer processes 11

Extension phase 8

Accounting

Standard

(IAS)
33

Employee Self-Services 75
Evaluation phase 74
EWC

SAP EarlyWatch Check

IT team 73

(EWC) Expert sizing 10, 29, 51, 76

Expressiveness

Java-based

of sizing project 7

application 25, 47
Java Virtual Machine (JVM) 57

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,

by throughput 22

Landscaping 6, 72, 78

18 Production sizing 8, 12, 53, 67

by users 4, 20

Programming guidelines 30

definition 3

Project team 73

expressiveness 7

Latency 19
liveCache 18
analysis 60

informational value 31
initial 8

Quick Sizer 35

multi-user mode 61

methods

average CPU sizing 37

performing 61

object 45

design principles 35

toolkit 24

principle 3

documentation 36, 41, 42

tools 60
Local area network (LAN)

production 8, 51, 63

functions 36, 40

17,

production sizing 13

navigation 41

73 Logged-on user 21

result 40, 46

peak CPU sizing 37

Logical Deployment Unit (DPU) 46

scope 20

project 36, 41, 47

throughput-based

questionnaires 37, 41, 47

Maximum

Extended

Memory

sizing element 38, 44, 47, 48

Transaction 57
Memory consumption 13
Memory requirement 40, 52, 56,
57 Methods 7

user-based 20, 38

Save function 41

in

verification 59, 63
Sizing project 71

application team 73

Reference database 23

definition 72

core team 73

reference installations 23

documentation 74, 77

Residence time 19, 27

Minimum requirement 5

execution 71, 74

Resizing 12, 13, 63

goal 74

Resource consumption 15, 24

planning 71
procedure 74

Network load 19
Network traffic 32

project scope 71

SAP

Non-disclosure policy 23

Application

success factors 71

Standard

O
Offline questionnaire 33
Processing

29
Operating system monitor 52
Orientation phase 8

Software

31 Status 42

SAP GoingLive Check (GLC) 63

System consolidation

SAP GoingLive Functional Upgrade

15 System GoLive 63, 67

Check

System integration 65

15, 63, 68
21, 40,

58
Product Availability Matrix

Performance

analysis

Throughput-based CPU sizing

45 Throughput sizing 22, 23

SAPS 40

Peak sizing 49
(ST30)

Performance trace (ST05)

SAP Solution Manager 64

SAP

12 Performance monitor 51
51,

57 Phased rollout 13
Phases
of sizing projects 7

Standard

Application

Benchmarks
23
Scalability 3, 61
Sessions 21
Single-instance project 15
Single-user analysis 12

108 Galileo Press 2007. All rights

reserved.

T-shirt sizing 9, 30
Target utilization 14, 50

Portal 21, 44
Process Integration 4

(PAM) Peak load 48, 49

13,

SAP NetWeaver

architecture

SAP EarlyWatch Check (EWC) 67

Business Intelligence

PAM

stakeholders 72

Performance

(SAPS) 10, 38, 40, 50

Analytical

IT team 73

Rule of thumb 29

Named user 20

38,

44 tool 11, 29, 51

result 38

Master data sizing 22, 26

7, 8, 11, 16,

27 measurement 12

CPU peak sizing 45, 48

planning 59

Online

formula 32

Load test 12, 59

Throughput sizing model 23

Throughput volume 7
Total cost of ownership (TCO)
4 Trace tool 51, 57
Transaction DB02 53

Index

Transaction ST05 57

active 21

Transaction ST06 52

concurrent 21

Transaction ST07 54

interaction step 52, 57

Transaction STAD 56

logged-on 21
named 20

User-based sizing 20, 38

Upgrade phase 8
Upgrade sizing

13, 15, 63, 67,

User interaction step 57

75 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