Sizing Methods of SAP System

www.sap-press.com 1
Sizing SAP®
Systems
Susanne Janssen, Ulrich Marquard
Contents
1 Introduction ................................................. 3
Sizing Definition .................................... 3
The Sizing Principle ................................ 3
Business Management and Technology 4
Goals of This Book ................................. 4
Target Group and Structure of the
Book ....................................................... 5
Related Topics ........................................ 5
2 Sizing Methods ........................................... 7
2.1 Phases of Sizing Projects ................................... 7
2.2 Methods for Initial Sizings ................................ 8
Hardware Budget Sizings ....................... 8
Advanced Sizing ..................................... 10
Expert Sizing .......................................... 10
Standard Tools — Even for Experts ....... 11
Analyzing Customer Data ...................... 11
2.3 Sizings Based on Productive Customer Data .... 12
Basic Analysis for All Production
Sizings .................................................... 13
Resizing .................................................. 13
Delta Sizing ............................................ 14
Upgrade Sizing ....................................... 15
Single-Instance Projects ......................... 15
2.4 Summary ........................................................... 15
3 Sizing Approaches ..................................... 17
3.1 Factors That Influence Sizing ............................ 17
3.2 Key Performance Indicators .............................. 18
3.3 Overview of Different Sizing
Approaches ....................................................... 20
Sizing by Users ....................................... 20
Advantages and Disadvantages of
User-Based Sizing .................................. 21
Sizing by Throughput ............................. 22
Basic Considerations and Assumptions
for Throughput Sizing ............................ 23
Advantages and Disadvantages
of Throughput Sizing ............................. 23
Sizing by Reference Installations ........... 23
Sizing by Load Tests ............................... 24
Conclusion ............................................. 24
3.4 User and Throughput Sizing Models ................. 24
Calculating CPU Requirements ............. 24
Calculating Memory Requirements ....... 25
Calculating Disk Requirements .............. 26
Frontend Network Requirements ......... 27
Conclusion for These Approaches ......... 27
3.5 Conclusion ........................................................ 27
4 Sizing Tools ................................................... 29
4.1 Rule of Thumb/Reality Check ........................... 29
Bottom-Up Method .............................. 30
Top-Down Method ................................ 30
4.2 T-shirt Sizing ...................................................... 30
Categories .............................................. 31
Pros and Cons ........................................ 31
4.3 Sizing Formula ................................................... 32
4.4 Offline Questionnaire ....................................... 33
4.5 Summary ........................................................... 33
5 Quick Sizer ................................................... 35
5.1 Quick Sizer Projects .......................................... 36
Creating a Project .................................. 36
Filling Out Sizing Questionnaires .......... 37
Determining the Sizing Result ............... 38
5.2 Functions ........................................................... 40
Initial Page ............................................. 41
Navigation Tree ...................................... 41
Header Bar ............................................. 41

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

www.sap-press.com 7
2 Sizing Methods
Sizing projects are carried out at very different stages of
an SAP project. They represent an iterative process that
depends closely on the amount of information that is
available to you at a certain point in time to make reliable
statements on the actual hardware requirements.
Accordingly, in each sizing project, you will often face
new situations that you must react to with different meth-
ods and, consequently, using different tools. This chapter
focuses on these different methods.
2.1 Phases of Sizing Projects
SAP regularly receives information requests like the fol-
lowing:
“We are a large customer in the consumer goods indus-
try with 30,000 business partners and 60,000 sales
orders containing 50 line items per month. How much
hardware do we need for our SAP application?”
This is a rather general question. The customer needs
information about hardware for a 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
̈
̈

2 Sizing Methods
the software, you will probably have only basic informa-
tion on how you are going to use it so that you can at
least make a rough estimate of the costs involved. During
the course of the implementation project, you can 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-
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 specific releases.
Blueprint phase (Phase B) 12 to 6 months
prior to GoLive
The first 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 specific 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 sys-
tem 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

