dsdsdsd by samuel Arismendi

Sizing SAP® Systems Susanne Janssen, Ulrich Marquard

Contents 1

Introduction

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

Basic Considerations and Assumptions

Sizing Deﬁnition ....................................

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

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

Advantages and Disadvantages

Business Management and Technology

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

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

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

Target Group and Structure of the

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

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

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

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

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

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

Calculating Memory Requirements .......

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

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

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

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

Sizing Methods

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

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

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

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

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

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

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

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

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

2.3 Sizings Based on Productive Customer Data ....

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

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

Basic Analysis for All Production Sizings ....................................................

Sizing Tools

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

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

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

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

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

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

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

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

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

4.4 Ofﬂine Questionnaire .......................................

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

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

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

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

3.1 Factors That Inﬂuence Sizing ............................

Sizing Approaches

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

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

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

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

3.3 Overview of Different Sizing

Quick Sizer

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

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

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

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

Advantages and Disadvantages of

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

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

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

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

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

www.sap-press.com

Contents

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

Step 5: Acquire Information and Apply

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

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

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

Step 6: Analyze First Results and Adapt

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

the Methods .......................................... 77 Step 7: Consolidate the Results and

Performance Monitors and Traces

......

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

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

Get Conﬁrmation from Stakeholders .... 77 8.4 Summary ...........................................................

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

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

9.1 Basic Foundations of the SAP Sizing

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

Sizing Details

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

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

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

SAP Software Architecture .................... 79 Application Services and Database

Sizing Veriﬁcation

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

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

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

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

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

Allocating Sufﬁcient Memory

Phase 1: Performing Individual

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

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

Allocating Sufﬁ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 .....................................................

Measuring Resource Consumption ....... 88

7.2 Veriﬁ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 ............

SAP GoingLive Functional Upgrade

9.3 Performing Sizing Measurements ..................... 94 Step 1: Deﬁne the Test Case ................. 94

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

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

Step 3: Create the Test Case in the

Executing Sizing Projects

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

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

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

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

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

Step 5: Create Sizing Guidelines Based

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

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

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

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

Deﬁnition of a Sizing Project ................. 72 8.2 Project Team ...................................................... 73 8.3 Methodical Procedure ......................................

Step 1: Deﬁne Project Contents and Goals ......................................................

Step 2: Determine Performance-Critical Processes ................................................

10 Summary and Outlook

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

Frequently Asked Questions

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

A.1 Sizing Approaches ............................................. 103 A.2 Quick Sizer ........................................................ 104

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

Step 3: Decide on the Approaches and Methods to Be Used ..............................

Literature and Links

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

Step 4: Deﬁne Milestones and Prepare a Detailed Schedule ...............................

Index

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

2 Sizing Methods

Sizing projects are carried out at very different stages of

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

an SAP project. They represent an iterative process that

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

depends closely on the amount of information that is

This question refers to a speciﬁc component in

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

accounting and is therefore more detailed. Perhaps

statements on the actual hardware requirements.

this customer has already carried out sizing projects

Accordingly, in each sizing project, you will often face

for other SAP applications and wants to perform

new situations that you must react to with different meth-

another one for this particular application. In addi-

ods and, consequently, using different tools. This chapter

tion, the customer wants to know how sizing can be

focuses on these different methods.

done for proprietary developments. 왘

2.1

“We are planning to consolidate our seven data centers into one. Can we simply add up existing sizings?”

Phases of Sizing Projects

This question (which comes from an existing SAP

SAP regularly receives information requests like the fol-

customer) refers to a system consolidation process

lowing:

in which additional hardware requirements must be

왘

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

taken into account if the different existing systems

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

are combined. System consolidation and single-

orders containing 50 line items per month. How much

instance concepts, which are used to check whether

hardware do we need for our SAP application?”

all systems can be globally integrated with one data-

This is a rather general question. The customer needs information about hardware for a ﬁrst estimate. The

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

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

question itself does not indicate why this is a large

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

customer. Perhaps the customer is only looking for a

