Sap Sizing Example

www.sap-press.com 1

Sizing SAP® Systems

Susanne Janssen, Ulrich Marquard

Contents

1 Introduction ................................................. 3

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

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

Business Management and Technology 4

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

Target Group and Structure of the

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

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

2 Sizing Methods ........................................... 7

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

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

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

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

Expert Sizing .......................................... 10

Standard Tools — Even for Experts ....... 11

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

2.3 Sizings Based on Productive Customer Data .... 12

Basic Analysis for All Production

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

Resizing .................................................. 13

Delta Sizing ............................................ 14

Upgrade Sizing ....................................... 15

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

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

3 Sizing Approaches ..................................... 17

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

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

3.3 Overview of Different Sizing

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

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

Advantages and Disadvantages of

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

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

Basic Considerations and Assumptions

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

Advantages and Disadvantages

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

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

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

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

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

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

Calculating Memory Requirements ....... 25

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

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

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

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

4 Sizing Tools ................................................... 29

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

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

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

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

Categories .............................................. 31

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

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

4.4 Offl ine Questionnaire ....................................... 33

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

5 Quick Sizer ................................................... 35

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

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

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

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

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

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

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

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

2 © Galileo Press 2007. All rights reserved.

Contents

Questionnaires ....................................... 43

Results Page ........................................... 45

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

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

6 Performance Monitors and Traces ...... 51

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

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

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

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

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

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

7 Sizing Verifi cation ...................................... 59

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

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

Phase 1: Performing Individual

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

Phase 2: Analyzing the Transaction

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

Phase 3: Load Tests in Multi-User

Mode ..................................................... 61

7.2 Verifi cation via Support Services ....................... 63

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

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

SAP GoingLive Functional Upgrade

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

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

8 Executing Sizing Projects ........................ 71

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

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

Project Scope ......................................... 71

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

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

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

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

Step 1: Defi ne Project Contents and

Goals ...................................................... 74

Step 2: Determine Performance-Critical

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

Step 3: Decide on the Approaches and

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

Step 4: Defi ne Milestones and Prepare

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

Step 5: Acquire Information and Apply

the Methods .......................................... 76

Step 6: Analyze First Results and Adapt

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

Step 7: Consolidate the Results and

Get Confi rmation from Stakeholders .... 77

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

9 Sizing Details ............................................... 79

9.1 Basic Foundations of the SAP Sizing

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

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

Application Services and Database

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

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

Allocating Suffi cient Memory

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

Allocating Suffi cient Disk I/O

Capabilities (or: Modeling Disk I/O

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

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

Measuring Resource Consumption ....... 88

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

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

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

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

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

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

Step 3: Create the Test Case in the

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

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

Step 5: Create Sizing Guidelines Based

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

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

10 Summary and Outlook ............................ 101

A Frequently Asked Questions ................. 103

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

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

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

B Literature and Links .................................. 105

Index ............................................................... 107

www.sap-press.com 7

2 Sizing Methods

Sizing projects are carried out at very different stages of

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 meth-

ods 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 fol-

lowing:

“We are a large customer in the consumer goods indus-

try 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 gener-

ate any load during live operation. In contrast, the

sales orders and sales order items are much more

critical to CPU sizing since they represent transac-

tion 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.

“We can’t fi nd any guidelines for the FIN-FSCM-TRN

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

�

�

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

ments. How should we carry out a sizing project?”

This question refers to a specifi c component in

accounting and is therefore more detailed. Perhaps

this customer has already carried out sizing projects

for other SAP applications and wants to perform

another one for this particular application. In addi-

tion, 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 single-

instance concepts, which are used to check whether

all systems can be globally integrated with one data-

base, 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 ulti-

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

form sizing projects (see Table 2.1). The 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

SAP project.

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

and you — as a customer — are not yet very familiar with

�

�


2 Sizing Methods

the software, you will probably have only basic informa-

tion 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 installation’s complexity differs too much from

the standard, you can, for instance, measure customer

processes in order to create customer-specifi c sizings.

All these different phases require different sizing meth-

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

tial and production sizings . Figure 2.1 provides an over-

view of the available sizing methods, with initial sizings

being shown in the upper section and production siz-

ings 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

time, customer-specifi c data can be analyzed.

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-

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 company’s production system

— at least the sizing for SAP SRM will be considered as

being initial.

Depending on the project phases, we differentiate ini-

tial 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 addi-

tional rules or measurements.

Hardware Budget Sizings

The main characteristic of budget sizings is that they

don’t 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-

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)


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

Upgrade phase (Phase F)


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

www.sap-press.com 9

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

you don’t know the other applications they will use and

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

form 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 SAP’s 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-

tage is that the rough categorization into S through XL

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.

