Sizing SAP Systems

Susanne Janssen, Ulrich Marquard

Contents 1 Introduction
................................................. 3 3 3 4 4 5 5 7 7 8 8 10 10 11 11 12 13 13 14 15 15 15 17 17 18 20 20 21

Basic Considerations and Assumptions for Throughput Sizing ............................ 23 Advantages and Disadvantages of Throughput Sizing ............................. 23 Sizing by Reference Installations ........... 23 Sizing by Load Tests ............................... Conclusion ............................................. 3.4 User and Throughput Sizing Models ................. Calculating CPU Requirements ............. Calculating Memory Requirements ....... Calculating Disk Requirements .............. Frontend Network Requirements ......... Conclusion for These Approaches ......... 3.5 Conclusion ........................................................
24 24 24 24 25 26 27 27 27 29

Sizing Denition .................................... The Sizing Principle ................................ Business Management and Technology Goals of This Book ................................. Target Group and Structure of the Book ....................................................... Related Topics ........................................

Sizing Methods

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

2.1 Phases of Sizing Projects ................................... 2.2 Methods for Initial Sizings ................................ Hardware Budget Sizings ....................... Advanced Sizing ..................................... Expert Sizing .......................................... Standard Tools Even for Experts ....... Analyzing Customer Data ...................... 2.3 Sizings Based on Productive Customer Data .... Basic Analysis for All Production Sizings .................................................... Resizing .................................................. Delta Sizing ............................................ Upgrade Sizing ....................................... Single-Instance Projects ......................... 2.4 Summary ...........................................................

Sizing Tools

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

4.1 Rule of Thumb/Reality Check ........................... 29 Bottom-Up Method .............................. 30 Top-Down Method ................................ 30 4.2 T-shirt Sizing ...................................................... 30 Categories .............................................. Pros and Cons ........................................ 4.3 Sizing Formula ................................................... 4.4 Ofine Questionnaire ....................................... 4.5 Summary ...........................................................
31 31 32 33 33 35 36 36 37

Sizing Approaches

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

Quick Sizer

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

3.1 Factors That Inuence Sizing ............................ 3.2 Key Performance Indicators .............................. 3.3 Overview of Different Sizing Approaches ....................................................... Sizing by Users ....................................... Advantages and Disadvantages of User-Based Sizing ..................................

5.1 Quick Sizer Projects .......................................... Creating a Project .................................. Filling Out Sizing Questionnaires ..........

Determining the Sizing Result ............... 38 5.2 Functions ........................................................... 40 Initial Page ............................................. Navigation Tree ...................................... Header Bar .............................................
www.sap-press.com

41 41 41

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

Contents

Questionnaires ....................................... Results Page ...........................................

43 45

Step 5: Acquire Information and Apply the Methods .......................................... Step 6: Analyze First Results and Adapt the Methods .......................................... 77 Step 7: Consolidate the Results and Get Conrmation from Stakeholders .... 77 8.4 Summary ...........................................................
78 79 76

5.3 Average and Peak Sizing .................................... 48 5.4 Summary ........................................................... 50

Performance Monitors and Traces

......

51 52 53

6.1 Operating System Monitor ............................... 6.2 Database Monitor .............................................

6.3 Application Monitor .......................................... 54 6.4 Single Record Statistics .................................... 56 6.5 Performance Trace .............................................
57

Sizing Details

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

9.1 Basic Foundations of the SAP Sizing Model ................................................................ 79 SAP Software Architecture .................... 79 Application Services and Database Services .................................................. 80 Modeling CPU Consumption ................ Allocating Sufcient Memory (or: Modeling Physical Memory) ........... 84 Allocating Sufcient 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 81

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

Sizing Verication

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

59 59 59

7.1 Load Tests .......................................................... Phase 0: Preparation .............................. Phase 1: Performing Individual

Measurements ....................................... 60 Phase 2: Analyzing the Transaction Design in Single Mode .......................... 60 Phase 3: Load Tests in Multi-User Mode .....................................................
61

7.2 Verication via Support Services ....................... 63 SAP GoingLive Check ............................ 63 SAP EarlyWatch Check .......................... 67 SAP GoingLive Functional Upgrade Check ..................................................... 68 7.3 Summary ...........................................................
69 71 71 71 71

9.3 Performing Sizing Measurements ..................... 94 Step 1: Dene 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

Executing Sizing Projects

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

8.1 Before the Sizing Project Begins ....................... Chicken or the Egg? ............................... Project Scope .........................................

Stakeholders in a Sizing Project ............. 72 Denition of a Sizing Project ................. 72 8.2 Project Team ...................................................... 73 8.3 Methodical Procedure ...................................... Step 1: Dene Project Contents and Goals ...................................................... Step 2: Determine Performance-Critical Processes ................................................ Step 3: Decide on the Approaches and Methods to Be Used .............................. Step 4: Dene Milestones and Prepare a Detailed Schedule ...............................
76 75 75 74 74