www.sap-press.com 9
mation you have is that 100 users will use SAP CRM, but
you don’t know the other applications they will use and
what will be their average activity, you can certainly per-
form the sizing, but in the long run, the informational
value provided by the result of the sizing process will be
too restricted.
For this reason, budget sizings are usually performed
way ahead of the GoLive phase (most of the time in
Phase A) if the goal is to estimate the approximate scope
of hardware.
For budget sizings, you can use the user-based sizing
function in SAP’s Quick Sizer (see Chapter 5, Quick Sizer).
Alternatively, you can use T-shirt sizings (see Section 4.2,
T-shirt Sizing), which have the advantage of requiring you
to answer only a few questions. Of course, the disadvan-
tage is that the rough categorization into S through XL
provides only limited informational value. Occasionally,
such sizings can be sufﬁcient, depending on the speciﬁc
situation.
For this reason, it makes a lot of sense to compare the
time and effort you want to invest into a sizing project
with the potential hardware costs.
Hardware Budget Sizing Advanced Sizing Expert Sizing
Smaller Companies
̈ Very simple algorithms
̈ Assumptions, likelihoods
̈ Level setting of project
̈ Risk identification
Medium to Large Companies
̈ Throughput estimates
̈ Questionnaires, formulas
̈ Usage of standard tools
̈ Focus on core business
processes
Large/Complex Projects
̈ Additional guidelines
̈ Custom calculations
̈ Analysis of custom coding
̈ Custom sizing guidelines
Resizing Delta Sizing Upgrade Sizing
All Projects All Projects
̈ SAP system monitors
̈ Goal: Extend an existing system
by functions (by different
functions, e.g., you are live with
CRM and want to add SCM)
All Projects
̈ SAP Notes
̈ Goal: Upgrade SAP software
Go-
Live
Initial Sizings
Post GoLive Sizings
̈ Goal: Extend an existing system
by load (e.g., by volume, 100
additional users who will do the
same as the current productive
ones)
Figure 2.1 Overview of Sizing Approaches and Methods
Budget Sizings Help in Estimating the Entire Size
Let’s suppose a budget sizing determines 4,000 SAPS
(SAP Application Performance Standard1
). Currently,
4,000 SAPS correspond more or less to a dual-core
machine (server) with two processors, which has a list
price of $15,000. Now you can make up your mind
whether it makes sense to tackle a rather intensive siz-
ing process or whether you want to take one of the
following two risks:
Result Is Too High
This means the server will not be fully utilized dur-
ing live operations. A result that is too high often
occurs because the initial estimates are usually too
conservative.
Result Is Too Low
This means that you must buy additional hard-
ware. In this case, the question is whether you can
afford to use the wrong assumptions. Let’s sup-
pose your initial estimate is wrong by 100%. You
̈
̈
1
1 See Section 9.2, SAP Application Performance Standard, for a
more detailed description of SAPS.

2 Sizing Methods
Advanced Sizing
If you’re in a situation in which there’s a high risk of mis-
judging the requirements by several 100 percents, you
should 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
̈
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:
̈
would then have to pay (in the above example)
an additional $15,000–$20,000 for a correspond-
ingly bigger server. There are some customers for
whom expenses in this range are critical, since the
implementation of a new production server also
involves the purchase of new quality assurance
systems and testing landscapes.

