Sizing SAP® Systems

Susanne Janssen, Ulrich Marquard

Contents

1 Introduction ................................................. 3 Basic Considerations and Assumptions

Sizing Definition .................................... 3 for Throughput Sizing ............................ 23
The Sizing Principle ................................ 3 Advantages and Disadvantages
Business Management and Technology 4 of Throughput Sizing ............................. 23
Goals of This Book ................................. 4 Sizing by Reference Installations ........... 23
Target Group and Structure of the Sizing by Load Tests ............................... 24
Book ....................................................... 5 Conclusion ............................................. 24
Related Topics ........................................ 5 3.4 User and Throughput Sizing Models ................. 24
Calculating CPU Requirements ............. 24
2 Sizing Methods ........................................... 7 Calculating Memory Requirements ....... 25
2.1 Phases of Sizing Projects ................................... 7 Calculating Disk Requirements .............. 26
2.2 Methods for Initial Sizings ................................ 8 Frontend Network Requirements ......... 27
Hardware Budget Sizings ....................... 8 Conclusion for These Approaches ......... 27
Advanced Sizing ..................................... 10 3.5 Conclusion ........................................................ 27
Expert Sizing .......................................... 10
Standard Tools — Even for Experts ....... 11 4 Sizing Tools ................................................... 29
Analyzing Customer Data ...................... 11 4.1 Rule of Thumb/Reality Check ........................... 29
2.3 Sizings Based on Productive Customer Data .... 12 Bottom-Up Method .............................. 30
Basic Analysis for All Production Top-Down Method ................................ 30
Sizings .................................................... 13 4.2 T-shirt Sizing ...................................................... 30
Resizing .................................................. 13 Categories .............................................. 31
Delta Sizing ............................................ 14 Pros and Cons ........................................ 31
Upgrade Sizing ....................................... 15 4.3 Sizing Formula ................................................... 32
Single-Instance Projects ......................... 15 4.4 Offline Questionnaire ....................................... 33
2.4 Summary ........................................................... 15 4.5 Summary ........................................................... 33

3 Sizing Approaches ..................................... 17 5 Quick Sizer ................................................... 35

3.1 Factors That Influence Sizing ............................ 17 5.1 Quick Sizer Projects .......................................... 36
3.2 Key Performance Indicators .............................. 18 Creating a Project .................................. 36
3.3 Overview of Different Sizing Filling Out Sizing Questionnaires .......... 37
Approaches ....................................................... 20 Determining the Sizing Result ............... 38
Sizing by Users ....................................... 20 5.2 Functions ........................................................... 40
Advantages and Disadvantages of Initial Page ............................................. 41
User-Based Sizing .................................. 21 Navigation Tree ...................................... 41
Sizing by Throughput ............................. 22 Header Bar ............................................. 41