10 Summary and Outlook A

............................ 101 ................. 103

Frequently Asked Questions

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

Literature and Links Index

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

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

Galileo Press 2007. All rights reserved.

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 methods and, consequently, using different tools. This chapter focuses on these different methods.

sizing). Moreover, we are using several custom developments. How should we carry out a sizing project? This question refers to a specic 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 addition, 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 singleinstance concepts, which are used to check whether all systems can be globally integrated with one database, 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 specic 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 ultimately get to the different phases in which you can perform 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.1

Phases of Sizing Projects

SAP regularly receives information requests like the following: We are a large customer in the consumer goods industry 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 rst estimate. The question itself does not indicate why this is a large customer. Perhaps the customer is only looking for a partial solution since the volumes mentioned indicate that this customer is a large medium-sized company. The business partners represent master data and are not yet relevant to sizing because they do not generate any load during live operation. In contrast, the sales orders and sales order items are much more critical to CPU sizing since they represent transaction 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 cant nd any guidelines for the FIN-FSCM-TRN component in your sizing area (http://service.sap.com/

www.sap-press.com

2 Sizing Methods

Phase Orientation phase (Phase A)

Point in Time 18 to 12 months prior to GoLive

Description 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 specic releases. The rst business blueprints have been created, and now you need reliable information on the scope of hardware you have to order because you must make sure you meet all your deadlines. You know how to implement the relevant processes, have become more familiar with SAP products and SAP terminology, and know which release you want to use. 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. The system is operational and is supposed to be consolidated. Region 1, for instance, has gone live with a specic software, and Region 2 is now supposed to go live on the same system. The system is operational and you want to add new functions. For example, your live system runs the SAP ERP applications, and you want to add CRM applications now. 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.

Blueprint phase (Phase B)

12 to 6 months prior to GoLive

Implementation phase (Phase C) Consolidation phase (Phase D) Extension phase (Phase E) Upgrade phase (Phase F)

6 to 0 months prior to GoLive System is operational System is operational System is operational

Table 2.1 Phases in Which Sizing Can Be Performed

the software, you will probably have only basic information 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 rene your initial assumptions by using standard sizing rules in order to take a closer look at the critical issues. If an installations complexity differs too much from the standard, you can, for instance, measure customer processes in order to create customer-specic sizings. All these different phases require different sizing methods. In this context, we generally distinguish between initial and production sizings. Figure 2.1 provides an overview of the available sizing methods, with initial sizings being shown in the upper section and production sizings 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-specic 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 rst time. That is also the case if, for instance, you want to use SAP SRM for the rst time while SAP ERP is already running in your companys production system at least the sizing for SAP SRM will be considered as being initial. Depending on the project phases, we differentiate initial 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 additional rules or measurements. Hardware Budget Sizings The main characteristic of budget sizings is that they dont 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-

Galileo Press 2007. All rights reserved.

2.2 Methods for Initial Sizings

Hardware Budget Sizing

Smaller Companies Very simple algorithms Assumptions, likelihoods Level setting of project Risk identification

Advanced Sizing
Medium to Large Companies Throughput estimates Questionnaires, formulas Usage of standard tools Focus on core business processes

Expert Sizing
Large/Complex Projects Additional guidelines Custom calculations Analysis of custom coding Custom sizing guidelines

GoLive

Initial Sizings

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

Delta Sizing
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)

Upgrade Sizing
All Projects SAP system monitors SAP Notes Goal: Upgrade SAP software

Post GoLive Sizings

Figure 2.1 Overview of Sizing Approaches and Methods
1

mation you have is that 100 users will use SAP CRM, but you dont know the other applications they will use and what will be their average activity, you can certainly perform 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 SAPs 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 disadvantage is that the rough categorization into S through XL provides only limited informational value. Occasionally, such sizings can be sufcient, depending on the specic situation. For this reason, it makes a lot of sense to compare the time and effort you want to invest into a sizing project with the potential hardware costs.

Budget Sizings Help in Estimating the Entire Size Lets 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 sizing 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 during 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 hardware. In this case, the question is whether you can afford to use the wrong assumptions. Lets suppose your initial estimate is wrong by 100%. You
1 See Section 9.2, SAP Application Performance Standard, for a more detailed description of SAPS.

www.sap-press.com

2 Sizing Methods

would then have to pay (in the above example) an additional $15,000 $20,000 for a correspondingly bigger server. There are some customers for whom expenses in this range are critical, since the implementation of a new production server also involves the purchase of new quality assurance systems and testing landscapes.

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 Years). Especially with regard to background-oriented processes such as those relevant to controlling or year-end settlements, this information is critical and cannot be taken care