www.sap-press.com 11
Identified all processes that are critical for perfor-
mance.
Used standard tools for the core processes.
Determined the performance-critical areas in which
your processes deviate from the standard.
Expert sizings are performed just before the system
GoLive, that is, when the functionality has been clearly
defined and perhaps even been implemented. In most
cases, expert sizing represents an iteration on a previ-
ously performed budget or advanced sizing so that you
can use the data of these previous processes as a basis
and simplify it, if necessary.
Basically, this method consists, on the one hand, of a
mixture of standard sizing and performance tools, and on
the other, of additional procedures and analyses. We can
roughly subdivide these two parts into:
The full utilization of the sizing tools’ functionality (in
particular, Quick Sizer’s) so that they meet specific
requirements at least in part.
The analysis and performance monitoring of core
processes in the customer system.
The following sections provide an overview of how you
can use standard tools in expert sizing to obtain useful
information, at least about parts of your system.
Standard Tools — Even for Experts
Whenever you have identified business transactions as
being close to the standard, you can use Quick Sizer (see
Chapter 5). That is, you can use Quick Sizer for partial
sizings.
Another option for using Quick Sizer in expert sizing is
that you can use it for optimizing process flows from the
point of view of sizing. For example, if you use overlap-
ping, performance-critical process chains, you can use the
24-hour load 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
map and document additional loads which, for example,
have been caused by custom coding.
̈
̈
̈
̈
̈
Simplified Example of Expert Sizing
A company uses SAP CRM applications to enter sales
orders and uses SAP ERP for sales order fulfillment and
HR. The sales order processing functions in the ERP
system have been custom-coded.
For this reason, a mixed approach is used in expert
sizing in such a way that core processes are mapped
through the standard as much as possible, while the
other processes are approached step by step:
First the company uses Quick Sizer to create a
standard sizing for sales order entry in SAP CRM.
Because the sales orders that have been entered
in the CRM system are further processed in the
ERP system, a certain amount of extra capacity is
added to the sending system, that is, SAP CRM,
according to the corresponding sizing rules.
The sizing of SAP ERP is mapped in Quick Sizer on
the basis of the total number of orders. The fact
that the orders are transferred through an inter-
face does not negatively affect the performance
of the ERP system (on the contrary, it has, rather,
a positive effect because there is no user interac-
tion). This sizing represents the basic structure of
the ERP sizing.
Because the company does not know up front
what the impact of extending the sales order pro-
cessing will be, it performs performance measure-
ments that show that, because of the extension
made in the customer system, the same process
that was mapped in Quick Sizer now needs more
resources.
The customer is now able to increase the ERP
result for sales order processing by 30% in such
a way that the customer multiplies the Quick
Sizer result by a factor of 1.3. Other results (for
instance, in HR) are not affected by this.
̈
̈
̈
̈
̈
Analyzing Customer Data
One of the most important tasks of expert sizing consists
of analyzing 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:

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.
̈
̈
̈
̈
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
̈
̈
̈
̈
̈
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
2.3 Sizings Based on Productive Customer Data

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

Upgrade Sizing
In upgrade projects, customers usually implement numer-
ous changes, which include the SAP software, database,
operating system, and an exchange of hardware. It often
happens that the 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.
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.
2.4 Summary

2 Sizing Methods
The sizing method used essentially depends on the initial
position you’re in. Basically, there are different methods
for an initial sizing, which can be mapped via standard
tools, and for a production sizing, which uses production
data as a basis for forecasting.
In this chapter, we have mentioned several times that
although sizing tools are very useful, they are subject to
certain limitations. These limitations primarily depend on
the way in which business processes and the associated
application software interact with each other. For this
reason, the following chapter, Sizing Approaches (Chap-
ter 3), describes how you can convert user-based and
throughput-based sizings into algorithms, and discusses
the pros and cons of different sizing approaches.

Index
2-tier implementation 47
3-tier implementation 47
80/20 rule 35
A
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
Application server 14, 19, 46, 55
Application team 73
Archiving object 45
Average CPU sizing 49
Average load 48
B
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
C
Cache 27
CCMS Ǟ Computing Center Management
System (CCMS)
Chief Information Officer (CIO) 4, 74
Chief Process Innovation Officer (CPIO) 4
Coding
custom 11, 59, 62
Computing Center Management System
(CCMS) 51, 65, 68
Concurrent user 21
Consolidation phase 8
Core 18
Core process
business 10, 65, 75
Core team 73
CPU 3, 15, 18, 66
CPU load 24
CPU time 3, 12, 23, 30, 57
CPU utilization 13
Custom development 8
Customer data
analyzing 11
Customer reference installation 23
Customizing 13, 17, 65
D
Database 18, 39, 53
Database monitor 53
Database server 13
Database space 13, 39
Data Dictionary 58
Delta sizing 13, 14
Disclaimer 42
Disk growth 53
Disk I/O operations 19, 39
Disk space
database 14, 39, 47
DPU Ǟ Logical Deployment Unit (DPU)
Dual-stack installation 26
E
Employee Self-Services 75
Evaluation phase 74
EWC Ǟ SAP EarlyWatch Check (EWC)
Expert sizing 10, 29, 51, 76
Expressiveness
of sizing project 7
Extension phase 8
F
Frontend network 19, 21, 57
G
Garbage in, garbage out 32, 76
GLC Ǟ SAP GoingLive Check (GLC)
GoLive 8
H
Hardware budget planning 4, 71
Hardware budget sizing 8
Hardware costs 4, 71
Hardware vendor 35, 42, 71
high-volume load tests 24
I
I/O (input/output)
per second 39
IAS Ǟ International Accounting Standard
(IAS)
Implementation
2-tier 47
3-tier 47
Implementation phase 8, 71, 76
Implementation project 27, 71, 74
Initial sizing 8, 63, 75
Input error 41, 43
International Accounting Standard (IAS)
33
IT team 73
J
Java-based
application 25, 47
Java Virtual Machine (JVM) 57