www.sap-press.com 1
Contents
Questionnaires .......................................
Results Page ...........................................
5.3 Average and Peak Sizing .................................... 48
5.4 Summary ........................................................... 50
6 Performance Monitors and Traces ......
6.1 Operating System Monitor ...............................
6.2 Database Monitor .............................................
6.3 Application Monitor .......................................... 54
6.4 Single Record Statistics .................................... 56
6.5 Performance Trace .............................................
6.6 Summary ........................................................... 58
7 Sizing Verification ......................................
7.1 Load Tests ..........................................................
Phase 0: Preparation ..............................
Phase 1: Performing Individual
Measurements ....................................... 60
Phase 2: Analyzing the Transaction
Design in Single Mode .......................... 60
Phase 3: Load Tests in Multi-User
Mode .....................................................
7.2 Verification via Support Services ....................... 63
SAP GoingLive Check ............................ 63
SAP EarlyWatch Check .......................... 67
SAP GoingLive Functional Upgrade
Check ..................................................... 68
7.3 Summary ...........................................................
8 Executing Sizing Projects ........................
8.1 Before the Sizing Project Begins .......................
Chicken or the Egg? ...............................
Project Scope .........................................
Stakeholders in a Sizing Project ............. 72
Definition of a Sizing Project ................. 72
8.2 Project Team ...................................................... 73
8.3 Methodical Procedure ......................................
Step 1: Define Project Contents and
Goals ......................................................
Step 2: Determine Performance-Critical
Processes ................................................
Step 3: Decide on the Approaches and
Methods to Be Used ..............................
Step 4: Define Milestones and Prepare
a Detailed Schedule ...............................
2 © Galileo Press 2007. All rights reserved.
43 Step 5: Acquire Information and Apply
45 the Methods .......................................... 76
Step 6: Analyze First Results and Adapt
the Methods .......................................... 77
Step 7: Consolidate the Results and
51 Get Confirmation from Stakeholders .... 77
52 8.4 Summary ........................................................... 78
53
9 Sizing Details ............................................... 79
9.1 Basic Foundations of the SAP Sizing
57 Model ................................................................ 79
SAP Software Architecture .................... 79
Application Services and Database
59 Services .................................................. 80
59 Modeling CPU Consumption ................ 81
59 Allocating Sufficient Memory
(or: Modeling Physical Memory) ........... 84
Allocating Sufficient Disk I/O
Capabilities (or: Modeling Disk I/O
Requirements) ....................................... 86
Modeling Network Bandwidth .............. 86
61 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: Define the Test Case ................. 94
69 Step 2: Identify the Test System ............ 95
Step 3: Create the Test Case in the
71 Test System ............................................ 95
71 Step 4: Measure the Sizing KPIs ............ 96
71 Step 5: Create Sizing Guidelines Based
71 on the Measurements ........................... 98
9.4 Summary ........................................................... 99
10 Summary and Outlook ............................ 101
74
A Frequently Asked Questions ................. 103
74 A.1 Sizing Approaches ............................................. 103
A.2 Quick Sizer ........................................................ 104
75 A.3 Sizing Projects ................................................... 104
75 B Literature and Links .................................. 105
76 Index ............................................................... 107
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 first 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 find 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 specific 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 specific 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
www.sap-press.com 7
2 Sizing Methods

Phase Point in Time Description

Orientation phase 18 to 12 months You familiarize yourself with the software functionality and want to know what the range
(Phase A) prior to GoLive 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 specific releases.

Blueprint phase (Phase B) 12 to 6 months The first business blueprints have been created, and now you need reliable information on
prior to GoLive 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 6 to 0 months You have ordered the hardware or are just about to do so, and you want to be absolutely
(Phase C) prior to GoLive sure that sizing is correct. For example, you are able to measure core processes using the
performance monitors.

Consolidation phase System is The system is operational and is supposed to be consolidated. Region 1, for instance, has
(Phase D) operational gone live with a specific software, and Region 2 is now supposed to go live on the same
system.

Extension phase System is The system is operational and you want to add new functions. For example, your live sys-
(Phase E) operational tem runs the SAP ERP applications, and you want to add CRM applications now.

Upgrade phase System is The system is operational and you want to perform an upgrade. For example, the system
(Phase F) operational 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-
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 refine
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-specific 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-specific 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 first time. That is also the case if, for instance, you
want to use SAP SRM for the first 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-

8 © Galileo Press 2007. All rights reserved.

 2.2 Methods for Initial Sizings

Go-
Hardware Budget Sizing Advanced Sizing Expert Sizing Live

Smaller Companies Medium to Large Companies Large/Complex Projects

 Very simple algorithms
 Assumptions, likelihoods
 Level setting of project
 Risk identification
 Throughput estimates
 Questionnaires, formulas
 Usage of standard tools
 Focus on core business
processes
 Additional guidelines
 Custom calculations
 Analysis of custom coding
 Custom sizing guidelines

Initial Sizings

Resizing Delta Sizing Upgrade Sizing

All Projects All Projects All Projects

 SAP system monitors
 Goal: Extend an existing system
by load (e.g., by volume, 100
additional users who will do the
same as the current productive
ones)
 SAP system monitors
 Goal: Extend an existing system