Advanced Sizing If youre in a situation in which theres a high risk of misjudging the requirements by several 100 percents, you should rene your budget sizing by using what is referred to as advanced sizing. For example, if the range of CPU power youre dealing with is between 8 and 16 cores, a more detailed sizing makes a lot of sense because it provides a higher degree of reliability. To do that, you can use additional functions of Quick Sizer, such as its throughput-based functionality, which allows you to determine the CPU load on average as well as by peak load (see Section 5.3, Average and Peak Sizing). Usually, advanced sizing occurs in phases B and C. In these phases, the rst business blueprints have already been created so that important and sizing-relevant information about the business software applications is available to you. This information could include, for instance, a PC vendors decision about which important materials 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 ne-tune the CPU sizing in that it distinguishes between the average CPU utilization (average sizing) and the utilization at peak times (peak sizing): 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

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 category 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 recommends 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 business transactions, in-house developments, and largescale 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 dened by their size, are also eligible candidates 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:

10

Galileo Press 2007. All rights reserved.

2.2 Methods for Initial Sizings

Identied all processes that are critical for performance. Used standard tools for the core processes. Determined the performance-critical areas in which your processes deviate from the standard. Expert sizings are performed just before the system GoLive, that is, when the functionality has been clearly dened and perhaps even been implemented. In most cases, expert sizing represents an iteration on a previously performed budget or advanced sizing so that you can use the data of these previous processes as a basis and simplify it, if necessary. 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 Sizers) so that they meet specic 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 identied 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 ows from the point of view of sizing. For example, if you use overlapping, performance-critical process chains, you can use the 24-hour load prole 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.

Simplied Example of Expert Sizing A company uses SAP CRM applications to enter sales orders and uses SAP ERP for sales order fulllment 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 interface does not negatively affect the performance of the ERP system (on the contrary, it has, rather, a positive effect because there is no user interaction). 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 processing will be, it performs performance measurements 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 specic customer processes. Typical cases in which it makes sense to analyze the performance gures on the basis of custom data because of the strong inherent customer-specic nature include the following:

www.sap-press.com

11

2 Sizing Methods

Variant conguration 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 performed (i.e., when business processes can be functionally mapped in a system), you use the standard performance monitors of the SAP system to measure the CPU time, memory consumption, or database 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 dening an appropriate test case to applying the customer-specic sizing rule. Chapter 6, Performance Monitors and Traces, contains detailed information on sizing-based performance measurements.
Step 1 2 3 4 5 6 Description Dene test case Identify test system Create test case in test system Measure sizing KPIs Implement measurement results in sizing method Apply sizing rule

Sizing Measurement Versus Performance Analysis Note that sizing measurements reect only the actual status. Based on sizing measurements, you can determine whether a business transaction is scalable. In this context, scalability means that the resource consumption 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 performance subproject.

The advantages of expert sizing over other sizing methods are found in the higher degree of accuracy and reliability of the information. If you manage a sizing project for a complex or large customer, you should denitely consider aspects from expert sizing, even though the collection 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 examples will show: You want to consolidate your existing system landscape (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.

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 sufcient 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 sizing tool. On the other hand, you can use them to verify sizing results. Because customers usually use them to verify sizing results, you can nd detailed information on them in Section 7.1, Load Tests.

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 system is that you can use your own data and settings as a basis. In other words, you do not need to rely on assumptions 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

12

Galileo Press 2007. All rights reserved.

2.3 Sizings Based on Productive Customer Data

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 rst analyze the status of the existing system before you can plan the new hardware requirements. Production System Sizings Versus Quick Sizer The unbeatable advantage of sizing on the basis of production data is that you can take your own data, processes, and settings into account. Quick Sizer has been designed for new installations and contains assumptions 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 rst identify the utilization of the sizing-relevant components in the existing 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 regarding 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 requirements using the various vendor-specic monitors or the SAP monitors, you should relate this information to a simple business key gure. Usually this is the users, but

it can also be projects or calls. Alternatively, you can also use the number of activities or sales orders, depending, on the one hand, on which unit is best suited to reect 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 description of individual sizing methods. A customer uses strategic procurement in the SRM environment. The analysis of the current utilization provides the following 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 analyzed. Based on this information, you can now determine whether the existing hardware is sufcient or whether it must be extended. Resizing A basic prerequisite for resizing is that only the throughput and user volumes can change, but not the functionality. Based on the current load situation and the new information, you can easily determine future requirements 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, Sample Analysis of a Production System), a resizing could look as follows: You want to add another 200 named users to the 1,567 existing ones. We assume that the ratio between named users and active users is identical

www.sap-press.com

13

2 Sizing Methods