Hardware Budget Sizing Advanced Sizing Expert Sizing

Smaller Companies

� Very simple algorithms

� Assumptions, likelihoods

� Level setting of project

� Risk identification

Medium to Large Companies

� Throughput estimates

� Questionnaires, formulas

� Usage of standard tools

� Focus on core businessprocesses

Large/Complex Projects

� Additional guidelines

� Custom calculations

� Analysis of custom coding

� Custom sizing guidelines

Resizing Delta Sizing Upgrade Sizing

All Projects All Projects

� SAP system monitors

� Goal: Extend an existing system by functions (by differentfunctions, e.g., you are live withCRM and want to add SCM)

All Projects


� SAP Notes

� Goal: Upgrade SAP software

Go-Live

Initial Sizings

Post GoLive Sizings


�

Goal: Extend an existing systemby load (e.g., by volume, 100additional users who will do thesame as the current productiveones)

Figure 2.1 Overview of Sizing Approaches and Methods

Budget Sizings Help in Estimating the Entire Size

Let’s suppose a budget sizing determines 4,000 SAPS

(SAP Application Performance Standard1). 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 siz-

ing 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 dur-

ing 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 hard-

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

afford to use the wrong assumptions. Let’s sup-

pose your initial estimate is wrong by 100%. You

�

�


1

1 See Section 9.2, SAP Application Performance Standard, for a more detailed description of SAPS.


2 Sizing Methods

Advanced Sizing

If you’re in a situation in which there’s a high risk of mis-

judging 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 you’re dealing with is between 8 and 16 cores, a

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

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

additional functions of Quick Sizer, such as its through-

put-based functionality, which allows you to determine

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

tion 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 infor-

mation about the business software applications is avail-

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

a PC vendor’s decision about which important materi-

als are imperative that an availability check be performed

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

an object and can become a performance bottleneck

because all other requests have to wait until the object is

released again.

Thus, in an advanced sizing process, you focus more

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

the key processes of the SAP Business Suite and tries to

break down the complex business scenarios into the most

important transactions and objects. In addition, Quick

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

that it distinguishes between the average CPU utilization

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

ing):

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

�

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 Year’s). 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 cat-

egory 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 rec-

ommends 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 busi-

ness transactions, in-house developments, and large-

scale 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 can-

didates 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:

�

would then have to pay (in the above example)

an additional $15,000 – $20,000 for a correspond-

ingly 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.

www.sap-press.com 11

Identifi ed all processes that are critical for perfor-

mance.

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 previ-

ously 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 subdivide these two parts into:

The full utilization of the sizing tools’ functionality (in

particular, Quick Sizer’s) 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 overlap-

ping, 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,

have been caused by custom coding .

�

�

�

�

�

Simplifi ed Example of Expert Sizing

A company uses SAP CRM applications to enter sales

orders and uses SAP ERP for sales order fulfi llment 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

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

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 inter-

face does not negatively affect the performance

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

a positive effect because there is no user interac-

tion). 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 pro-

cessing will be, it performs performance measure-

ments that show that, because of the extension

made in the customer system, the same process

that was mapped in Quick Sizer now needs more

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.

�

�

�

�

�

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 inher-

ent customer-specifi c nature include the following:



2 Sizing Methods

Variant confi guration that evaluates complex object

dependencies: Its runtime can hardly be anticipated

in the standard, if at all.

Each custom extension.

To analyze customer data, the following two methods are

available: single-user analysis and the load test .

Single-user Analysis

Single-user analysis is based on a relatively simple

principle: As soon as integration tests can be per-

formed (i.e., when business processes can be func-

tionally mapped in a system), you use the standard

performance monitors of the SAP system to mea-

sure the CPU time , memory consumption, or data-

base 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 customer-spe-

cifi c sizing rule. Chapter 6, Performance Monitors and

Traces, contains detailed information on sizing-based

performance measurements.

Step Description

1 Defi ne test case

2 Identify test system

3 Create test case in test system

4 Measure sizing KPIs

5 Implement measurement results in sizing method

6 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 about

the locking procedure or memory requirements.

In the sizing environment, load tests have a hybrid

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

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

verify sizing results. Because customers usually use

them to verify sizing results, you can fi nd detailed

information on them in Section 7.1, Load Tests.

�

�

�

�

Sizing Measurement Versus Performance Analysis

Note that sizing measurements refl ect only the actual

status. Based on sizing measurements, you can deter-

mine whether a business transaction is scalable. In

this context, scalability means that the resource con-

sumption 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 perfor-

mance subproject.

The advantages of expert sizing over other sizing meth-

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

ability 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 col-

lection 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 exam-

ples will show:

You want to consolidate your existing system land-