by functions (by different
functions, e.g., you are live with
CRM and want to add SCM)
 SAP system monitors
 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
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 sufficient, depending on the specific
situation.
For this reason, it makes a lot of sense to compare the
time and effort you want to invest into a sizing project
with the potential hardware costs.
Budget Sizings Help in Estimating the Entire Size
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 See Section 9.2, SAP Application Performance Standard, for a
more detailed description of SAPS.

www.sap-press.com 9
2 Sizing Methods
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.
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 refine 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 first 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 fine-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
10 © Galileo Press 2007. All rights reserved.
as the size of these objects. If you have times of peak
load, you can, of course, specify them.
왘 Throughput-based sizing enables you to determine
in greater detail in which areas and at what time
the CPU peak load occurs (for example, in the week
before Christmas or New 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 defined 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:
 2.2 Methods for Initial Sizings

왘 Identified all processes that are critical for perfor-

Simplified Example of Expert Sizing
mance.
A company uses SAP CRM applications to enter sales
왘 Used standard tools for the core processes.
orders and uses SAP ERP for sales order fulfillment and
왘 Determined the performance-critical areas in which
HR. The sales order processing functions in the ERP
your processes deviate from the standard.
system have been custom-coded.
For this reason, a mixed approach is used in expert
Expert sizings are performed just before the system
sizing in such a way that core processes are mapped
GoLive, that is, when the functionality has been clearly
through the standard as much as possible, while the
defined and perhaps even been implemented. In most
other processes are approached step by step:
cases, expert sizing represents an iteration on a previ-
왘 First the company uses Quick Sizer to create a
ously performed budget or advanced sizing so that you
standard sizing for sales order entry in SAP CRM.
can use the data of these previous processes as a basis
왘 Because the sales orders that have been entered
and simplify it, if necessary.
in the CRM system are further processed in the
Basically, this method consists, on the one hand, of a
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
according to the corresponding sizing rules.
roughly subdivide these two parts into:
왘 The sizing of SAP ERP is mapped in Quick Sizer on
왘 The full utilization of the sizing tools’ functionality (in
the basis of the total number of orders. The fact
particular, Quick Sizer’s) so that they meet specific
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 interac-
tion). This sizing represents the basic structure of
The following sections provide an overview of how you
the ERP sizing.
can use standard tools in expert sizing to obtain useful
왘 Because the company does not know up front
information, at least about parts of your system.
what the impact of extending the sales order pro-
cessing will be, it performs performance measure-
Standard Tools — Even for Experts
ments that show that, because of the extension
Whenever you have identified 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
resources.
sizings.
왘 The customer is now able to increase the ERP
Another option for using Quick Sizer in expert sizing is
result for sales order processing by 30% in such
that you can use it for optimizing process flows from the
a way that the customer multiplies the Quick
point of view of sizing. For example, if you use overlap-
Sizer result by a factor of 1.3. Other results (for
ping, performance-critical process chains, you can use the
instance, in HR) are not affected by this.
24-hour load profile 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 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 inher-
ent customer-specific nature include the following:

www.sap-press.com 11
2 Sizing Methods
왘 Variant configuration 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 defining an
appropriate test case to applying the customer-spe-
cific sizing rule. Chapter 6, Performance Monitors and
Traces, contains detailed information on sizing-based
performance measurements.
Step Description
1 Define 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 sufficient 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 find detailed
information on them in Section 7.1, Load Tests.
12 © Galileo Press 2007. All rights reserved.
Sizing Measurement Versus Performance Analysis
Note that sizing measurements reflect 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 definitely
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 first
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 first 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-specific monitors or the
SAP monitors, you should relate this information to a
simple business key figure. Usually this is the users, but
2.3 Sizings Based on Productive Customer Data
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 reflect
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 sufficient 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
www.sap-press.com 13
2 Sizing Methods

value, which can be specified by the hardware vendors at