factors?”

partial solution since the volumes mentioned indicate

This customer uses a speciﬁc release that he wants

that this customer is a large medium-sized company.

to upgrade across multiple releases in one step and

The business partners represent master data and are

therefore wants to know if new hardware needs to be

not yet relevant to sizing because they do not gener-

purchased for that.

ate any load during live operation. In contrast, the

왘

sales orders and sales order items are much more

By further analyzing these kinds of requests, we ulti-

critical to CPU sizing since they represent transac-

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

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

form sizing projects (see Table 2.1). The informational

sales orders per day is quite considerable; however,

value of the sizing project can vary, depending on the

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

different phases. In addition, you should note that not

throughput volume. SAP has several customers who

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

process more than a million sales order items per day.

SAP project.

“We can’t ﬁnd any guidelines for the FIN-FSCM-TRN component in your sizing area (http://service.sap.com/

Thus, if the system GoLive is still way down the road and you — as a customer — are not yet very familiar with

www.sap-press.com

2 Sizing Methods

Phase

Point in Time

Description

Orientation phase (Phase A)

18 to 12 months prior to GoLive

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

Blueprint phase (Phase B)

12 to 6 months prior to GoLive

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

Implementation phase (Phase C)

6 to 0 months prior to GoLive

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

Consolidation phase (Phase D)

System is operational

The system is operational and is supposed to be consolidated. Region 1, for instance, has gone live with a speciﬁ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

the software, you will probably have only basic informa-

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

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

in phase E, and upgrade sizings in phase F.

least make a rough estimate of the costs involved. During the course of the implementation project, you can reﬁne your initial assumptions by using standard sizing rules in order to take a closer look at the critical issues.

2.2 Methods for Initial Sizings Initial sizings are sizings that refer to new installations,

If an installation’s complexity differs too much from

that is, installations in which you use SAP software for

the standard, you can, for instance, measure customer

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

processes in order to create customer-speciﬁc sizings.

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

All these different phases require different sizing meth-

is already running in your company’s production system

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

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

tial and production sizings. Figure 2.1 provides an over-

being initial.

view of the available sizing methods, with initial sizings

Depending on the project phases, we differentiate ini-

being shown in the upper section and production siz-

tial sizings into hardware budget sizings (budget sizings

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

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

because under certain circumstances, some processes can

budget sizings and advanced sizings are based on tools,

be mapped using standard methods while, at the same

whereas expert sizings are a mixture of tools and addi-

time, customer-speciﬁc data can be analyzed.

tional rules or measurements.

The following sections describe the characteristics of these different sizings in greater detail. At this point it is

Hardware Budget Sizings

important to know that sizings can be performed within

The main characteristic of budget sizings is that they

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

don’t require much information from the customer and

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

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

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

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

2.2 Methods for Initial Sizings

Hardware Budget Sizing Smaller Companies

Advanced Sizing

Expert Sizing

GoLive

Large/Complex Projects

Medium to Large Companies

Very simple algorithms

Throughput estimates

Additional guidelines

Assumptions, likelihoods

Questionnaires, formulas

Custom calculations

Level setting of project

Usage of standard tools

Analysis of custom coding

Risk identification

Focus on core business processes

Custom sizing guidelines

Initial Sizings

Resizing

Delta Sizing

Upgrade Sizing

All Projects

SAP system monitors

Goal: Extend an existing system by load (e.g., by volume, 100 additional users who will do the same as the current productive ones)

Goal: Extend an existing system by functions (by different functions, e.g., you are live with CRM and want to add SCM)

SAP Notes

Goal: Upgrade SAP software

Post GoLive Sizings Figure 2.1 Overview of Sizing Approaches and Methods 1

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

Budget Sizings Help in Estimating the Entire Size

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

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

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

(SAP Application Performance Standard1). Currently,

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

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

value provided by the result of the sizing process will be

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

too restricted.

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

For this reason, budget sizings are usually performed

whether it makes sense to tackle a rather intensive siz-

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

ing process or whether you want to take one of the

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

following two risks:

of hardware.

왘

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

Result Is Too High This means the server will not be fully utilized dur-

function in SAP’s Quick Sizer (see Chapter 5, Quick Sizer).

ing live operations. A result that is too high often

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

occurs because the initial estimates are usually too

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

conservative.

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

왘

Result Is Too Low

tage is that the rough categorization into S through XL

This means that you must buy additional hard-

provides only limited informational value. Occasionally,

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

such sizings can be sufﬁcient, depending on the speciﬁc

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

situation.

pose your initial estimate is wrong by 100%. You

For this reason, it makes a lot of sense to compare the time and effort you want to invest into a sizing project with the potential hardware costs.

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

www.sap-press.com

2 Sizing Methods

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

would then have to pay (in the above example)

load, you can, of course, specify them.

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

왘

Throughput-based sizing enables you to determine in greater detail in which areas and at what time the CPU peak load occurs (for example, in the week before Christmas or New 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

Advanced Sizing

of by user-based sizing.

If you’re in a situation in which there’s a high risk of misjudging the requirements by several 100 percents, you

The drawback of advanced sizing is that you have to

should reﬁne your budget sizing by using what is referred

familiarize yourself with the core business processes in

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

order to obtain the appropriate information from the

power you’re dealing with is between 8 and 16 cores, a

user departments for the Quick Sizer questionnaire. This

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

certainly takes more time than asking for the number of

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

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

additional functions of Quick Sizer, such as its through-

but it is much more accurate.

put-based functionality, which allows you to determine

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

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

An “XL” category in Quick Sizer represents a large cat-

tion 5.3, Average and Peak Sizing).

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

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

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

these phases, the ﬁrst business blueprints have already

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

been created so that important and sizing-relevant infor-

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

mation about the business software applications is avail-

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

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

SAPS and higher.

a PC vendor’s decision about which important materials are imperative that an availability check be performed

Expert Sizing

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

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

an object and can become a performance bottleneck

ommends that its customers not rely exclusively on one

because all other requests have to wait until the object is

sizing tool but rather that they analyze the core processes

released again.

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

Thus, in an advanced sizing process, you focus more

expert sizing.

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

This method is particularly suited for complex busi-

the key processes of the SAP Business Suite and tries to

ness transactions, in-house developments, and large-

break down the complex business scenarios into the most

scale installations. Complex business transactions may

important transactions and objects. In addition, Quick

also occur in smaller installations, such as in the supply

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

chain or in retailing systems. Global installations, which

that it distinguishes between the average CPU utilization

are not only deﬁned by their size, are also eligible can-

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

didates for expert sizing because of the time differences

ing):

that must be taken into account.

왘

For processor requirements, you can perform an average sizing in such a way that you specify the number of objects that are processed per year as well

To be able to perform an expert sizing process, you must have:

2.2 Methods for Initial Sizings

왘

Identiﬁ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.

Simpliﬁed Example of Expert Sizing A company uses SAP CRM applications to enter sales orders and uses SAP ERP for sales order fulﬁ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

Expert sizings are performed just before the system GoLive, that is, when the functionality has been clearly deﬁ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.

sizing in such a way that core processes are mapped through the standard as much as possible, while the other processes are approached step by step: 왘

standard sizing for sales order entry in SAP CRM. 왘

ERP system, a certain amount of extra capacity is

mixture of standard sizing and performance tools, and on

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

the other, of additional procedures and analyses. We can 왘

The full utilization of the sizing tools’ functionality (in

according to the corresponding sizing rules. 왘

that the orders are transferred through an inter-

requirements at least in part.

face does not negatively affect the performance

The analysis and performance monitoring of core

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

processes in the customer system.

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

The following sections provide an overview of how you can use standard tools in expert sizing to obtain useful information, at least about parts of your system.

the ERP sizing. 왘

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

Whenever you have identiﬁed business transactions as

made in the customer system, the same process

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

that was mapped in Quick Sizer now needs more

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

Because the company does not know up front what the impact of extending the sales order pro-

Standard Tools — Even for Experts

sizings.

The sizing of SAP ERP is mapped in Quick Sizer on the basis of the total number of orders. The fact

particular, Quick Sizer’s) so that they meet speciﬁc 왘

Because the sales orders that have been entered in the CRM system are further processed in the

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

roughly subdivide these two parts into:

First the company uses Quick Sizer to create a

resources. 왘

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

whether it is possible to perform moves (see also Section 5.3, Average and Peak Sizing). Quick Sizer enables you to

Analyzing Customer Data

map and document additional loads which, for example,

One of the most important tasks of expert sizing consists

have been caused by custom coding.

of analyzing specific customer processes. Typical cases in which it makes sense to analyze the performance figures on the basis of custom data because of the strong inherent customer-specific nature include the following:

www.sap-press.com

2 Sizing Methods

Variant conﬁguration that evaluates complex object

왘

Sizing Measurement Versus Performance Analysis

dependencies: Its runtime can hardly be anticipated

Note that sizing measurements reﬂect only the actual

in the standard, if at all.

status. Based on sizing measurements, you can deter-

Each custom extension.

왘

mine whether a business transaction is scalable. In this context, scalability means that the resource con-

To analyze customer data, the following two methods are

sumption increases linearly with the number or size

available: single-user analysis and the load test.

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

Single-user Analysis

왘

you must analyze and resolve the problem in a perfor-

Single-user analysis is based on a relatively simple

mance subproject.

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

The advantages of expert sizing over other sizing meth-

performance monitors of the SAP system to mea-

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

sure the CPU time, memory consumption, or data-

ability of the information. If you manage a sizing project

base growth on your hard disk, depending on your

for a complex or large customer, you should deﬁnitely

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

consider aspects from expert sizing, even though the col-

three to create the sizing forecast.

lection and analysis of the information takes more time.

Table 2.2 provides an overview of the procedure to be applied in a single-user analysis, from deﬁning an appropriate test case to applying the customer-speciﬁc sizing rule. Chapter 6, Performance Monitors and

2.3 Sizings Based on Productive Customer Data

Traces, contains detailed information on sizing-based

Sizing is an iterative process — that is, even operational

performance measurements.

installations can be subject to change processes that affect the resource requirements, as the following exam-

Step

Description

Deﬁne test case

Identify test system

Create test case in test system

Measure sizing KPIs

Implement measurement results in sizing method

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

Apply sizing rule

server that already hosts an ERP system).

