background sizing 1 1

28
Sizing Guide Theory and Practice of Sizing SAP Software Released for SAP Customers and Partners Document Version 1.1, February 2007

Upload: satya-bharat-kumar-naidu

Post on 30-Nov-2015

20 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: Background Sizing 1 1

Sizing Guide

Theory and Practice of Sizing SAP Software

Released for SAP Customers and Partners

Document Version 1.1, February 2007

Page 2: Background Sizing 1 1

© Copyright 2007 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. Disclaimer Some components of this product are based on Java™. Any code change in these components may cause unpredictable and severe malfunctions and is therefore expressively prohibited, as is any decompilation of these components. SAP Library document classification: CUSTOMERS & PARTNERS Documentation in the SAP Service Marketplace You can find this documentation at the following address: http://service.sap.com/sizing

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 4

Page 3: Background Sizing 1 1

TABLE OF CONTENTS INTRODUCTION........................................................................................................................................................ 5

1 MODELING SAP SOFTWARE: THEORETICAL BACKGROUND........................................................... 6 1.1 ARCHITECTURE AND SERVICES (AND A QUEUING MODEL)............................................................................. 6 1.2 SINGLE SERVICE QUEUING MODEL................................................................................................................. 8 1.3 SAP STANDARD APPLICATION BENCHMARKS .............................................................................................. 13

1.3.1 Benchmark and Performance Measurements....................................................................................... 14 1.3.2 Measuring Resource Consumption ...................................................................................................... 15 1.3.3 Benchmark Results ............................................................................................................................... 16

2 SIZING APPROACHES ................................................................................................................................... 18 2.1 OVERVIEW OF DIFFERENT SIZING APPROACHES ........................................................................................... 18

2.1.1 Sizing by the number of users............................................................................................................... 19 2.1.2 Sizing by throughput numbers.............................................................................................................. 22 2.1.3 Sizings based on customer data............................................................................................................ 23 2.1.4 Sizing an Installation Using a Reference Installation .......................................................................... 24

2.2 POST GO-LIVE SIZINGS................................................................................................................................. 24 3 SAP’S ONLINE SIZING TOOL QUICK SIZER ........................................................................................... 25

4 SIZING VS. LANDSCAPING .......................................................................................................................... 26

5 CONCLUSION................................................................................................................................................... 27

6 APPENDIX......................................................................................................................................................... 28 6.1 QUOTED BENCHMARK RESULTS ................................................................................................................... 28 6.2 LITERATURE ................................................................................................................................................. 28 6.3 FEEDBACK .................................................................................................................................................... 29

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 4

Page 4: Background Sizing 1 1

Introduction In today’s economy there is an endless variety of business scenarios, which create many different demands on the performance of standard software in general. The following lists some typical examples of common business scenarios: A telecommunications company sends out 3 million SMS over a period of 10 hours during a marketing

campaign. These in turn trigger 3 million activities in the company’s CRM system.

Every month a company must process its payroll for 450,000 employees with three retro calculations each within 4.5 hours.

A service provider is responsible for the maintenance of airplanes, which have bills of materials containing several hundred thousand entries. These bills of materials are called and changed when maintenance work is done on an airplane.

Pharmaceutical companies have to retain their data in the online system over several years. As a result their databases can reach a size of several terabytes and tables with over 100 gigabytes of data.

In Brazil every delivery must have a document called “nota fiscal” for the tax authorities. This means that every delivery note is produced twice within a very tight time window.

These examples from actual customer requests show that the most important indicators for performance are response time and data throughput. Good response times are especially important when users have to work interactively. A high throughput is generally more relevant in background processes. With respect to the database, however, an actual business transaction is nothing more than the changing or insertion of one or more lines into one or more relational database tables within one database transaction. For a typical database schema in an SAP system, this means that: In the example of the bills of materials, 100,000 lines have to be read from relational database tables,

and that simple changes can trigger complex calculations and updates in the database.

If for example a collective bill with several thousand billing items is created for a large customer, these billing items must be inserted into the table ITEM, within one database transaction.

In the example of the marketing campaign, several smaller database transactions affecting two or three lines have to be carried out in a very short time span.

However, it is not only large companies that expect a system to behave in a predictable manner when throughput rises. Smaller enterprises also expect their software to be scalable. This means that a system always has to run in the most optimal manner, not only in high performance situations, when several million document line items have to be processed per hour.

The precondition for this behavior is that the system, that is, software and hardware, are scalable. Scalability has different dimensions, as you can see from the examples below. At front-end level, it can mean scalability with the number of users

At application level, this can mean scalability with the number of processed business objects or scalability with the number of items per business object

At application level there is also the scalability with the number of jobs that must be processed

At system level, it can mean scalability with the number of application servers

At database level there is scalability with the number of CPUs, cores or threads.

When an IT system is scalable, it is possible to perform adequate sizing. During sizing the hardware the necessary resources are determined for performance-critical business processes to run smoothly. Scalability and the sizing determinations based on this scalability are the most important reasons for using SAP standard application benchmarks. They check the scalability of SAP software on different hardware and database platforms. In order to show how the benchmarks check the scalability of a system, in the following we describe the architecture of SAP systems and then touch upon the theory that forms the basis of the standard application benchmarks and sizing.

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 5

Page 5: Background Sizing 1 1

The first chapter will give some theoretical background on the software architecture as well as on queuing theory and benchmarking to be able to motivate and explain the sizing approaches used for most business applications (chapter 2). Chapter 3 explains how these sizing approaches have been implemented in an SAP’s online sizing tool, the Quick Sizer. We conclude with summing up the most important facts about sizing SAP solutions in chapter 4.

1 Modeling SAP Software: Theoretical Background This chapter describes the model that serves as the basis for testing performance, measuring scalability and making sizing predictions. The theoretical background of sizing includes aligning the architecture of SAP software with the theory from queuing models. Against that background we will explain how the single server queuing model forms the theoretical basis for sizing.

That this model along with the assumptions is valid is being proven by SAP Standard Application Benchmarks that show the system’s behavior using simulated users and data that are very close to real live data and load.

1.1 Architecture and Services (and a Queuing Model)