among the new users and that they will do the same as the existing users, so that we can make the following calculations: Active Users The ratio between 200 and 1,567 is 12%, which means that the number of active users will probably increase by 12%. CPU Database Server 34% + 12% corresponds to 34% 1.12 = 38.1% A utilization of 38% is sufcient for a database server. Many customers plan a target utilization of 25% to 50% for the database server. CPU Application Server 56% + 12% corresponds to 56% 1.12 = 62.7% The application servers can absorb a utilization of 62.7% quite well. However, many customers plan a target utilization of 30% to 50% for the application servers, which is why an extension is at least 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.

value, which can be specied 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 sufcient by using a rule of three. Delta Sizing of a Production System The above customer (see previous box, Resizing a Production System) has created a sizing for a new application. According to the sizing, the application will require 1,200 SAPS (240 database SAPS and 960 application SAPS). What needs to be done now is easy: The SAPS values must be added up, and the target utilization must be determined. The existing hardware is evaluated as follows: Database server: 4,000 SAPS; the two applications: 2,800 SAPS each The current net SAPS consumption for the database 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 utilization of 65% and you should therefore only use net amounts. However, you should also take into account that the delta is based on standard assumptions as

Delta Sizing 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 SAPs standard sizing rules specify the CPU requirements in terms of SAPS and a target utilization of 65%. As we will demonstrate in Section 9.2, SAP Application Performance Standard, each hardware conguration in the SAP environment has its own SAPS

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.

14

Galileo Press 2007. All rights reserved.

2.4 Summary

Upgrade Sizing In upgrade projects, customers usually implement numerous changes, which include the SAP software, database, operating system, and an exchange of hardware. It often happens that the conguration and parameter settings are changed as well. All this can have an impact on the number 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 requirements, memory requirements, and database space. Because these SAP Notes provide standardized information about different transactions, they carry the risk of you currently using a transaction that is counterbalanced by other transactions. Sample Upgrade Sizing A (ctitious) SAP Note on delta resource consumption states that the resource consumption in the memory increases by 5% on average. Transactions A and F do not show any additional consumption, whereas Transaction 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 calculating the main memory. The best thing to do is to calculate 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.

Single-Instance Projects From the point of view of sizing, the majority of singleinstance projects in which companies change from a bestof-breed strategy2 to a single-instance strategy (one software vendor, all data in one system) represent a mixture of resizing and delta sizing, sometimes also upgrade sizing. Note that an upgrade sizing must be performed rst to make sure that identical conditions apply. Considerations in the Context of a Single-Instance Study A customer uses several SAP and legacy systems in Europe. This customer now wants to consolidate its European and American systems. Consequently, this means the following: If the SAP software has different release versions, an upgrade sizing must be performed rst. The relevant 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 current consumptions of existing SAP systems must be analyzed and totaled. Finally, a delta sizing must be performed for the legacy software. Ultimately, the additional requirements for the new software are added to the existing load.

2.4 Summary
Because SAP software shows a high degree of scalability, 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 specic production model. However, a new application server affects the databases memory requirements because it involves the addition of new database users. A higher volume generally 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 product from the best vendor for each (technological) area. The different products are then connected with each other via interfaces.

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, Verication via Support Services). The SAP GoingLive Functional Upgrade Check includes a sizing process.

www.sap-press.com

15

2 Sizing Methods

The sizing method used essentially depends on the initial position youre 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 (Chapter 3), describes how you can convert user-based and throughput-based sizings into algorithms, and discusses the pros and cons of different sizing approaches.

16

Galileo Press 2007. All rights reserved.

Index

2-tier implementation 47 3-tier implementation 47 80/20 rule 35

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

Extension phase 8

F
Frontend network 19, 21, 57

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

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

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

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

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

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

E
Employee Self-Services 75 Evaluation phase 74 EWC SAP EarlyWatch Check (EWC) Expert sizing 10, 29, 51, 76 Expressiveness of sizing project 7

J
Java-based application 25, 47 Java Virtual Machine (JVM) 57

www.sap-press.com

107

Index

K
Key performance indicator 12, 17, 31

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

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

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

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

M
Master data sizing 22, 26 Maximum Extended Memory in Transaction 57 Memory consumption 13 Memory requirement 40, 52, 56, 57 Methods 7 Minimum requirement 5

R
Reference database 23 reference installations 23 Residence time 19, 27 Resizing 12, 13, 63 Resource consumption 15, 24 Rule of thumb 29

N
Named user 20 Network load 19 Network traffic 32 Non-disclosure policy 23

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

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

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

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

108 Galileo Press 2007. All rights reserved.

Index

Transaction ST05 57 Transaction ST06 52 Transaction ST07 54 Transaction STAD 56

active 21 concurrent 21 interaction step 52, 57 logged-on 21 named 20 User-based sizing 20, 38 User interaction step 57

of sizings 59, 63

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

U
Upgrade phase 8 Upgrade sizing 13, 15, 63, 67, 75 Usage type 47 User

V
Verification 77

www.sap-press.com

109