Table 2.2 Steps in Creating a Sizing Rule 왘

ples will show: 왘

scape (for example, by merging all your international subsidiaries on one server). 왘

왘

You want to add additional functions to an existing

You want to upgrade Release X to Release Y.

Load Test

All these situations can affect the hardware and require

Load tests are occasionally used in the context of

a more or less comprehensive sizing project. The major

expert sizings and make sense when a single-user

advantage of sizings that are based on a production sys-

analysis does not provide sufﬁcient information about

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

the locking procedure or memory requirements.

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

In the sizing environment, load tests have a hybrid

tions made by SAP.

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

Regarding production sizings, we distinguish between

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

the following three methods, which pursue different

verify sizing results. Because customers usually use

goals:

them to verify sizing results, you can ﬁnd detailed

왘

information on them in Section 7.1, Load Tests.

You want to consolidate your existing system land-

Resizing In a resizing project, the throughput or user volume

2.3 Sizings Based on Productive Customer Data

왘

changes, but not the processes (or customizing or

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

parameter settings, and so on).

use the number of activities or sales orders, depending,

Delta Sizing

on the one hand, on which unit is best suited to reﬂect

In a delta sizing project, you add new functionality.

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

Upgrade Sizing

how easily it can be determined.

An upgrade sizing involves a change of the SAP release.