In order to explain the sizing model, we take a look at the architecture SAP business applications in general run on. This multi-tier architecture includes at least a database tier, an application tier and a presentation tier. On the presentation tier, there is the presentation logic for each user. Multiple users connect to the application either in the Local Area Network or the Wide Area Network, for which middleware servers within or outside the firewall are needed. The business logic of the SAP software runs on the application tier, which can either run together with the database (central server) or on separate application servers. The database, amongst others, handles the persistence of data.

As you can see from the examples below, most of the CPU load is being processed on the application tier and on the database tier.

(Fig. 1) Multi-tier Internet Architecture with typical CPU load distribution in Online Transaction Processing (OLTP) and Online Aanalytical Processing (OLAP) environments

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 6

Page 6: Background Sizing 1 1

To control, that is to reliably predict, the performance of a system as a whole, you must identify and analyze the bottlenecks of the entire system. This can be done either by using theoretical models or by performing load tests. In practice, a mixture of both methods has proven to be the most effective, because load tests can be used to examine the behavior of specific potential bottlenecks more closely than theoretic modeling alone. The following will therefore first analyze system bottlenecks from a theoretic perspective and then see how load tests, in this case standard application benchmark validate the theoretic assumptions.

First, take a closer look at the database and application layers, because it is on these layers that most of the data has to be processed in parallel.

The most important performance indicators are CPU usage, main memory usage, disk growth and I/O and required network bandwidth between application and front-end. The size of the hard disk is of secondary importance, because ideally the data located in the database does not directly influence the performance of an OLTP application.

Application Services and Database Services

An SAP system offers numerous services on the application and database tiers. Services for processing user requests, locks, printing, background processing, and others, run on the application server. The user requests and other types of requests are distributed by a dispatcher process to independent work processes in the ABAP environment and server nodes in the Java environment.

Application servers and Web servers are horizontally scalable. It is possible to define an unlimited amount of servers on these tiers, thus avoiding queuing effects. For example, in one benchmark test, 161 physical application servers connected to one database. Against that background, dialog, update and background processes can be eliminated as possible causes of bottlenecks. Likewise, services within the network and system infrastructure are not causes of potential bottlenecks – at least not when optimally configured.

This leaves hard disk, main memory, network and CPU of the database server as possible causes of bottlenecks. Again, let’s take a look at system behavior during load tests. Benchmark tests and customer system analyses have shown that the database server in terms of hard disk, main memory and network can be designed in such a way that no queue effects occur1. This then leaves CPU power (in the following, CPU can also refer to cores and threads and other components of processor architectures) as the cause of bottlenecks. In other words, the performance of a system as a whole is limited to the CPU power of the database server.

A Word on Parallel Database Systems

The challenge with parallel database systems lies in implementing the synchronization of the database caches in a scalable manner on the different nodes. Much progress has been made in this area through new developments in hardware technologies. However, SAP customers are still using parallel database systems mainly for high availability scenarios.

The CPU(s) of the database server as service center

The only queuing relevant service center of any software component is/are the CPU/s of the database server, because all other components of the database server such as memory, disks, and network bandwidth can be chosen, tuned and configured in such a way that queuing effects can be neglected for them. These heuristic considerations and arguments explain why we think that it makes sense to describe an SAP software component as a single service queuing model.

From this model we can deduce some formulas that provide a mathematical basis for our model and allow quantitative statements on throughput and response times.

1 Even if this may mean high investments in main memory, network bandwidth, and disk I/O capacity.

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 7

Page 7: Background Sizing 1 1

1.2 Single Service2 Queuing Model

Based on the above considerations, we model an SAP system using a single service queuing model which renders simple formulas. These in turn provide quantitative information about response time and throughput behavior of that system.

The model has one queuing buffer and one or more identical servers [Bolch et al]. In our case a server refers to a database CPU. Another assumption is that one CPU can process only one request at a given point in time. Throughput, response time and CPU usage are highly interdependent parameters in this context. The response time is especially important, because its dependence on the usage of the service center is non-linear. In the simple case of a one-processor machine, which can be modeled after the M/M/13 system, the function shows a hyperbole. Symmetrical multi-processor machines are modeled using M/M/n systems. Their response time behavior is similar, although the response time remains close to constant during larger load periods, it then increases tremendously.

Our single service queuing model has the following dependencies (see also Lozowska et al, Bolch et al): The CPU utilization law and the response time law put the utilization, throughput, end-user number, user activity and think time in one interrelationship.

Calculating with the model (M/M/1)

Utilization law

This law puts into a relationship the data throughput λ and the service time σ that make up the utilizationρ.4

σλρ ∗= (1.1)

Response time law

Here, the number of users N divided by throughput λ minus the measured think time Ζ are used to calculate the expected response time of the CPU

ZNT −=λ

(1.2)

2 Or Single Station Queueing Model (cf. Bolch et al., 212ff.) 3 M/M/ means that the number of arriving requests is equal to the number of processed requests. 1, n refers to the number of CPUs.

4 ρ = Utilization Z = Think Time

σ = Service Time T = Response time

N = Population (number of users) T = Mean Response Time

λ = Throughput T̂ = Mean normalized response time

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 8

Page 8: Background Sizing 1 1

Number of users that can be processed simultaneously

The highest number of users a CPU can process simultaneously can be obtained by adding the measured response time and the think time, multiplying this with the utilization and dividing the whole thing by the measured service time.