among the new users and that they will do the same
any time and for each release. Based on this information
as the existing users, so that we can make the follow-
(available SAPS, software release, CPU utilization, new
ing calculations:
SAPS), you can easily calculate whether the hardware will
왘 Active Users
be sufficient by using a rule of three.
The ratio between 200 and 1,567 is 12%, which
means that the number of active users will prob-
Delta Sizing of a Production System
ably increase by 12%.
The above customer (see previous box, Resizing a Pro-
왘 CPU Database Server
duction System) has created a sizing for a new appli-
34% + 12% corresponds to 34% × 1.12 = 38.1%
cation. According to the sizing, the application will
A utilization of 38% is sufficient for a database
require 1,200 SAPS (240 database SAPS and 960 appli-
server. Many customers plan a target utilization of
cation SAPS). What needs to be done now is easy: The
25% to 50% for the database server.
SAPS values must be added up, and the target utiliza-
왘 CPU Application Server
tion must be determined.
56% + 12% corresponds to 56% × 1.12 = 62.7%
The existing hardware is evaluated as follows:
The application servers can absorb a utilization of
왘 Database server: 4,000 SAPS; the two applica-
62.7% quite well. However, many customers plan
tions: 2,800 SAPS each
a target utilization of 30% to 50% for the applica-
왘 The current net SAPS consumption for the data-
tion servers, which is why an extension is at least
base is 1,360 SAPS (i.e., 34% of 4,000 SAPS) and
conceivable here.
3,700 SAPS at the application level (i.e., 66% of
왘 Main Memory
5,600 SAPS)
26GB (out of 32): 26GB × 1.12 ~= 29GB
For the database, this would mean the following: 1,360
29GB out of 32GB of allocated memory might be
SAPS + 240 SAPS = 1,600 SAPS — which represents a
a bit tight. It is therefore advisable to extend the
future utilization of 40%. The application servers reach
memory.
4,660 SAPS and a utilization of 83%, which could lead
왘 Database Space
the customer to the conclusion that it would make
7GB of growth corresponds to 7GB × 1.12 = 8GB per
sense to add another application server.
month
If you have followed the above descriptions of tools
Currently, 312GB out of 512GB are being used. If
and methods closely, you will have noticed that SAP
the database grows by 96GB (8GB × 12 months)
calculates the standard sizings with a target utiliza-
per year, bottlenecks can occur in a very short
tion of 65% and you should therefore only use net
time. Thus, the disk space should be extended.
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.
Because delta sizing can be performed only when new But if you want to base your calculations on net
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
However, there is one special characteristic you should database, 620 SAPS to the application level.
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
configuration in the SAP environment has its own SAPS

14 © Galileo Press 2007. All rights reserved.


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 configuration 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 (fictitious) 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, Verification
via Support Services). The SAP GoingLive Functional Upgrade
Check includes a sizing process.
2.4 Summary
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 first
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 first. 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 specific 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.
www.sap-press.com 15
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
16 © Galileo Press 2007. All rights reserved.
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 Computing Center Management System Extension phase 8

3-tier implementation 47 (CCMS) 51, 65, 68
80/20 rule 35 Concurrent user 21 F
Consolidation phase 8
Frontend network 19, 21, 57
A Core 18

A/P (Average and Peak) 44