Sample Analysis of a Production System The following example forms the basis for the descrip-

Common to all these sizing methods is that you must ﬁrst

tion of individual sizing methods. A customer uses

analyze the status of the existing system before you can

strategic procurement in the SRM environment. The

plan the new hardware requirements.

analysis of the current utilization provides the following result:

Production System Sizings Versus Quick Sizer

왘

CPU

The unbeatable advantage of sizing on the basis of pro-

Utilization of the database server is 34%; that of

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

the two application servers is 56%.

cesses, and settings into account. Quick Sizer has been

왘

designed for new installations and contains assump-

213GB out of 512GB are occupied with a monthly

tions about the productive operation. For this reason, we recommend Quick Sizer for initial sizings only.

Database growth of 7GB.

왘

Memory 26GB out of 32GB are being consumed.

Basic Analysis for All Production Sizings

By using a system monitor, the customer has found

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

out that approximately 1,254 named users out of a

lization of the sizing-relevant components in the exist-

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

ing system. Using the appropriate monitors, which are

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

described in detail in Chapter 6, you can determine the

mine whether the existing hardware is sufﬁcient or

following information:

whether it must be extended.

왘

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

Resizing

existing hardware compensate for the future load?

A basic prerequisite for resizing is that only the through-

Here, you must distinguish between the utilization of

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