scape (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 sys-

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

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

tions 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

�

�

�

�


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 pro-

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

cesses, and settings into account. Quick Sizer has been

designed for new installations and contains assump-

tions 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 uti-

lization of the sizing-relevant components in the exist-

ing 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 regard-

ing 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?

Once you have determined the current utilization or the

database growth and the increasing memory require-

ments using the various vendor-specifi c monitors or the

SAP monitors, you should relate this information to a

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

�

�

�

�

�

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.

Sample Analysis of a Production System

The following example forms the basis for the descrip-

tion of individual sizing methods. A customer uses

strategic procurement in the SRM environment. The

analysis of the current utilization provides the follow-

ing 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 ana-

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

mine whether the existing hardware is suffi cient or

whether it must be extended.

�

�

�

Resizing

A basic prerequisite for resizing is that only the through-

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

ality. Based on the current load situation and the new

information, you can easily determine future require-

ments using a rule of three.

Typical resizings occur in system consolidations or in

what is referred to as phased rollouts, in which customers

install new software in different phases in their business

units or international subsidiaries.

Resizing a Production System

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

ple Analysis of a Production System), a resizing 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

2.3 Sizings Based on Productive Customer Data


2 Sizing Methods

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 sizing results are applied to the

current utilization.

However, there is one special characteristic you should

be aware of: The SAP’s standard sizing rules specify the

CPU requirements in terms of SAPS and a target utili-

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

SAP Application Performance Standard, each hardware

confi guration in the SAP environment has its own SAPS

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 Pro-

duction System) has created a sizing for a new appli-

cation. According to the sizing, the application will

require 1,200 SAPS (240 database SAPS and 960 appli-

cation SAPS). What needs to be done now is easy: The

SAPS values must be added up, and the target utiliza-

tion must be determined.

The existing hardware is evaluated as follows:

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

tions: 2,800 SAPS each

The current net SAPS consumption for the data-

base 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 utiliza-

tion 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.

�

�

�

�

among the new users and that they will do the same

as the existing users, so that we can make the follow-

ing calculations:

Active Users

The ratio between 200 and 1,567 is 12%, which

means that the number of active users will prob-

ably increase by 12%.

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 applica-

tion 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.

�

�

�

�

�


Upgrade Sizing

In upgrade projects, customers usually implement numer-

ous changes, which include the SAP software, database,

operating system, and an exchange of hardware. It often

happens that the confi guration and parameter settings are

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

ber 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 require-

ments, memory requirements, and database space.

Because these SAP Notes provide standardized infor-

mation 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 Trans-

action G consumes an additional 30%. The CPU and

database consumptions remain unchanged.

If you — as the customer — now use Transaction G

extensively, this could cause problems when calculat-

ing the main memory. The best thing to do is to calcu-

late 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.

�

�

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.

Single-Instance Projects

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

instance projects in which companies change from a best-

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

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

of resizing and delta sizing, sometimes also upgrade siz-

ing. 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

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 rel-

evant 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 cur-

rent consumptions of existing SAP systems must

be analyzed and totaled.

Finally, a delta sizing must be performed for the

legacy software. Ultimately, the additional require-

ments for the new software are added to the exist-

ing load.

�

�

�

2.4 Summary

Because SAP software shows a high degree of scalabil-

ity, you can consider a linear change in consumption as

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

to extend the processing power of application servers,

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

CPUs, depending on your specifi c production model.

However, a new application server affects the data-

base’s memory requirements because it involves the

addition of new database users. A higher volume gener-

ally 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 prod-uct from the best vendor for each (technological) area. The different products are then connected with each other via interfaces.

2.4 Summary


2 Sizing Methods

The sizing method used essentially depends on the initial