Index
K
Key performance indicator 12, 17, 31
L
Landscaping 6, 72, 78
Latency 19
liveCache 18
Load test 12, 59
analysis 60
multi-user mode 61
performing 61
planning 59
toolkit 24
tools 60
Local area network (LAN) 17, 73
Logged-on user 21
Logical Deployment Unit (DPU) 46
M
Master data sizing 22, 26
Maximum Extended Memory in Transac-
tion 57
Memory consumption 13
Memory requirement 40, 52, 56, 57
Methods 7
Minimum requirement 5
N
Named user 20
Network load 19
Network traffic 32
Non-disclosure policy 23
O
Offline questionnaire 33
Online Analytical Processing 29
Operating system monitor 52
Orientation phase 8
P
PAM Ǟ Product Availability Matrix (PAM)
Peak load 48, 49
Peak sizing 49
Performance analysis (ST30) 12
Performance monitor 51
Performance trace (ST05) 51, 57
Phased rollout 13
Phases
of sizing projects 7
Physical memory 18
Processor 18
Product availability 5
Product Availability Matrix (PAM) 5, 18
Production sizing 8, 12, 53, 67
Programming guidelines 30
Project team 73
Q
Quick Sizer 35
average CPU sizing 37
CPU peak sizing 45, 48
design principles 35
documentation 36, 41, 42
functions 36, 40
navigation 41
peak CPU sizing 37
project 36, 41, 47
questionnaires 37, 41, 47
result 38
Save function 41
sizing element 38, 44, 47, 48
R
Reference database 23
reference installations 23
Residence time 19, 27
Resizing 12, 13, 63
Resource consumption 15, 24
Rule of thumb 29
S
SAP Application Performance Standard
(SAPS) 10, 38, 40, 50
SAP EarlyWatch Check (EWC) 67
SAP GoingLive Check (GLC) 63
SAP GoingLive Functional Upgrade Check
15, 63, 68
SAP NetWeaver
Business Intelligence 21, 40, 58
Portal 21, 44
Process Integration 4
SAPS 40
SAP Solution Manager 64
SAP Standard Application Benchmarks
23
Scalability 3, 61
Sessions 21
Single-instance project 15
Single-user analysis 12
Single record statistics (STAD) 56
Sizing
approach 17
by throughput 22
by users 4, 20
definition 3
expressiveness 7
formula 32
informational value 31
initial 8
methods 7, 8, 11, 16, 27
measurement 12
object 45
principle 3
production 8, 51, 63
production sizing 13
result 40, 46
scope 20
throughput-based 38, 44
tool 11, 29, 51
user-based 20, 38
verification 59, 63
Sizing project 71
application team 73
core team 73
definition 72
documentation 74, 77
execution 71, 74
goal 74
IT team 73
planning 71
procedure 74
project scope 71
stakeholders 72
success factors 71
Software architecture 31
Status 42
System consolidation 13, 15
System GoLive 63, 67
System integration 65
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

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

Sizing Methods of SAP System

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Sizing Methods of SAP System

Ähnlich wie Sizing Methods of SAP System (20)

Mehr von Doddi Priyambodo

Mehr von Doddi Priyambodo (11)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Sizing Methods of SAP System