the application server and that in the database.

ality. Based on the current load situation and the new

Memory Consumption

information, you can easily determine future require-

How much room for maneuver do you have regard-

ments using a rule of three.

ing the memory requirement: Will it increase or stay 왘

Typical resizings occur in system consolidations or in

the same?

what is referred to as phased rollouts, in which customers

Database Space

install new software in different phases in their business

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

units or international subsidiaries.

make a note: How quickly did they grow during the last several months?

Resizing a Production System Based on the above example (see previous box, Sam-

Once you have determined the current utilization or the

ple Analysis of a Production System), a resizing could

database growth and the increasing memory require-

look as follows: You want to add another 200 named

ments using the various vendor-speciﬁc monitors or the

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

SAP monitors, you should relate this information to a

ratio between named users and active users is identical

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

www.sap-press.com

2 Sizing Methods

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

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

왘

CPU Database Server 34% + 12% corresponds to 34% × 1.12 = 38.1% A utilization of 38% is sufﬁ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

value, which can be speciﬁ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 sufﬁ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: 왘

tions: 2,800 SAPS each 왘

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

Main Memory

5,600 SAPS)

26GB (out of 32): 26GB × 1.12 ~= 29GB 29GB out of 32GB of allocated memory might be a bit tight. It is therefore advisable to extend the memory. 왘

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

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

Currently, 312GB out of 512GB are being used. If the database grows by 96GB (8GB × 12 months) per year, bottlenecks can occur in a very short time. Thus, the disk space should be extended.

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

conceivable here. 왘

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

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

Delta Sizing

well, and the 65% factor could be a useful buffer. But if you want to base your calculations on net

Because delta sizing can be performed only when new functions are added to an existing software application,

amounts, you can do so as follows:

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

왘

The net requirement of the new application is 780

difference being that the sizing results are applied to the

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

current utilization.

SAPS out of the 780 SAPS are allocated to the database, 620 SAPS to the application level.

However, there is one special characteristic you should be aware of: The SAP’s standard sizing rules specify the

왘

Consequently, this means that we can expect a

CPU requirements in terms of SAPS and a target utili-

growth of approximately 10% for the database

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

and approximately 20% on the application side.

SAP Application Performance Standard, each hardware conﬁguration in the SAP environment has its own SAPS

2.4 Summary

Upgrade Sizing

Single-Instance Projects

In upgrade projects, customers usually implement numer-

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

ous changes, which include the SAP software, database,

instance projects in which companies change from a best-

operating system, and an exchange of hardware. It often

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

happens that the conﬁguration and parameter settings are

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

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

of resizing and delta sizing, sometimes also upgrade siz-

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

ing. Note that an upgrade sizing must be performed ﬁrst

Upgrade sizing refers to the additional requirements

to make sure that identical conditions apply.

of SAP software. SAP uses regression tests to check the resource consumption of the most important transactions

Considerations in the Context of a