σρ )( ZTN +∗

= (1.3)

The mean normalized response time T ˆ

You can also use the above figures and the relationships to predict to a certain extent how the system

will behave. In this case, the mean response time T and the service time σ were normalized.

ρσ −==

11:ˆ TT . (1.4)

This formula expresses the mean throughput time using Little's Theorem in a single processor machine. You can see that the mean response time increases sharply if the system is utilized to a great extend. The dependencies in a multiprocessor machine, however, are more complex, as we will show in the following.

From theory to practice and vice versa

Performance tests on a single processor box should yield a graph similar to the one below. The x-bar depicts the utilization, the y-bar the response times (mean response times using Little’s theorem.)

Normalized Service Times for One CPU

0

2

4

6

8

10

12

14

16

18

20

0,00 0,20 0,40 0,60 0,80 1,00

Utilization ρ

Mea

n R

espo

nse

Tim

e

ρ−11

(Fig. 2) Normalized Service times for one CPU

The graph shows the expected behavior of a single processor machine. The heavier the machine is utilized, the more the requests are in a queue. In order to verify our assumptions, we compare measurements from a 1-processor, 2-processor, and 4-processor machine with the theoretically obtained values from above. The results are quite astonishing.

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 9

Page 9: Background Sizing 1 1

In the following graph actually measured values have been normalized and referenced to the theoretical values for a single processor machine.

(Fig. 3) Comparing Throughput in n-Processor Machines

Let's have a first look at the single processor machine. With low utilization the actually measured value is much worse than the assumed one, possibly due to some overhead in the machine. Under heavy utilization, its actual response times are 50% better than what could have been expected by queuing theory. There can be two reasons for this: With high processor utilization, monitors give out measurement mistakes

Overhead by processes running in the background on the machine.

What is more surprising, however, is that two- and four-processor machines show a distinctly different behavior. At 60% utilization, the 2-processor machine performs 50% better, a 4-processor machine a 100%. At 70%, the effect is even more dramatic: The 4-processor machine performs more than 150% percent better than the theoretical value for the single processor machine.

The above results show that we cannot describe the behavior of single processor machines by 1- 1/ρ. Therefore we must amend our model. For this purpose, we use an M/M/m system. In this model there is only one queue but n service centers5. In theory, the knees of the curves are sharper due to good response times at higher utilization.

5 As the formulas are quite lengthy, we only summarize theory.

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 10

Page 10: Background Sizing 1 1

(Fig. 4) Normalized Service Times for n-Processor Machines

From the graph you can see that the knees of the service times curve vary considerably when comparing machines with different processor distribution. A four-processor machine utilized to a great extent can still provide good service times. However, when a certain load is reached, such a system behaves much more chaotic than a single CPU system. Even though a certain load should not be exceeded, one can deduce from this observation that each CPU in a symmetric multiprocessor machine can be used much more efficiently, economically and cost-effectively.

Example for efficient use: When a 4-processor machine is utilized to 80%, each processor is utilized to 80% on average. In the best case, a new incoming request will see 3 processors working with 100% utilization and 1 processor with only 20%. The request effectively sees a queue length equal to the queue-length of a single processor machine with 20% utilization. Of course this argument does not reflect all details of the behavior of a symmetric multiprocessor machine. Still, it holds true for a very high level of accuracy as can be seen from the exact values displayed in the above graph.

Dependencies of response time and throughput

Now, when we look back at the formulas for the M/M/1 system, we can see that there are two dependencies. There is a linear dependency of throughput on utilization and a hyperbolic dependency of response time on utilization in which a small change on the x-bar leads to enormous changes on the y-bar. In a multi-processor environment the response time is a non-linear function of the utilization of a service center and thus a complex value to deal with. Throughput, however, with its linear dependency on utilization is much easier to measure and calculate, irrespective of whether they are multi-processor machines or not.

Considering Throughput

Since there is only one database server available in the system, the surrounding devices must be laid out in such a way that it can handle throughput efficiently. Therefore application servers must have no queue which can be achieved with target utilizations of between 30% and 50%, depending on whether they are single- or multi-processor machines. Since they are generally multi-processor machines, 50% average target utilization is fine.

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 11

Page 11: Background Sizing 1 1

With regard to sizing SAP software components, the considerations from above can be translated into a two step procedure for sizing. 1. In the first step the CPU power of the database server has to be chosen in such a way that both the

throughput and the response time requirements of the database server are met.

2. To ensure that the model developed above is valid, all other service centers such as the CPU(s) of the application servers as well as main memory, network bandwidth and disks have to be sized so that their utilization is not higher than some 30% to 50%. This ensures that queuing effects of these service centers can be neglected so that they can be modeled as service centers with constant response times6. The total response time then is the sum of the database response time –which depends on the utilization of the database server– and the delay due to the other service centers. This delay is independent from the load.

This two-step procedure simplifies the sizing procedure strongly as well as the bottleneck and performance analysis of the software component – the only component we have to deal with is the CPU power of the database server. It is the starting point for sizing, system configuration, and performance analysis. All other components need not be sized independently, but should be chosen in such a way that they are powerful enough to avoid additional queuing effects.

A prerequisite for this procedure is measuring the service times for the most relevant SAP business processes so that the throughput law (equation 1.1) and the response time law (equation 1.2) can be applied properly. These service times are –as already discussed– CPU times of the dialog, update, and batch work processes

CPU consumption on the database server (or the CPU time of the database processes)

Memory and I/O-bandwidth requirements of these servers (cf. next chapter)

The results of the CPU measurements heavily depend on the tested hardware. Different CPUs with different architectures and clock speed will produce different figures. Therefore a hardware and platform independent measurement environment and procedure has been developed by SAP. It allows comparing different hardware configurations. Memory, network load, disk I/O are certainly also important performance KPIs which can deteriorate a system’s performance if not supplied in sufficient quantities. In the following, we’ll describe the characteristics of SAP standard application benchmarks which have been designed for the sole purpose of monitoring resource consumption of SAP applications and hardware configurations in load situations.

6 They are often referred to as "delay centers"

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 12

Page 12: Background Sizing 1 1

1.3 SAP Standard Application Benchmarks

There are different methods to analyze the performance of a system. These methods can basically be subdivided into measuring methods and modeling techniques. However, to measure, compare, and normalize the service times for different platforms all approaches need a hardware independent standard.

The following two approaches to define a platform independent performance standard with the help of benchmark programs or suites are:

• Real-world reference machine. All measurement results are compared with the results obtained on a real-world reference machine (such as the MIPS7 definition). This is a simple model, but amongst others, fast development in hardware technology and portability issues are the great disadvantages of this model.

• Theoretical reference machine. An abstract machine or a theoretical reference machine is defined by its performance characteristics alone. Because it is an abstract machine, its performance can always be adapted to the state-of-the-art. Haas & Zorn suggest an abstract machine with simulations of real processes to determine the load factors8 (cf. Haas, Zorn, 18). The performance is defined by throughput and response time numbers of specific programs.

SAP opted for the second approach as a more unified analysis of SAP applications. The theoretical reference programs are called SAP Standard Application Benchmarks. These application benchmarks simulate user or background activity for different applications, thus creating throughput. In turn, throughput numbers define the processing power of a system or configuration. For better comparison capabilities, SAP introduced a hardware independent unit called SAPS9.

The most important reasons for choosing the abstract reference machine are: Using an abstract reference machine allows to compare different architectures as well as different

client/server configurations (2-tier, 3-tier, multi-tier). This is very important when testing scalability issues.

Due to the rapid progress in hardware technology, a physical reference machine will be outdated very quickly.

SAP always considers throughput in the context of business processes. This also enables the comparison of SAP software with legacy systems.

Furthermore, this kind of definition takes into account that the implementation and tuning of hardware and software components on different platforms may differ.

In the following chapter we describe the definition and the most important features of SAP Standard Application Benchmarks.

7 Million Instructions Per Second 8 cf Haas 1995 9 SAP R/3 Application Benchmark Performance Standard (SAPS): 100 SAPS are equivalent to 2,000 fully processed order line items per hour. 6,000 dialog steps (screen changes) with 2,000 postings or 2,400 SAP transactions.

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 13

Page 13: Background Sizing 1 1

1.3.1 Benchmark and Performance Measurements SAP and its hardware partners have developed the Standard Application Benchmarks to test hardware and database performance of multiple different SAP software applications running on multiple different operating systems, database architectures and hardware configurations. Released for hardware, logo and technology partners, the benchmarks: Provide basic sizing recommendations to customers

Place substantial load upon a system during the testing of new hardware, system software components, and Relational Database Management Systems (RDBMS)

Available since SAP R/3 Release 1.1H (April 1993), there are benchmarks reflecting different performance behavior of different business applications and programming languages and architectures. Amongst the benchmarks you will find, for example: The most common SD standard application benchmark (details will be shown below)

An Interaction Center benchmark which simulates call center users creating load within very tight required response times and a Web interface

Two business intelligence benchmarks which simulate upload processes of millions of data records or users that perform data mining

Two benchmarks where users access backend data and utilize Enterprise Portal services

Two benchmarks simulating extensive planning functions using the liveCache, a central planning component within SAP NetWeaver

A banking benchmark designed to process millions of account statements within one hour

Most of the benchmarks are online benchmarks simulating end users, but there are also a number of background benchmarks.

Simulating real-life users

A Standard Application Benchmark basically consists of a number of script files that simulate the actions of a typical user in each of the business applications, as well as a predefined SAP database which contains sample company data against which the benchmark is run.

The benchmarks are designed to perform the most typical transactions of the application components. The transactions have been chosen to depict the quantity structure of an installation (e.g. orders per day, number of goods movements, etc.).

The business applications have been customized so that computer system resource consumption is kept to a minimum but still represents the economic reality. Comparable customizations can be found in SAP installations which have a need for high data throughput.

In general, each benchmark user has its own master data, such as material, vendor or customer master data to avoid data locking situations. An exception to this rule is the Assemble-To-Order benchmark which reflects the production of a PC and which is designed to handle locking situations and overcome them.

The multi-tier Internet architecture of almost all SAP business applications consists of a database, application and presentation layer. Possible configurations for benchmark simulation are:

Two-tier configuration

Database and application layer reside on a single system. The simulation is driven by a presentation server. You can even run all layers on one system, thus obtaining sophisticated information about the system's performance.

Multi-tier configuration

Database and application layer are on separate systems. The simulation is driven by a presentation server. A possible configuration can be:

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 14

Page 14: Background Sizing 1 1

1 database server (or several when using parallel database techniques)

n application servers (n tested up to 161) with dedicated enqueue, update, message and dialog server

n presentation servers (benchmark drivers)

This configuration achieves an impressive degree of scalability on all tiers.

During a benchmark run all performance data relevant to system, user, and business applications are monitored and can be used to compare platforms and as basic input for sizing recommendations. In addition to published application benchmarks, SAP uses automated test tools and methods to reliably measure performance KPIs of the different SAP applications.

1.3.2 Measuring Resource Consumption Each online benchmark consumes system resources in different proportions. The below diagram describes the distribution of resources for a sample hardware and RDBMS configuration for a specific software release. The relative CPU load in the sample benchmark results is adjusted to Financials (FI). That the business applications are designed to scalability can be obtained from the percentage of load that the database CPU handles. In the below example the load is between 8% and 22%, depending on the application. In real-life systems the percentage would be higher, because the benchmarks environments are optimally tuned for high-performance, whereas in customer installations you usually have custom-coding, additional functions and so on. Still, these results yield a sound basis for sizing estimates, as we’ll see in the following.

(Fig 5): Example for CPU load factors obtained form benchmark results

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 15

Page 15: Background Sizing 1 1

1.3.3 Benchmark Results This section is again a bit more theoretical. The following graph shows a number of benchmark results for the SD benchmark since 1993 (fully business-processed order line items per hour). The Sales and Distribution benchmark is one of the most CPU-intensive benchmarks and has become a de-facto standard for SAP's platform partners and in the ERP (Enterprise Resource Planning) market.

(Fig. 6): Published Results for SD Benchmarks (Three-tier Configuration)

The benchmark results show that the system architecture scales. Many customers inquire what the meaning of the graph is. Although the information is obtained from SAP software, SAP's only share in this graph is that the system architecture has not changed significantly through the years. Instead, hardware is becoming increasingly faster and better. Resource requirements for the applications themselves have remained relatively stable. The number of database accesses has increased, but they have also become more efficient. Within SAP development, we monitor this important information for each release and publish SAP Notes on relative resource requirements.

The first three-tier benchmarks ran on 4 CPU machines with a 100 MHz database server, and six to ten application servers. The current record benchmark10 of more than 160,000 SD benchmark users ran on a 32 CPU database (1.4 GHz) and 12 application servers. The following list shows the throughput of the benchmark from the point of view of the database.

10 As of September 2006; probably outdated very soon, but not without proving the point still in ten years from now.

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 16

Page 16: Background Sizing 1 1

(Fig. 7) SD Benchmark results on a three-tier configuration

The figure shows the load the database was able to handle during this SAP benchmark and what demands are made on relational database systems by production systems. For example, in this benchmark more than 5000 database transactions were executed per second and 470,000 lines were inserted into different database tables. The relationship between inserted lines and database transactions shows that we are dealing with relatively short database transactions – on the median, around 94 table lines were inserted per transaction. Because the SD benchmark dialog users are simulated, the transactions have to be short, to ensure quick response times. In a production system, however, there are also other batch-like processing steps that are executed in parallel, where database transactions with 10,000s or even 100,000 changed table lines are not uncommon.

Another indicator is the number of SQL statements that are processed per second. Without effective statement caches on the application side and also on the database side, these numbers would not be achievable, because alone the CPU usage for parsing the commands would exhaust the available resources. For the design of OLTP applications this means that the reusability of requests is of great importance.

In addition it is important to consider the amount of data that is written to the hard disks for this benchmark. This cannot be explained alone by the transaction log of the database. The indexes needed for the read accesses are also significant. Many of the application tables that are changed in this benchmark have one or two secondary indexes in addition to the primary key, one table even has six additional indexes.

A final aspect to consider is the package size used in the network traffic between the database server and application server. With OLTP transactions generally small amounts of data are read in the database using highly selective SELECT commands. This leads to having many small packages, as you can also see from the benchmark result details from above.

The next chapter shows how the information from benchmark results and other performance measurements translates into sizing guidelines.

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 17

Page 17: Background Sizing 1 1

2 Sizing Approaches The preceding chapters discussed theoretical sizing approaches and methods to measure system resource consumption by using standard application benchmarks. Sizing combines these two topics and models basic resources of SAP business applications. The following will show the pros and cons of different sizing approaches and explains which approach SAP favors.

Note that the argumentation is based on assumptions because we cannot reliably measure the resources that can make up a system. This is because of the vast variety of different factors such as disks, network configuration, releases, parameter settings, user behavior, etc. that influence the resource consumption. The following overview points out the most important parameters that are being considered. User behavior can be defined in many different ways, for example in technical terms or rather in

business terms. A very important parameter is the activity profile of a user which means how often and frequently will a user send requests to the system. This is normally expressed by the user's think time.

The applications used have an impact on resource consumption. Some components put more load on the system than others and special functionality can cause high additional load. So a differentiation has to be made.

Customization from a more technical standpoint. Customer modifications can have a strong influence on the resource consumption and the way business transactions are being processed. This includes business processes, expected throughput, and tuning of the operating system, the RDBMS and the system parameterizations.

In addition, there is a weaker overall influence from the RDBMS and the releases of SAP business applications and the operating system, respectively.

Due to the fact that actual measurements should only be interpreted with regard to the environment they have been conducted in, we assume standard values for the most important business processes. Our assumptions stem from experience in customer systems, Standard Application Benchmarks and single process performance analysis. This enables us to incorporate data from different sources.

2.1 Overview of Different Sizing Approaches

It is the goal of sizing to estimate how much hardware in terms of CPU, disk, memory and front-end network is needed to run SAP software in the future. Dedicated configurations and landscaping are out of scope of the SAP standard sizing.

For sizing most SAP applications we have identified three different and independent sizing models that have different advantages and disadvantages. In the following graph you can see the approaches and their distinguishing features. They include amongst others the exactness of the results, effort, personnel costs, or time. There is no ideal approach as such; you will always have to make a compromise of a certain kind. The reference installation is also being mentioned as a possible approach to sizing.

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 18

Page 18: Background Sizing 1 1

Incr

easi

ngly

acc

urat

e User-based

Throughput-based

CustomerPerformance Test

Incr

easi

ng e

ffort

s an

d co

st

Reference Installation

Incr

easi

ngly

acc

urat

e User-based

Throughput-based

CustomerPerformance Test

Incr

easi

ng e

ffort

s an

d co

st

Reference Installation

(Fig. 8): Three sizing approaches and a reference installation11

The three approaches can be regarded completely independent from one another as they all emphasize different system usage and business characteristics. So when results from them differ to a great extend it is very likely that some input assumptions are wrong or that the input parameters to the different models are inconsistent (garbage-in, garbage-out). Sometimes the most important parameters for a sizing approach such as user activity (think time) in the user based sizing are very difficult to estimate. Thus it is clear that the results will suffer from a high uncertainty. In the following, we introduce the sizing models.

2.1.1 Sizing by the number of users

Assumptions

If you look at it closely, you realize that a "user" is a very abstract notion. There are a number of possible definitions for users in the SAP context.

11 For further information on customer performance tests refer to the whitepaper Carrying out Customer Performance Tests, available on SAPNet for customers and partners in the Performance archive.

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 19

Page 19: Background Sizing 1 1

A named user is a user with an account. This user is not necessarily logged on to the system. Since this is a user without a profile in terms of load this user creates it is impossible to use this information as an input for sizing, although, alas, it is the easiest for the customer to obtain.

Logged-on users processed a logon procedure and are able to work with the system, though they may take a coffee break or attend an important meeting. Depending on the architecture of the system they consume different resources in the system, but they do not necessarily consume sizing-relevant amounts of CPU, front-end bandwidth, disk and memory.

Work places or front-ends include all front-ends that have been installed in the network. This number differs from the number of users because one front-end can be used by several different users, or one user can work on different front-ends. There is no use in counting all PCs or laptops to determine users.

Sessions comprise the number of sessions a users has open at the same time. Most users will work only with one session at a time, even if they have opened multiple sessions. For each session, however, some memory is needed to store the session context. So though it is possible to count the number of logged-in users and the sessions they have open it is probably not worth the effort.

Concurrent users are working simultaneously or concurrently in the system. They consume system resources at the same time. They are often mixed up with logged-on users, and sometimes concurrency is defined in terms of simultaneously accessing a work process or a specific database entry.

An active user is basically a concurrent user with a time stamp. The SAP user sizing approach defines active users that go through a given number of business processes in a given time period. It proved to be convenient to distinguish between three categories of active users in most of SAP’s sizing procedures, because these categories represent typical activity patterns of users

-

-

-

A Low User or occasional user processes on average ten interaction steps an hour12 or one every six minutes.

A Medium User processes in average 120 interaction steps an hour or one every 30 seconds. Most users will have a comparable profile

A High User processes an average of 360 interaction steps an hour or one every 10 seconds. This is typical for power users working in call centers or doing data entry.

Most users are defined like the above active users. Special users, for example in the Portal, are treated slightly differently, although they are still defined by there think time. Business intelligence users are distinguished by the reporting behavior they perform, for example.

Advantages, disadvantages

An advantage of user based sizing certainly is that the distribution of active users across applications and application components can be determined quite easily. For sizing, we would consider the input of these users per application scenario, which works fine for small systems (up to 200 concurrent users). However, as you can obtain from the above listing, it is very difficult to clearly define a user, and the number of users heavily depends on the definitions used. This shows that sizing procedures that rely on user numbers have a very huge systematic error due to the fact that the user numbers are not well defined and that the effort to determine and forecast the activity and behavior of a user to a high level of accuracy is very high. Thus there is a high risk to do capacity planning for a large system just with a user-based sizing model.

12 Assuming a working week of 40 hours

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 20

Page 20: Background Sizing 1 1

The Model

In order to reflect the considerations laid out before, the user sizing model contains load factors to take into account the impact of different application scenarios, business processes and user behavior. In the following we describe what the calculation is based upon. CPU consumption. Load factors model CPU resource consumption of different user types, different

business processes and different software components. These CPU load factors are measured with the help of the Standard Application Benchmarks and other performance test tools and methods. We also assume that the users are mainly spread across the most important business processes of the respective scenario. For calculation purposes, the users are normalized and weighted. Expressed in a simplified formula, it would look like this:

CPU consumption = application load ∗ number of normalized active users

Memory consumption. In general, memory sizing includes user specific and shared resources. This includes the user context, as well as the use of work processes, shared buffers and JAVA specifics. Expressed in a simplified formula, it would look like this:

Physical memory consumption = shared buffer + context ∗ number of users

Of course, the size of the shared buffer and the size of the user context strongly depend on the application components; we therefore distinguish between memory requirements of the database and the application server. Because each application server consumes memory on the database, we assume one physical application server. If several application servers are installed in the end, you need to factor this in the eventual hardware lay-out.

Most sizings only offer memory sizing based on users. There are some memory-driven applications, where memory requirements are determined through the throughput sizing, such as liveCache or Java-based applications.

Disk size. With the help of the user activity profile you can calculate how many business processes of an application component will be processed by each user in a specific time interval. Because of the SAP data model it is a straight forward calculation to determine the amount of disk space needed to store the business documents of a certain business process. Expressed in a simplified formula, it would look like this:

Disk size = Minimum requirement for empty system + number of work days per year * disk_parameter * active users

Front-end network bandwidth. The network traffic between presentation server and application server depends on the application and the front-end design. In general it is around 7 KB and one round trip for each user interaction step in standard SAPGUI applications13. Thus the required network bandwidth can be calculated easily. To calculate the total response time measured on the presentation server, the network latency has to be added to the application server response time.

13 For more information on front-end network load requirements of SAP solutions, see the respective paper at service.sap.com/sizing guidelines solutions.

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 21

Page 21: Background Sizing 1 1

2.1.2 Sizing by throughput numbers Throughput sizing can be applied if the system is not implemented yet, but the customer has a rough idea on the expected data volume and throughput per component and business process. It is typically the second phase in a sizing project, where the business blueprint has advanced to a certain extent.

Assumptions

Most of the business processes used in the system are comparable to the business processes tested in the SAP Standard Application Benchmarks and are optimized for high throughput. There is no special data constellation like very big orders (of higher than 10,000 items) or very big bill of materials (of more than 15,000 materials).

Reporting normally takes place during time periods where the load on the system is small as compared to the peak load. Therefore reporting can mostly be neglected except for business intelligence.

There are no customer add-ons that have measurable impact on the system performance or scalability.

The CPU(s) in a 2-tier configuration architecture or the CPU(s) of the database server in a 3-tier configuration are the bottleneck resource of the system, all other resources like network bandwidth, memory or disk I/O are configured in such a way that their utilization is small enough to avoid queuing effects.

Example: A machine that can handle 100 SAPS as an application server is also able to handle the requirement of 100 SAPS as a database server. (SAPS (DATABASE) = SAPS (DIALOG) = SAPS (UPDATE) = ...)

The above means the following:

A server with a central SAP Enterprise Core Component installed that can handle 6000 dialog steps per hour in the SD benchmark has a standard throughput power of 100 SAPS.

The performance measurements on this machine yield a ratio between database and application CPU of 15% database and 85% application.

A customer who needs to process 40,000 SD benchmark dialog steps per hour, which is a requirement of 667 SAPS for the total system. From the above we know that we need 667 * 0,15 = 100 SAPS on the database and 566 on the application server. A server like the above mentioned can be used as a database-server (assuming that 100 SAPS (mixed) - which was measured in the 2-tier configuration - equals 100 SAPS (DB)) with a CPU utilization of 100%. If six additional application servers of the same type are used as application servers, they will be utilized with 566/600 = 94%.

Measurements on Standard Application Benchmarks show that the above assumption is normally valid within a 10% error margin (or less). This avoids a lot of additional measurements with different configurations, but there is need at least for one two-tier and one three tier benchmark result on a given hardware to verify this assumption.

Advantages, disadvantages

The advantage of this model, relative thoroughness, can quickly turn into a disadvantage. This model makes quite precise assumptions for data throughput which can therefore easily be misleading if one or more of the assumptions above are not valid. There is also a certain risk that during the implementation of the business processes some of the requirements defined beforehand have to be re-adjusted. However, for large installations a throughput sizing of some sort is an absolute must.

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 22

Page 22: Background Sizing 1 1

The Model

CPU consumption. Standard Application Benchmarks are used to determine the CPU times (service times) for each transaction and service (dialog, update and database) on a reference CPU. The SD benchmark is used to measure the number of SAPS of the reference CPU. Thus the formula (1.3) of the queuing model can be used to calculate the CPU requirements for the database and application servers.

For the CPU calculation you need to know the number and the size of the business objects / transactions / scenarios that are being processed in a specified time frame. Expressed in a simplified formula, it would look like this:

CPU consumption = number of objects / processing hours

Disk consumption. Calculating the disk space used is straightforward and independent of the database and operating system.

To reduce the number of needed parameters, only those tables are taken into account that will see a lot of inserts and which will store business data that is needed for a long time. In the next step, the net size of the table rows is determined as well as the net size of the indexes for each row. This depends of course on the data distribution, but can be neglected within the required range of accuracy. Further input parameters for the calculation are the number of lines in each table, which can be derived from the amount of business processes, and the retention period which determines how long the table entries will be stored before they can be deleted. Finally the disk space needed to install an empty system without business data has to be added. Of course this calculation does not include additional requirements due to mirroring, other RAID systems or the operating system. Compression algorithms of the database are also neglected. Expressed in a simplified formula, it would look like this:

Gross disk space = number of objects * size of objects * (table width + index width) * residence time in the DB

Memory consumption. Usually, user contexts dominate the memory requirements; therefore they should be calculated by the user based sizing model. For Java applications, garbage collection has an influence both on memory and CPU and is therefore being factored into the sizing guidelines. The LiveCache, which is used for planning purposes, also contains a dedicated model to calculate memory resources based on throughput. Expressed in a simplified formula, liveCache memory sizing would look like this:

Physical memory consumption = number of objects held in memory for planning run * size of objects * memory_parameter. For reasons of simplicity, memory sizing can also be made by tying it to the CPU requirement.

Network bandwidth. The network bandwidth to the presentation server is of course dominated by the number of concurrent users and the complexity of the GUI. The front-end can be sized based on user activity. Expressed in a simplified formula, liveCache memory sizing would look like this:

Bandwidth = number of hits per second * GUI_parameter

2.1.3 Sizings based on customer data All guidelines that SAP delivers are based on standardized performance test scripts that assume an excellently configured and tuned system and optimally customized software. Sometimes customers include own developments or third-party software into the landscape, so that they deviate significantly from the standard. Still, SAP recommends these customers to also use standard sizing guidelines as a starting point to get a rough estimate first and then take their own data and systems as a more valid basis.

Black-box sizing validation requires a test system or a productive system where fractions of the

estimated future load is run upon. For example, in the final layout a customer wants to process 600,000 sales order line items per day. The first country go live is with 12,000 items per day. If the customer monitors CPU and memory utilization and observes disk growth, they can check the

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 23

Page 23: Background Sizing 1 1

utilization of the allocated hardware is matches the load. If there is a deviation, measures must be taken, such as system tuning efforts or even performance optimizations. The approach is called black-box, because you simply ascertain the facts. The advantages here are that this can be done quite easily; the disadvantage is that it must take place during production and may come too late.

Another more sophisticated but thus more time-consuming exercise is to measure resource consumption of time-critical bread-and-butter transactions. This is also a black-box approach in the sense, that you create and run test cases and use the SAP monitors to collect the key performance indicators without needing to know the coding. With these numbers, you can create your proper sizing guideline.

A third possibility is to run high-volume load tests. If set up and executed efficiently, they do not only deliver a sizing validation, but also help to verify scalable software and system infrastructure, including load balancing, parallel processing capabilities, locking behavior, system tuning and parameterization, bottleneck analysis for infrastructure, fail-over, back-up and disaster recovery strategies as well as monitoring and system administration, and even a calibration of thresholds. When it comes to questions of robustness, load tests can check for deadlocks, data inconsistencies, possible performance degradation in overload situations and identify possible memory leaks (especially with Java applications). The disadvantages clearly are time and skills that are required to perform these tests. For more information on conducting load tests, see http://service.sap.com/performance Media Library.

2.1.4 Sizing an Installation Using a Reference Installation This approach does not really belong to the group of the above mentioned sizing approaches. A reference database consists of real live data from existing installation allows a new customer for example to get information about how a similar project was implemented and sized. Here the biggest problem is to define "similar", in most cases "similarity" of systems will of course be defined by the business processes used.

Reference installations at customer sites can help to verify sizing procedures, too. The basic idea is that a sizing is done with the statistics available in the productive system, such as: The number of users for particular transactions and reports

CPU time

General system response time

Number of database calls

Dialog steps per transaction and report

Size of database tables

Size and quality of buffers

The issue here is that customer A from industry Z may not be willing to share their business and installation information with customer B from the same industry. In general, the above information is available from the CCMS tools and the application monitor and could be used as input for the sizing models to do an "ex post sizing". Comparing the result of the sizing with the real configuration allows to test and verify the sizing assumptions, procedures and forecasts and would therefore improve the quality of all sizing procedures considerably. However, as non-disclosure policies are strictly being adhered to, this option is impossible.

2.2 Post Go-Live Sizings

There are sizing approaches that take place after going live. These approaches address different goals of the sizing exercise. Resizing: A resizing approach is appropriate when you are extending an existing application by

volume and time periods only. The method is quite simple: monitor CPU utilization, table growth, and memory usage; relate it to a meaningful business entity, such as the number of concurrent users or the number of active projects; and add the load coming in through the additional users and projects

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 24

Page 24: Background Sizing 1 1

causing the same load structure. Here, since your own productive data is apt to provide a meaningful basis for predicting hardware requirements, we do not recommend using the Quick Sizer tool. Instead, you can use performance monitors to monitor CPU and memory utilization (OS monitor, ST06), database growth (database monitor DB02), front-end network load (statistical data records, ST03) and, based on this information, judge, if your current hardware is sufficient, or if you may need to buy new one. This exercise is also performed when doing a sizing validation for a phased roll-out.

Delta Sizing: If you are changing the business by adding new functions to an existing system, for example, you decided to add supply chain management to your existing ERP application or are simply exeeding the scope of functions. With delta sizing, you take note of current utilization (as described above) and add the projected load of the new functions, for which you can use the Quick Sizer to estimate.

Upgrade Sizing: When performing an upgrade, you must be aware that there may be different upgrades you are facing, such as hardware, platform, or software releases. The best approach is to analyze each upgrade by itself and add the resulting requirements, if needed. Hardware and platform vendors provide their own upgrade information, and SAP performs regression testing of their standard business test cases (about one hundred top transactions) and sums it up in notes that describe the influence of the upgrade on CPU, disk, memory, and front-end network in a hardware-independent format. If you have implemented the new release on your own hardware, you can quantify the influences much better by benchmarking your key transactions in both releases as described above. Also, we recommend not to use the Quick Sizer tool, because your installed data is much more meaningful.

3 SAP’s Online Sizing Tool Quick Sizer SAP built the Quick Sizer as an online Internet application in close cooperation with its technology partners. This tool delivers, based on customers’ estimates and input, general sizing categories for an initial sizing, that is, for first-time implementation of SAP software. The results provide an objective basis for sizing, independent from platform and configuration.

In the Quick Sizer, two of the above sizing models have been implemented independently of each other: user sizing and throughput sizing. The most important reason for offering independent sizing models in one tool are the different advantages and disadvantages as discussed in the previous chapter. Furthermore, there are different limitations in the validity of each approach. Therefore it is strongly recommended to enter the input for both sizing approaches and compare the results. Thus the accuracy and the confidence level for the sizing forecast is increased considerably, because the input parameters and values for user sizing and throughput sizing are nearly completely independent. If the results of the two sizing models differ, the user has the possibility to check the input parameters for plausibility, for example number and activity of users in comparison to the expected throughput or completeness of the business functions entered.

Another important reason for offering two sizing approaches in the Quick Sizer is to gather as much input as possible about the planned resource requirements of the system and to standardize these input parameters for further analyses, for example the GoingLive service of SAP Support. In order to compare a system to a reference installation, both the system and the reference installation have to be characterized by a set of stable and well-defined parameters. Otherwise, a reasonable comparison would be impossible. Thus the questionnaires of the Quick Sizer are a mandatory subset of parameters to define the performance characteristics of an SAP software application or a software component on a business or application level in a platform independent way. Of course there are additional parameters on a technical level, such as CPU-utilization, I/O bandwidth, or network latency to give some examples that have to be considered when characterizing an installation completely.

The platform independent, abstract results of the Quick Sizer can be used by any of our hardware partners to create an actual offer. SAP itself does not make any hardware recommendations, the responsibility for sizing and detailed hardware configuration lies with the hardware vendors.

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 25

Page 25: Background Sizing 1 1

Finally, the result of the Quick Sizer should be used during system installation and configuration. For example the detailed forecast on table and index sizes can be used as important input for the initial database layout.

During the implementation phase, the questionnaire of the Quick Sizer should be used on a regular basis to check whether changed business requirements lead to changes in the sizing results which would imply a system reconfiguration.

The Quick Sizer should not be used for a resizing or an upgrade sizing, as the customer data delivers much more accurate results.

For more information on the Quick Sizer see http://service.sap.com/quicksizing.

4 Sizing vs. Landscaping It is certainly good to know how much hardware resources are required to run SAP software. A burning issue with customers is to know just how to distribute these abstract resources to real hardware, particularly in consolidation projects. The expectations are often that sizing must account for this, too. However, landscaping, that is, determining which applications, components and services can be installed on dedicated servers is a dedicated process of its own. Devising a complete hardware landscape involves several phases which are briefly described in the figure below.

1. Mapping business processes to SAP business applications This phase is the delicate precondition for any sizing. The custom business processes must be mapped to the appropriate SAP software product. This joint effort of customer and implementation partner takes place at a business or management level, possibly in a face-to-face discussion between the customer and an expert in SAP business application who translates the customer's requirements into a business implementation proposal. There are a number of services to translate your custom business processes into SAP processes, such as business maps and solution maps. For more information on these tools see http://service.sap.com/bmet.

2. Translating business requirements into high-level technical requirements The task here is to find out, which processes are critical to achieve the required throughput, with the methods described in this paper. The Quick Sizer or other sizing methodologies provide hardware-independent resource requirements. It is the task of SAP to provide these basic sizing guidelines and hardware independency is a fundamental principle.

3. Implementing actual servers and infrastructure It is the task of the hardware vendor to translate the hardware independent requirements into actual system configurations and possible landscapes. This includes, for example, the decision whether two applications can run on the same hardware, whether you would use large or small configurations, fail-over and other strategies. One of the reasons why SAP only delivers hardware independent hardware estimates if, for example, that customers and hardware partners may choose to employ one large application server or many small ones. Both configurations can do the same job, but SAP cannot predict the possible outcome.

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 26

Page 26: Background Sizing 1 1

(Fig. 9) Conducting Customer Performance Tests

5 Conclusion The scalability of the multi-tier Internet architecture is the prerequisite for all sizing models. These sizing models are based on queuing theory. Because of the scalability of all components, even a simple queuing model achieves excellent results.

SAP Standard Application Benchmarks help to determine input parameters for the queuing model and to check and prove the scalability of a given hardware configuration. The results of the benchmarks as well as feedback from productive systems are used to create sizing guidelines that help customers to predict hardware requirements based on business volume data.

In the Quick Sizer, an Internet based tool developed in close cooperation with SAP's hardware partners, two sizing approaches have been implemented: User-based and throughput-based sizing. The Quick Sizer calculates ranges for CPU, disk and memory resource requirements. The data entered is always available on-line and can be used for the system installation or sizing verifications during the implementation project. Sizing and configuration forecasts can only be valid, if basic assumptions hold like a well-tuned and implemented system, proactive and experienced system administration, well-trained users and continuous system performance analysis.

SAP offers various utilities and services during all phases of the system life cycle to ensure that these prerequisites for a well performing system are met, such as GoingLive or technical capacity management services.

As hardware architectures on the one hand and hardware and software virtualization methods are becoming increasingly powerful, the sizing process becomes easier, as only thresholds have to be looked at with more care, namely the point in time when peak processing requires availability of the hardware.

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 27

Page 27: Background Sizing 1 1

6 Appendix

6.1 Quoted Benchmark Results

The table below contains the benchmark results quoted.

For more details see http://www.sap.com/benchmark.

6.2 Literature

Bolch G. et al.

Queueing Networks and Markov Chains. Modeling and Performance Evaluation with Computer Science Applications. John Whiley, New York. 1998

Haas, M. & Zorn, W.

Methodische Leistungsanalyse von Rechensystemen. Reihe: Handbuch der Informatik 2.6, Oldenbourg, München, Wien. 1995

Janssen, S. & Marquard, U.

"Conducting Custom Performance Tests", SAP Professional Journal, 5/2000

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 28

Page 28: Background Sizing 1 1

Internet Resources www.sap.com/benchmark for more information on benchmark results and the benchmarking

procedure

SAP Service Marketplace /quicksizing Quick Sizer Using the Quick Sizer: "Using the Quick Sizer"

sdn.sap.com/weblogs

o Quick Sizer overview and usage

6.3 Feedback

Please send comments and feedback on this document to Susanne Janssen: Email: [email protected]

© SAP AG Sizing SAP Solutions - SAP Customers and Partners 29