Core process
G
business 10, 65, 75
Active user 21
Core team 73 Garbage in, garbage out 32, 76
Advanced sizing 10
CPU 3, 15, 18, 66 GLC 씮 SAP GoingLive Check (GLC)
Analysis
CPU load 24 GoLive 8
of customer data 11
CPU time 3, 12, 23, 30, 57
of customer processes 11
CPU utilization 13 H
performance monitor 51
Custom development 8 Hardware budget planning 4, 71
transaction design 60
Customer data Hardware budget sizing 8
Application monitor (ST07) 54
analyzing 11 Hardware costs 4, 71
Application profile 71
Customer reference installation 23 Hardware vendor 35, 42, 71
Application server 14, 19, 46, 55
Customizing 13, 17, 65 high-volume load tests 24
Application team 73
Archiving object 45
Average CPU sizing 49
D I
Average load 48 Database 18, 39, 53 I/O (input/output)
Database monitor 53 per second 39
B Database server 13 IAS 씮 International Accounting Standard
Database space 13, 39 (IAS)
Baseline test 62
Data Dictionary 58 Implementation
Benchmark result 30, 36
Delta sizing 13, 14 2-tier 47
BI Accelerator 씮 Business Intelligence
Disclaimer 42 3-tier 47
Accelerator
Disk growth 53 Implementation phase 8, 71, 76
Blank installation 46, 47
Disk I/O operations 19, 39 Implementation project 27, 71, 74
Blueprint phase 8
Disk space Initial sizing 8, 63, 75
Business Intelligence Accelerator (BI
database 14, 39, 47 Input error 41, 43
Accelerator) 18
DPU 씮 Logical Deployment Unit (DPU) International Accounting Standard (IAS)
C Dual-stack installation 26 33
IT team 73
Cache 27 E
CCMS 씮 Computing Center Management
Employee Self-Services 75 J
System (CCMS)
Evaluation phase 74 Java-based
Chief Information Officer (CIO) 4, 74
EWC 씮 SAP EarlyWatch Check (EWC) application 25, 47
Chief Process Innovation Officer (CPIO) 4
Expert sizing 10, 29, 51, 76 Java Virtual Machine (JVM) 57
Coding
Expressiveness
custom 11, 59, 62
of sizing project 7

www.sap-press.com 107
Index

K Physical memory 18 Single record statistics (STAD) 56

Processor 18 Sizing
Key performance indicator 12, 17, 31
Product availability 5 approach 17

L 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 formula 32
Load test 12, 59 Q informational value 31
analysis 60 initial 8
Quick Sizer 35
multi-user mode 61 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
throughput-based 38, 44
M questionnaires 37, 41, 47
tool 11, 29, 51
result 38
Master data sizing 22, 26 user-based 20, 38
Save function 41
Maximum Extended Memory in Transac- verification 59, 63
sizing element 38, 44, 47, 48
tion 57 Sizing project 71
Memory consumption 13 R application team 73
Memory requirement 40, 52, 56, 57 core team 73
Reference database 23 definition 72
Methods 7
reference installations 23 documentation 74, 77
Minimum requirement 5
Residence time 19, 27 execution 71, 74
N Resizing 12, 13, 63 goal 74
Resource consumption 15, 24 IT team 73
Named user 20 Rule of thumb 29 planning 71
Network load 19
procedure 74
Network traffic 32 S project scope 71
Non-disclosure policy 23
SAP Application Performance Standard stakeholders 72

O (SAPS) 10, 38, 40, 50 success factors 71

SAP EarlyWatch Check (EWC) 67
Offline questionnaire 33 SAP GoingLive Check (GLC) 63
Online Analytical Processing 29 SAP GoingLive Functional Upgrade Check
Operating system monitor 52 15, 63, 68
Orientation phase 8 SAP NetWeaver
Business Intelligence 21, 40, 58
P Portal 21, 44
PAM 씮 Product Availability Matrix (PAM) Process Integration 4
Peak load 48, 49 SAPS 40
Peak sizing 49 SAP Solution Manager 64
Performance analysis (ST30) 12 SAP Standard Application Benchmarks
Performance monitor 51 23
Performance trace (ST05) 51, 57 Scalability 3, 61
Phased rollout 13 Sessions 21
Phases Single-instance project 15
of sizing projects 7 Single-user analysis 12
Software architecture 31
Status 42
System consolidation 13, 15
System GoLive 63, 67
System integration 65
T
T-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

108 © Galileo Press 2007. All rights reserved.

 Index

Transaction ST05 57 active 21 of sizings 59, 63

Transaction ST06 52 concurrent 21
Transaction ST07 54 interaction step 52, 57 W
Transaction STAD 56 logged-on 21
Wide area network (WAN) 17, 73
named 20
Work days
U User-based sizing 20, 38
in Quick Sizer 42
User interaction step 57
Upgrade phase 8
Upgrade sizing 13, 15, 63, 67, 75
Usage type 47
V
User Verification 77

www.sap-press.com 109