and to create a delta. This information is made available

Single-Instance Study

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

A customer uses several SAP and legacy systems in

which describes the resource consumption between

Europe. This customer now wants to consolidate its

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

European and American systems. Consequently, this

6.0. The SAP Notes provide information about the delta

means the following:

regarding the number of database calls, CPU require-

왘

If the SAP software has different release versions, an upgrade sizing must be performed ﬁrst. The rel-

ments, memory requirements, and database space.

evant factors will be upgraded so that all systems

Because these SAP Notes provide standardized infor-

have the same version.

mation about different transactions, they carry the risk of 왘

you currently using a transaction that is counterbalanced

The next step involves resizing the SAP software based on the same release version; that is, the cur-

by other transactions.

rent consumptions of existing SAP systems must Sample Upgrade Sizing

be analyzed and totaled.

A (ﬁctitious) SAP Note on delta resource consumption

왘

Finally, a delta sizing must be performed for the

states that the resource consumption in the memory

legacy software. Ultimately, the additional require-

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

ments for the new software are added to the exist-

not show any additional consumption, whereas Trans-

ing load.

action G consumes an additional 30%. The CPU and database consumptions remain unchanged. If you — as the customer — now use Transaction G

2.4 Summary

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

Because SAP software shows a high degree of scalabil-

late a best case and a worst case.

ity, you can consider a linear change in consumption as

왘

Memory (Best Case)

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

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

to extend the processing power of application servers,

Memory (Worst Case)

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

26GB × 30% = 33.8GB

CPUs, depending on your speciﬁc production model.

Probably, the future memory requirement will be within that range.

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

Since this is a very complex subject, SAP provides the SAP GoingLive Functional Upgrade Check service as part of the standard service coverage (see also Section 7.2, Veriﬁcation via Support Services). The SAP GoingLive Functional Upgrade Check includes a sizing process.

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

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

www.sap-press.com

2 Sizing Methods

The sizing method used essentially depends on the initial

certain limitations. These limitations primarily depend on

position youâ&#x20AC;&#x2122;re in. Basically, there are different methods

the way in which business processes and the associated

for an initial sizing, which can be mapped via standard

application software interact with each other. For this

tools, and for a production sizing, which uses production