position you’re 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 (Chap-

ter 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

3-tier implementation 47

80/20 rule 35

AA/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

Application server 14, 19, 46, 55

Application team 73

Archiving object 45

Average CPU sizing 49

Average load 48

BBaseline test 62

Benchmark result 30, 36

BI Accelerator � Business Intelligence

Accelerator

Blank installation 46, 47

Blueprint phase 8

Business Intelligence Accelerator (BI

Accelerator) 18

CCache 27

CCMS � Computing Center Management

System (CCMS)

Chief Information Officer (CIO) 4, 74

Chief Process Innovation Officer (CPIO) 4

Coding

custom 11, 59, 62

Computing Center Management System

(CCMS) 51, 65, 68

Concurrent user 21

Consolidation phase 8

Core 18

Core process

business 10, 65, 75

Core team 73

CPU 3, 15, 18, 66

CPU load 24

CPU time 3, 12, 23, 30, 57

CPU utilization 13

Custom development 8

Customer data

analyzing 11

Customer reference installation 23

Customizing 13, 17, 65

DDatabase 18, 39, 53

Database monitor 53

Database server 13

Database space 13, 39

Data Dictionary 58

Delta sizing 13, 14

Disclaimer 42

Disk growth 53

Disk I/O operations 19, 39

Disk space

database 14, 39, 47

DPU � Logical Deployment Unit (DPU)

Dual-stack installation 26

EEmployee Self-Services 75

Evaluation phase 74

EWC � SAP EarlyWatch Check (EWC)

Expert sizing 10, 29, 51, 76

Expressiveness

of sizing project 7

Extension phase 8

FFrontend network 19, 21, 57

GGarbage in, garbage out 32, 76

GLC � SAP GoingLive Check (GLC)

GoLive 8

HHardware budget planning 4, 71

Hardware budget sizing 8

Hardware costs 4, 71

Hardware vendor 35, 42, 71

high-volume load tests 24

II/O (input/output)

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 Accounting Standard (IAS)

33

IT team 73

JJava-based

application 25, 47

Java Virtual Machine (JVM) 57


Index

KKey performance indicator 12, 17, 31

LLandscaping 6, 72, 78

Latency 19

liveCache 18

Load test 12, 59

analysis 60

multi-user mode 61

performing 61

planning 59

toolkit 24

tools 60

Local area network (LAN) 17, 73

Logged-on user 21

Logical Deployment Unit (DPU) 46

MMaster data sizing 22, 26

Maximum Extended Memory in Transac-

tion 57

Memory consumption 13

Memory requirement 40, 52, 56, 57

Methods 7

Minimum requirement 5

NNamed user 20

Network load 19

Network traffic 32

Non-disclosure policy 23

OOffline questionnaire 33

Online Analytical Processing 29

Operating system monitor 52

Orientation phase 8

PPAM � Product Availability Matrix (PAM)

Peak load 48, 49

Peak sizing 49

Performance analysis (ST30) 12

Performance monitor 51

Performance trace (ST05) 51, 57

Phased rollout 13

Phases

of sizing projects 7

Physical memory 18

Processor 18

Product availability 5

Product Availability Matrix (PAM) 5, 18

Production sizing 8, 12, 53, 67

Programming guidelines 30

Project team 73

QQuick Sizer 35

average CPU sizing 37

CPU peak sizing 45, 48

design principles 35

documentation 36, 41, 42

functions 36, 40

navigation 41

peak CPU sizing 37

project 36, 41, 47

questionnaires 37, 41, 47

result 38

Save function 41

sizing element 38, 44, 47, 48

RReference database 23

reference installations 23

Residence time 19, 27

Resizing 12, 13, 63

Resource consumption 15, 24

Rule of thumb 29

SSAP Application Performance Standard

(SAPS) 10, 38, 40, 50

SAP EarlyWatch Check (EWC) 67

SAP GoingLive Check (GLC) 63

SAP GoingLive Functional Upgrade Check

15, 63, 68

SAP NetWeaver

Business Intelligence 21, 40, 58

Portal 21, 44

Process Integration 4

SAPS 40

SAP Solution Manager 64

SAP Standard Application Benchmarks

23

Scalability 3, 61

Sessions 21

Single-instance project 15

Single-user analysis 12

Single record statistics (STAD) 56

Sizing

approach 17

by throughput 22

by users 4, 20

definition 3

expressiveness 7

formula 32

informational value 31

initial 8

methods 7, 8, 11, 16, 27

measurement 12

object 45

principle 3

production 8, 51, 63

production sizing 13

result 40, 46

scope 20

throughput-based 38, 44

tool 11, 29, 51

user-based 20, 38

verification 59, 63

Sizing project 71

application team 73

core team 73

definition 72

documentation 74, 77

execution 71, 74

goal 74

IT team 73

planning 71

procedure 74

project scope 71

stakeholders 72

success factors 71

Software architecture 31

Status 42

System consolidation 13, 15

System GoLive 63, 67

System integration 65

TT-shirt sizing 9, 30

Target utilization 14, 50

Throughput-based CPU sizing 45

Throughput sizing 22, 23

Throughput sizing model 23

Throughput volume 7

Total cost of ownership (TCO) 4

Trace tool 51, 57

Transaction DB02 53


Index

Transaction ST05 57

Transaction ST06 52

Transaction ST07 54

Transaction STAD 56

UUpgrade phase 8

Upgrade sizing 13, 15, 63, 67, 75

Usage type 47

User

active 21

concurrent 21

interaction step 52, 57

logged-on 21

named 20

User-based sizing 20, 38

User interaction step 57

VVerification 77

of sizings 59, 63

WWide area network (WAN) 17, 73

Work days

in Quick Sizer 42

Documents

Sap Sizing Example