reason, the following chapter, Sizing Approaches (Chap-

data as a basis for forecasting.

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

In this chapter, we have mentioned several times that although sizing tools are very useful, they are subject to

throughput-based sizings into algorithms, and discusses the pros and cons of different sizing approaches.

Index

2-tier implementation 47

Computing Center Management System

3-tier implementation 47 80/20 rule 35

(CCMS) 51, 65, 68 Concurrent user 21 Consolidation phase 8

Core 18

A/P (Average and Peak) 44 Active user 21 Advanced sizing 10 Analysis of customer data 11 of customer processes 11 performance monitor 51 transaction design 60 Application monitor (ST07) 54 Application profile 71

Core process business 10, 65, 75 Core team 73

Extension phase 8

F Frontend network 19, 21, 57

G Garbage in, garbage out 32, 76

CPU 3, 15, 18, 66

GLC 씮 SAP GoingLive Check (GLC)

CPU load 24

GoLive 8

CPU time 3, 12, 23, 30, 57 CPU utilization 13

Custom development 8

Hardware budget planning 4, 71

Customer data

Hardware budget sizing 8

analyzing 11

Hardware costs 4, 71

Customer reference installation 23

Hardware vendor 35, 42, 71

Customizing 13, 17, 65

high-volume load tests 24

Average CPU sizing 49

Average load 48

Database 18, 39, 53

I/O (input/output)

Application server 14, 19, 46, 55 Application team 73 Archiving object 45

Database monitor 53

Database server 13

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

Database space 13, 39 Data Dictionary 58

Implementation phase 8, 71, 76

Disk I/O operations 19, 39

Implementation project 27, 71, 74

Disk space

Initial sizing 8, 63, 75

database 14, 39, 47 DPU 씮 Logical Deployment Unit (DPU)

Chief Process Innovation Officer (CPIO) 4 Coding custom 11, 59, 62

3-tier 47

Disk growth 53

Cache 27

Chief Information Officer (CIO) 4, 74

2-tier 47

Disclaimer 42

C System (CCMS)

(IAS) Implementation

Delta sizing 13, 14

Dual-stack installation 26

CCMS 씮 Computing Center Management

per second 39 IAS 씮 International Accounting Standard

Input error 41, 43 International Accounting Standard (IAS) 33 IT team 73

Employee Self-Services 75

Evaluation phase 74

Java-based

EWC 씮 SAP EarlyWatch Check (EWC) Expert sizing 10, 29, 51, 76

application 25, 47 Java Virtual Machine (JVM) 57

Expressiveness of sizing project 7

www.sap-press.com

107

Index

K Key performance indicator 12, 17, 31

Physical memory 18

Single record statistics (STAD) 56

Processor 18

Sizing

Product availability 5

approach 17

Product Availability Matrix (PAM) 5, 18

by throughput 22

Production sizing 8, 12, 53, 67

by users 4, 20

Landscaping 6, 72, 78

Programming guidelines 30

definition 3

Latency 19

Project team 73

expressiveness 7

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

formula 32

informational value 31 initial 8

Quick Sizer 35

methods 7, 8, 11, 16, 27

average CPU sizing 37

performing 61

measurement 12

CPU peak sizing 45, 48

planning 59

object 45

design principles 35

toolkit 24

principle 3

documentation 36, 41, 42

tools 60

production 8, 51, 63

functions 36, 40

Local area network (LAN) 17, 73

production sizing 13

navigation 41

Logged-on user 21

result 40, 46

peak CPU sizing 37

Logical Deployment Unit (DPU) 46

scope 20

project 36, 41, 47

questionnaires 37, 41, 47

Master data sizing 22, 26

Save function 41

Maximum Extended Memory in Transac-

sizing element 38, 44, 47, 48

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

result 38

tion 57

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

application team 73

Reference database 23

definition 72

reference installations 23

documentation 74, 77

Residence time 19, 27

execution 71, 74

Resizing 12, 13, 63

goal 74

Resource consumption 15, 24

Named user 20

IT team 73

Rule of thumb 29

planning 71

procedure 74

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

core team 73

Network load 19 Network traffic 32 Non-disclosure policy 23

project scope 71 stakeholders 72

SAP Application Performance Standard

success factors 71

(SAPS) 10, 38, 40, 50 SAP EarlyWatch Check (EWC) 67

Software architecture 31

Offline questionnaire 33

SAP GoingLive Check (GLC) 63

Status 42

Online Analytical Processing 29

SAP GoingLive Functional Upgrade Check

System consolidation 13, 15

Operating system monitor 52 Orientation phase 8

15, 63, 68

System GoLive 63, 67

SAP NetWeaver

System integration 65

Business Intelligence 21, 40, 58 Portal 21, 44

PAM ě&#x201D;Ž Product Availability Matrix (PAM)

Process Integration 4

T-shirt sizing 9, 30

Peak load 48, 49

SAPS 40

Target utilization 14, 50

Peak sizing 49

SAP Solution Manager 64

Throughput-based CPU sizing 45

Performance analysis (ST30) 12

SAP Standard Application Benchmarks

Throughput sizing 22, 23

Performance monitor 51

Throughput sizing model 23

Performance trace (ST05) 51, 57

Scalability 3, 61

Throughput volume 7

Phased rollout 13

Sessions 21

Total cost of ownership (TCO) 4

Phases

Single-instance project 15

Trace tool 51, 57

Single-user analysis 12

Transaction DB02 53

of sizing projects 7

Index

Transaction ST05 57

active 21

Transaction ST06 52

concurrent 21

Transaction ST07 54

interaction step 52, 57

Transaction STAD 56

logged-on 21

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

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

Usage type 47

User

Verification 77

of sizings 59, 63

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

www.sap-press.com

109