Sizing Methods of SAP System

4,309 views
3,992 views

Published on

Sizing Methods of SAP System

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
4,309
On SlideShare
0
From Embeds
0
Number of Embeds
109
Actions
Shares
0
Downloads
181
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Sizing Methods of SAP System

  1. 1. www.sap-press.com 1 Sizing SAP® Systems Susanne Janssen, Ulrich Marquard Contents 1 Introduction ................................................. 3 Sizing Definition .................................... 3 The Sizing Principle ................................ 3 Business Management and Technology 4 Goals of This Book ................................. 4 Target Group and Structure of the Book ....................................................... 5 Related Topics ........................................ 5 2 Sizing Methods ........................................... 7 2.1 Phases of Sizing Projects ................................... 7 2.2 Methods for Initial Sizings ................................ 8 Hardware Budget Sizings ....................... 8 Advanced Sizing ..................................... 10 Expert Sizing .......................................... 10 Standard Tools — Even for Experts ....... 11 Analyzing Customer Data ...................... 11 2.3 Sizings Based on Productive Customer Data .... 12 Basic Analysis for All Production Sizings .................................................... 13 Resizing .................................................. 13 Delta Sizing ............................................ 14 Upgrade Sizing ....................................... 15 Single-Instance Projects ......................... 15 2.4 Summary ........................................................... 15 3 Sizing Approaches ..................................... 17 3.1 Factors That Influence Sizing ............................ 17 3.2 Key Performance Indicators .............................. 18 3.3 Overview of Different Sizing Approaches ....................................................... 20 Sizing by Users ....................................... 20 Advantages and Disadvantages of User-Based Sizing .................................. 21 Sizing by Throughput ............................. 22 Basic Considerations and Assumptions for Throughput Sizing ............................ 23 Advantages and Disadvantages of Throughput Sizing ............................. 23 Sizing by Reference Installations ........... 23 Sizing by Load Tests ............................... 24 Conclusion ............................................. 24 3.4 User and Throughput Sizing Models ................. 24 Calculating CPU Requirements ............. 24 Calculating Memory Requirements ....... 25 Calculating Disk Requirements .............. 26 Frontend Network Requirements ......... 27 Conclusion for These Approaches ......... 27 3.5 Conclusion ........................................................ 27 4 Sizing Tools ................................................... 29 4.1 Rule of Thumb/Reality Check ........................... 29 Bottom-Up Method .............................. 30 Top-Down Method ................................ 30 4.2 T-shirt Sizing ...................................................... 30 Categories .............................................. 31 Pros and Cons ........................................ 31 4.3 Sizing Formula ................................................... 32 4.4 Offline Questionnaire ....................................... 33 4.5 Summary ........................................................... 33 5 Quick Sizer ................................................... 35 5.1 Quick Sizer Projects .......................................... 36 Creating a Project .................................. 36 Filling Out Sizing Questionnaires .......... 37 Determining the Sizing Result ............... 38 5.2 Functions ........................................................... 40 Initial Page ............................................. 41 Navigation Tree ...................................... 41 Header Bar ............................................. 41
  2. 2. 2 ©Galileo Press 2007. All rights reserved. Contents Questionnaires ....................................... 43 Results Page ........................................... 45 5.3 Average and Peak Sizing .................................... 48 5.4 Summary ........................................................... 50 6 Performance Monitors and Traces ...... 51 6.1 Operating System Monitor ............................... 52 6.2 Database Monitor ............................................. 53 6.3 Application Monitor .......................................... 54 6.4 Single Record Statistics .................................... 56 6.5 Performance Trace ............................................. 57 6.6 Summary ........................................................... 58 7 Sizing Verification ...................................... 59 7.1 Load Tests .......................................................... 59 Phase 0: Preparation .............................. 59 Phase 1: Performing Individual Measurements ....................................... 60 Phase 2: Analyzing the Transaction Design in Single Mode .......................... 60 Phase 3: Load Tests in Multi-User Mode ..................................................... 61 7.2 Verification via Support Services ....................... 63 SAP GoingLive Check ............................ 63 SAP EarlyWatch Check .......................... 67 SAP GoingLive Functional Upgrade Check ..................................................... 68 7.3 Summary ........................................................... 69 8 Executing Sizing Projects ........................ 71 8.1 Before the Sizing Project Begins ....................... 71 Chicken or the Egg? ............................... 71 Project Scope ......................................... 71 Stakeholders in a Sizing Project ............. 72 Definition of a Sizing Project ................. 72 8.2 Project Team ...................................................... 73 8.3 Methodical Procedure ...................................... 74 Step 1: Define Project Contents and Goals ...................................................... 74 Step 2: Determine Performance-Critical Processes ................................................ 75 Step 3: Decide on the Approaches and Methods to Be Used .............................. 75 Step 4: Define Milestones and Prepare a Detailed Schedule ............................... 76 Step 5: Acquire Information and Apply the Methods .......................................... 76 Step 6: Analyze First Results and Adapt the Methods .......................................... 77 Step 7: Consolidate the Results and Get Confirmation from Stakeholders .... 77 8.4 Summary ........................................................... 78 9 Sizing Details ............................................... 79 9.1 Basic Foundations of the SAP Sizing Model ................................................................ 79 SAP Software Architecture .................... 79 Application Services and Database Services .................................................. 80 Modeling CPU Consumption ................ 81 Allocating Sufficient Memory (or: Modeling Physical Memory) ........... 84 Allocating Sufficient Disk I/O Capabilities (or: Modeling Disk I/O Requirements) ....................................... 86 Modeling Network Bandwidth .............. 86 Measuring Resource Consumption ....... 88 Benchmark Results ................................ 88 Results from a Java Benchmark ............. 90 9.2 SAP Application Performance Standard ............ 92 9.3 Performing Sizing Measurements ..................... 94 Step 1: Define the Test Case ................. 94 Step 2: Identify the Test System ............ 95 Step 3: Create the Test Case in the Test System ............................................ 95 Step 4: Measure the Sizing KPIs ............ 96 Step 5: Create Sizing Guidelines Based on the Measurements ........................... 98 9.4 Summary ........................................................... 99 10 Summary and Outlook ............................ 101 A Frequently Asked Questions ................. 103 A.1 Sizing Approaches ............................................. 103 A.2 Quick Sizer ........................................................ 104 A.3 Sizing Projects ................................................... 104 B Literature and Links .................................. 105 Index ............................................................... 107
  3. 3. www.sap-press.com 7 2 Sizing Methods Sizing projects are carried out at very different stages of an SAP project. They represent an iterative process that depends closely on the amount of information that is available to you at a certain point in time to make reliable statements on the actual hardware requirements. Accordingly, in each sizing project, you will often face new situations that you must react to with different meth- ods and, consequently, using different tools. This chapter focuses on these different methods. 2.1 Phases of Sizing Projects SAP regularly receives information requests like the fol- lowing: “We are a large customer in the consumer goods indus- try with 30,000 business partners and 60,000 sales orders containing 50 line items per month. How much hardware do we need for our SAP application?” This is a rather general question. The customer needs information about hardware for a first estimate. The question itself does not indicate why this is a large customer. Perhaps the customer is only looking for a partial solution since the volumes mentioned indicate that this customer is a large medium-sized company. The business partners represent master data and are not yet relevant to sizing because they do not gener- ate any load during live operation. In contrast, the sales orders and sales order items are much more critical to CPU sizing since they represent transac- tion data. In terms of revenue, an average of 2,000 sales orders per day is quite considerable; however, from the point of view of software, this is not a high throughput volume. SAP has several customers who process more than a million sales order items per day. “We can’t find any guidelines for the FIN-FSCM-TRN component in your sizing area (http://service.sap.com/ ̈ ̈ sizing). Moreover, we are using several custom develop- ments. How should we carry out a sizing project?” This question refers to a specific component in accounting and is therefore more detailed. Perhaps this customer has already carried out sizing projects for other SAP applications and wants to perform another one for this particular application. In addi- tion, the customer wants to know how sizing can be done for proprietary developments. “We are planning to consolidate our seven data centers into one. Can we simply add up existing sizings?” This question (which comes from an existing SAP customer) refers to a system consolidation process in which additional hardware requirements must be taken into account if the different existing systems are combined. System consolidation and single- instance concepts, which are used to check whether all systems can be globally integrated with one data- base, are currently red-hot issues with our customers. “We are currently running Release SAP R/3 4.6C and want to upgrade to SAP ERP 6.0. What are the upgrade factors?” This customer uses a specific release that he wants to upgrade across multiple releases in one step and therefore wants to know if new hardware needs to be purchased for that. By further analyzing these kinds of requests, we ulti- mately get to the different phases in which you can per- form sizing projects (see Table 2.1). The informational value of the sizing project can vary, depending on the different phases. In addition, you should note that not all the phases described in Table 2.1 have to occur in an SAP project. Thus, if the system GoLive is still way down the road and you — as a customer — are not yet very familiar with ̈ ̈
  4. 4. 8 ©Galileo Press 2007. All rights reserved. 2 Sizing Methods the software, you will probably have only basic informa- tion on how you are going to use it so that you can at least make a rough estimate of the costs involved. During the course of the implementation project, you can refine your initial assumptions by using standard sizing rules in order to take a closer look at the critical issues. If an installation’s complexity differs too much from the standard, you can, for instance, measure customer processes in order to create customer-specific sizings. All these different phases require different sizing meth- ods. In this context, we generally distinguish between ini- tial and production sizings. Figure 2.1 provides an over- view of the available sizing methods, with initial sizings being shown in the upper section and production siz- ings in the lower one. Expert sizing is marked as a hybrid because under certain circumstances, some processes can be mapped using standard methods while, at the same time, customer-specific data can be analyzed. The following sections describe the characteristics of these different sizings in greater detail. At this point it is important to know that sizings can be performed within several phases of a project: Sizing is an iterative process. Budget sizing, for example, could be done in phases A and B, advanced sizings in phases A through C, expert siz- ings in phases B and C, resizings in phase D, delta sizings in phase E, and upgrade sizings in phase F. 2.2 Methods for Initial Sizings Initial sizings are sizings that refer to new installations, that is, installations in which you use SAP software for the first time. That is also the case if, for instance, you want to use SAP SRM for the first time while SAP ERP is already running in your company’s production system — at least the sizing for SAP SRM will be considered as being initial. Depending on the project phases, we differentiate ini- tial sizings into hardware budget sizings (budget sizings for short), advanced sizings, and expert sizings. Usually, budget sizings and advanced sizings are based on tools, whereas expert sizings are a mixture of tools and addi- tional rules or measurements. Hardware Budget Sizings The main characteristic of budget sizings is that they don’t require much information from the customer and they contain many assumptions (i.e., values provided by SAP based on experience). For example, if the only infor- Phase Point in Time Description Orientation phase (Phase A) 18 to 12 months prior to GoLive You familiarize yourself with the software functionality and want to know what the range of expenses is for the new hardware. Accordingly, you will certainly know which processes you want to map using the software, and you also know the approximate amount of data that is supposed to be processed. However, you are not familiar with the SAP jargon, nor are you interested in specific releases. Blueprint phase (Phase B) 12 to 6 months prior to GoLive The first business blueprints have been created, and now you need reliable information on the scope of hardware you have to order because you must make sure you meet all your deadlines. You know how to implement the relevant processes, have become more familiar with SAP products and SAP terminology, and know which release you want to use. Implementation phase (Phase C) 6 to 0 months prior to GoLive You have ordered the hardware or are just about to do so, and you want to be absolutely sure that sizing is correct. For example, you are able to measure core processes using the performance monitors. Consolidation phase (Phase D) System is operational The system is operational and is supposed to be consolidated. Region 1, for instance, has gone live with a specific software, and Region 2 is now supposed to go live on the same system. Extension phase (Phase E) System is operational The system is operational and you want to add new functions. For example, your live sys- tem runs the SAP ERP applications, and you want to add CRM applications now. Upgrade phase (Phase F) System is operational The system is operational and you want to perform an upgrade. For example, the system runs on SAP R/3 Enterprise and you want to upgrade it to SAP ERP 6.0. Table 2.1 Phases in Which Sizing Can Be Performed
  5. 5. www.sap-press.com 9 mation you have is that 100 users will use SAP CRM, but you don’t know the other applications they will use and what will be their average activity, you can certainly per- form the sizing, but in the long run, the informational value provided by the result of the sizing process will be too restricted. For this reason, budget sizings are usually performed way ahead of the GoLive phase (most of the time in Phase A) if the goal is to estimate the approximate scope of hardware. For budget sizings, you can use the user-based sizing function in SAP’s Quick Sizer (see Chapter 5, Quick Sizer). Alternatively, you can use T-shirt sizings (see Section 4.2, T-shirt Sizing), which have the advantage of requiring you to answer only a few questions. Of course, the disadvan- tage is that the rough categorization into S through XL provides only limited informational value. Occasionally, such sizings can be sufficient, depending on the specific situation. For this reason, it makes a lot of sense to compare the time and effort you want to invest into a sizing project with the potential hardware costs. Hardware Budget Sizing Advanced Sizing Expert Sizing Smaller Companies ̈ Very simple algorithms ̈ Assumptions, likelihoods ̈ Level setting of project ̈ Risk identification Medium to Large Companies ̈ Throughput estimates ̈ Questionnaires, formulas ̈ Usage of standard tools ̈ Focus on core business processes Large/Complex Projects ̈ Additional guidelines ̈ Custom calculations ̈ Analysis of custom coding ̈ Custom sizing guidelines Resizing Delta Sizing Upgrade Sizing All Projects All Projects ̈ SAP system monitors ̈ Goal: Extend an existing system by functions (by different functions, e.g., you are live with CRM and want to add SCM) All Projects ̈ SAP system monitors ̈ SAP Notes ̈ Goal: Upgrade SAP software Go- Live Initial Sizings Post GoLive Sizings ̈ 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) Figure 2.1 Overview of Sizing Approaches and Methods Budget Sizings Help in Estimating the Entire Size Let’s suppose a budget sizing determines 4,000 SAPS (SAP Application Performance Standard1 ). Currently, 4,000 SAPS correspond more or less to a dual-core machine (server) with two processors, which has a list price of $15,000. Now you can make up your mind whether it makes sense to tackle a rather intensive siz- ing process or whether you want to take one of the following two risks: Result Is Too High This means the server will not be fully utilized dur- ing live operations. A result that is too high often occurs because the initial estimates are usually too conservative. Result Is Too Low This means that you must buy additional hard- ware. In this case, the question is whether you can afford to use the wrong assumptions. Let’s sup- pose your initial estimate is wrong by 100%. You ̈ ̈ 2.2 Methods for Initial Sizings 1 1 See Section 9.2, SAP Application Performance Standard, for a more detailed description of SAPS.
  6. 6. 10 ©Galileo Press 2007. All rights reserved. 2 Sizing Methods Advanced Sizing If you’re in a situation in which there’s a high risk of mis- judging the requirements by several 100 percents, you should refine your budget sizing by using what is referred to as advanced sizing. For example, if the range of CPU power you’re dealing with is between 8 and 16 cores, a more detailed sizing makes a lot of sense because it pro- vides a higher degree of reliability. To do that, you can use additional functions of Quick Sizer, such as its through- put-based functionality, which allows you to determine the CPU load on average as well as by peak load (see Sec- tion 5.3, Average and Peak Sizing). Usually, advanced sizing occurs in phases B and C. In these phases, the first business blueprints have already been created so that important and sizing-relevant infor- mation about the business software applications is avail- able to you. This information could include, for instance, a PC vendor’s decision about which important materi- als are imperative that an availability check be performed for (processors, for example). An availability check locks an object and can become a performance bottleneck because all other requests have to wait until the object is released again. Thus, in an advanced sizing process, you focus more on the core business processes. Quick Sizer is able to map the key processes of the SAP Business Suite and tries to break down the complex business scenarios into the most important transactions and objects. In addition, Quick Sizer provides the option to fine-tune the CPU sizing in that it distinguishes between the average CPU utilization (average sizing) and the utilization at peak times (peak siz- ing): For processor requirements, you can perform an average sizing in such a way that you specify the number of objects that are processed per year as well ̈ as the size of these objects. If you have times of peak load, you can, of course, specify them. Throughput-based sizing enables you to determine in greater detail in which areas and at what time the CPU peak load occurs (for example, in the week before Christmas or New Year’s). Especially with regard to background-oriented processes such as those relevant to controlling or year-end settlements, this information is critical and cannot be taken care of by user-based sizing. The drawback of advanced sizing is that you have to familiarize yourself with the core business processes in order to obtain the appropriate information from the user departments for the Quick Sizer questionnaire. This certainly takes more time than asking for the number of users (as is done, for instance, in a budget sizing process), but it is much more accurate. Note that advanced sizing is still a tool-based process. An “XL” category in Quick Sizer represents a large cat- egory in the tool-controlled area, but not necessarily in the entire sizing context. For example, in Quick Sizer, the largest category (“XXL”) starts at 30,000 SAPS. A number of large customers operate on 40,000 to 100,000 SAPS; a few other customers operate in the range of 300,000 SAPS and higher. Expert Sizing For ranges of 30,000 SAPS and higher, SAP therefore rec- ommends that its customers not rely exclusively on one sizing tool but rather that they analyze the core processes and, above all, the customer processes in great detail via expert sizing. This method is particularly suited for complex busi- ness transactions, in-house developments, and large- scale installations. Complex business transactions may also occur in smaller installations, such as in the supply chain or in retailing systems. Global installations, which are not only defined by their size, are also eligible can- didates for expert sizing because of the time differences that must be taken into account. To be able to perform an expert sizing process, you must have: ̈ would then have to pay (in the above example) an additional $15,000–$20,000 for a correspond- ingly bigger server. There are some customers for whom expenses in this range are critical, since the implementation of a new production server also involves the purchase of new quality assurance systems and testing landscapes.
  7. 7. www.sap-press.com 11 Identified all processes that are critical for perfor- mance. Used standard tools for the core processes. Determined the performance-critical areas in which your processes deviate from the standard. Expert sizings are performed just before the system GoLive, that is, when the functionality has been clearly defined and perhaps even been implemented. In most cases, expert sizing represents an iteration on a previ- ously performed budget or advanced sizing so that you can use the data of these previous processes as a basis and simplify it, if necessary. Basically, this method consists, on the one hand, of a mixture of standard sizing and performance tools, and on the other, of additional procedures and analyses. We can roughly subdivide these two parts into: The full utilization of the sizing tools’ functionality (in particular, Quick Sizer’s) so that they meet specific requirements at least in part. The analysis and performance monitoring of core processes in the customer system. The following sections provide an overview of how you can use standard tools in expert sizing to obtain useful information, at least about parts of your system. Standard Tools — Even for Experts Whenever you have identified business transactions as being close to the standard, you can use Quick Sizer (see Chapter 5). That is, you can use Quick Sizer for partial sizings. Another option for using Quick Sizer in expert sizing is that you can use it for optimizing process flows from the point of view of sizing. For example, if you use overlap- ping, performance-critical process chains, you can use the 24-hour load profile provided by Quick Sizer to ascertain whether it is possible to perform moves (see also Section 5.3, Average and Peak Sizing). Quick Sizer enables you to map and document additional loads which, for example, have been caused by custom coding. ̈ ̈ ̈ ̈ ̈ Simplified Example of Expert Sizing A company uses SAP CRM applications to enter sales orders and uses SAP ERP for sales order fulfillment and HR. The sales order processing functions in the ERP system have been custom-coded. For this reason, a mixed approach is used in expert sizing in such a way that core processes are mapped through the standard as much as possible, while the other processes are approached step by step: First the company uses Quick Sizer to create a standard sizing for sales order entry in SAP CRM. Because the sales orders that have been entered in the CRM system are further processed in the ERP system, a certain amount of extra capacity is added to the sending system, that is, SAP CRM, according to the corresponding sizing rules. The sizing of SAP ERP is mapped in Quick Sizer on the basis of the total number of orders. The fact that the orders are transferred through an inter- face does not negatively affect the performance of the ERP system (on the contrary, it has, rather, a positive effect because there is no user interac- tion). This sizing represents the basic structure of the ERP sizing. Because the company does not know up front what the impact of extending the sales order pro- cessing will be, it performs performance measure- ments that show that, because of the extension made in the customer system, the same process that was mapped in Quick Sizer now needs more resources. The customer is now able to increase the ERP result for sales order processing by 30% in such a way that the customer multiplies the Quick Sizer result by a factor of 1.3. Other results (for instance, in HR) are not affected by this. ̈ ̈ ̈ ̈ ̈ Analyzing Customer Data One of the most important tasks of expert sizing consists of analyzing specific customer processes. Typical cases in which it makes sense to analyze the performance figures on the basis of custom data because of the strong inher- ent customer-specific nature include the following: 2.2 Methods for Initial Sizings
  8. 8. 12 ©Galileo Press 2007. All rights reserved. 2 Sizing Methods Variant configuration that evaluates complex object dependencies: Its runtime can hardly be anticipated in the standard, if at all. Each custom extension. To analyze customer data, the following two methods are available: single-user analysis and the load test. Single-user Analysis Single-user analysis is based on a relatively simple principle: As soon as integration tests can be per- formed (i.e., when business processes can be func- tionally mapped in a system), you use the standard performance monitors of the SAP system to mea- sure the CPU time, memory consumption, or data- base growth on your hard disk, depending on your requirements. You can then use this data in a rule of three to create the sizing forecast. Table 2.2 provides an overview of the procedure to be applied in a single-user analysis, from defining an appropriate test case to applying the customer-spe- cific sizing rule. Chapter 6, Performance Monitors and Traces, contains detailed information on sizing-based performance measurements. Step Description 1 Define test case 2 Identify test system 3 Create test case in test system 4 Measure sizing KPIs 5 Implement measurement results in sizing method 6 Apply sizing rule Table 2.2 Steps in Creating a Sizing Rule Load Test Load tests are occasionally used in the context of expert sizings and make sense when a single-user analysis does not provide sufficient information about the locking procedure or memory requirements. In the sizing environment, load tests have a hybrid nature: On the one hand, you can use them as a siz- ing tool. On the other hand, you can use them to verify sizing results. Because customers usually use them to verify sizing results, you can find detailed information on them in Section 7.1, Load Tests. ̈ ̈ ̈ ̈ Sizing Measurement Versus Performance Analysis Note that sizing measurements reflect only the actual status. Based on sizing measurements, you can deter- mine whether a business transaction is scalable. In this context, scalability means that the resource con- sumption increases linearly with the number or size of the processed projects. If a process is not scalable, you must analyze and resolve the problem in a perfor- mance subproject. The advantages of expert sizing over other sizing meth- ods are found in the higher degree of accuracy and reli- ability of the information. If you manage a sizing project for a complex or large customer, you should definitely consider aspects from expert sizing, even though the col- lection and analysis of the information takes more time. 2.3 Sizings Based on Productive Customer Data Sizing is an iterative process — that is, even operational installations can be subject to change processes that affect the resource requirements, as the following exam- ples will show: You want to consolidate your existing system land- scape (for example, by merging all your international subsidiaries on one server). You want to add additional functions to an existing system (for example, by installing a CRM system on a server that already hosts an ERP system). You want to upgrade Release X to Release Y. All these situations can affect the hardware and require a more or less comprehensive sizing project. The major advantage of sizings that are based on a production sys- tem is that you can use your own data and settings as a basis. In other words, you do not need to rely on assump- tions made by SAP. Regarding production sizings, we distinguish between the following three methods, which pursue different goals: Resizing In a resizing project, the throughput or user volume ̈ ̈ ̈ ̈
  9. 9. www.sap-press.com 13 changes, but not the processes (or customizing or parameter settings, and so on). Delta Sizing In a delta sizing project, you add new functionality. Upgrade Sizing An upgrade sizing involves a change of the SAP release. Common to all these sizing methods is that you must first analyze the status of the existing system before you can plan the new hardware requirements. Production System Sizings Versus Quick Sizer The unbeatable advantage of sizing on the basis of pro- duction data is that you can take your own data, pro- cesses, and settings into account. Quick Sizer has been designed for new installations and contains assump- tions about the productive operation. For this reason, we recommend Quick Sizer for initial sizings only. Basic Analysis for All Production Sizings For all production sizings, you must first identify the uti- lization of the sizing-relevant components in the exist- ing system. Using the appropriate monitors, which are described in detail in Chapter 6, you can determine the following information: CPU Utilization What is the actual utilization of the CPU? Can the existing hardware compensate for the future load? Here, you must distinguish between the utilization of the application server and that in the database. Memory Consumption How much room for maneuver do you have regard- ing the memory requirement: Will it increase or stay the same? Database Space Take a look at the 30 biggest tables and indexes, and make a note: How quickly did they grow during the last several months? Once you have determined the current utilization or the database growth and the increasing memory require- ments using the various vendor-specific monitors or the SAP monitors, you should relate this information to a simple business key figure. Usually this is the users, but ̈ ̈ ̈ ̈ ̈ it can also be projects or calls. Alternatively, you can also use the number of activities or sales orders, depending, on the one hand, on which unit is best suited to reflect the respective business activity, but also, on the other, on how easily it can be determined. Sample Analysis of a Production System The following example forms the basis for the descrip- tion of individual sizing methods. A customer uses strategic procurement in the SRM environment. The analysis of the current utilization provides the follow- ing result: CPU Utilization of the database server is 34%; that of the two application servers is 56%. Database 213GB out of 512GB are occupied with a monthly growth of 7GB. Memory 26GB out of 32GB are being consumed. By using a system monitor, the customer has found out that approximately 1,254 named users out of a total of 1,567 have been active during the period ana- lyzed. Based on this information, you can now deter- mine whether the existing hardware is sufficient or whether it must be extended. ̈ ̈ ̈ Resizing A basic prerequisite for resizing is that only the through- put and user volumes can change, but not the function- ality. Based on the current load situation and the new information, you can easily determine future require- ments using a rule of three. Typical resizings occur in system consolidations or in what is referred to as phased rollouts, in which customers install new software in different phases in their business units or international subsidiaries. Resizing a Production System Based on the above example (see previous box, Sam- ple Analysis of a Production System), a resizing could look as follows: You want to add another 200 named users to the 1,567 existing ones. We assume that the ratio between named users and active users is identical 2.3 Sizings Based on Productive Customer Data
  10. 10. 14 ©Galileo Press 2007. All rights reserved. 2 Sizing Methods Delta Sizing Because delta sizing can be performed only when new functions are added to an existing software application, the procedure is similar to that of initial sizing, the only difference being that the sizing results are applied to the current utilization. However, there is one special characteristic you should be aware of: The SAP’s standard sizing rules specify the CPU requirements in terms of SAPS and a target utili- zation of 65%. As we will demonstrate in Section 9.2, SAP Application Performance Standard, each hardware configuration in the SAP environment has its own SAPS value, which can be specified by the hardware vendors at any time and for each release. Based on this information (available SAPS, software release, CPU utilization, new SAPS), you can easily calculate whether the hardware will be sufficient by using a rule of three. Delta Sizing of a Production System The above customer (see previous box, Resizing a Pro- duction System) has created a sizing for a new appli- cation. According to the sizing, the application will require 1,200 SAPS (240 database SAPS and 960 appli- cation SAPS). What needs to be done now is easy: The SAPS values must be added up, and the target utiliza- tion must be determined. The existing hardware is evaluated as follows: Database server: 4,000 SAPS; the two applica- tions: 2,800 SAPS each The current net SAPS consumption for the data- base is 1,360 SAPS (i.e., 34% of 4,000 SAPS) and 3,700 SAPS at the application level (i.e., 66% of 5,600 SAPS) For the database, this would mean the following: 1,360 SAPS + 240 SAPS = 1,600 SAPS — which represents a future utilization of 40%. The application servers reach 4,660 SAPS and a utilization of 83%, which could lead the customer to the conclusion that it would make sense to add another application server. If you have followed the above descriptions of tools and methods closely, you will have noticed that SAP calculates the standard sizings with a target utiliza- tion of 65% and you should therefore only use net amounts. However, you should also take into account that the delta is based on standard assumptions as well, and the 65% factor could be a useful buffer. But if you want to base your calculations on net amounts, you can do so as follows: The net requirement of the new application is 780 SAPS (1,200 SAPS × 0.65 target utilization). 160 SAPS out of the 780 SAPS are allocated to the database, 620 SAPS to the application level. Consequently, this means that we can expect a growth of approximately 10% for the database and approximately 20% on the application side. ̈ ̈ ̈ ̈ among the new users and that they will do the same as the existing users, so that we can make the follow- ing calculations: Active Users The ratio between 200 and 1,567 is 12%, which means that the number of active users will prob- ably increase by 12%. CPU Database Server 34% + 12% corresponds to 34% × 1.12 = 38.1% A utilization of 38% is sufficient for a database server. Many customers plan a target utilization of 25% to 50% for the database server. CPU Application Server 56% + 12% corresponds to 56% × 1.12 = 62.7% The application servers can absorb a utilization of 62.7% quite well. However, many customers plan a target utilization of 30% to 50% for the applica- tion servers, which is why an extension is at least conceivable here. Main Memory 26GB (out of 32): 26GB × 1.12 ~= 29GB 29GB out of 32GB of allocated memory might be a bit tight. It is therefore advisable to extend the memory. Database Space 7GB of growth corresponds to 7GB × 1.12 = 8GB per month Currently, 312GB out of 512GB are being used. If the database grows by 96GB (8GB × 12 months) per year, bottlenecks can occur in a very short time. Thus, the disk space should be extended. ̈ ̈ ̈ ̈ ̈
  11. 11. www.sap-press.com 15 Upgrade Sizing In upgrade projects, customers usually implement numer- ous changes, which include the SAP software, database, operating system, and an exchange of hardware. It often happens that the configuration and parameter settings are changed as well. All this can have an impact on the num- ber of work processes, buffer settings, or other things.1 Upgrade sizing refers to the additional requirements of SAP software. SAP uses regression tests to check the resource consumption of the most important transactions and to create a delta. This information is made available to all customers in SAP Notes, such as SAP Note 901070, which describes the resource consumption between SAP ERP Core Component (SAP ECC) 5.0 and SAP ERP 6.0. The SAP Notes provide information about the delta regarding the number of database calls, CPU require- ments, memory requirements, and database space. Because these SAP Notes provide standardized infor- mation about different transactions, they carry the risk of you currently using a transaction that is counterbalanced by other transactions. Sample Upgrade Sizing A (fictitious) SAP Note on delta resource consumption states that the resource consumption in the memory increases by 5% on average. Transactions A and F do not show any additional consumption, whereas Trans- action G consumes an additional 30%. The CPU and database consumptions remain unchanged. If you — as the customer — now use Transaction G extensively, this could cause problems when calculat- ing the main memory. The best thing to do is to calcu- late a best case and a worst case. Memory (Best Case) 26GB (out of 32): 26GB × 1.05 ~= 27.3GB Memory (Worst Case) 26GB × 30% = 33.8GB Probably, the future memory requirement will be within that range. ̈ ̈ 1 Since this is a very complex subject, SAP provides the SAP GoingLive Functional Upgrade Check service as part of the standard service coverage (see also Section 7.2, Verification via Support Services). The SAP GoingLive Functional Upgrade Check includes a sizing process. Single-Instance Projects From the point of view of sizing, the majority of single- instance projects in which companies change from a best- of-breed strategy2 to a single-instance strategy (one soft- ware vendor, all data in one system) represent a mixture of resizing and delta sizing, sometimes also upgrade siz- ing. Note that an upgrade sizing must be performed first to make sure that identical conditions apply. Considerations in the Context of a Single-Instance Study A customer uses several SAP and legacy systems in Europe. This customer now wants to consolidate its European and American systems. Consequently, this means the following: If the SAP software has different release versions, an upgrade sizing must be performed first. The rel- evant factors will be upgraded so that all systems have the same version. The next step involves resizing the SAP software based on the same release version; that is, the cur- rent consumptions of existing SAP systems must be analyzed and totaled. Finally, a delta sizing must be performed for the legacy software. Ultimately, the additional require- ments for the new software are added to the exist- ing load. ̈ ̈ ̈ 2.4 Summary Because SAP software shows a high degree of scalabil- ity, you can consider a linear change in consumption as a given fact. The same applies to hardware: If you want to extend the processing power of application servers, you can add more servers, replace the CPU, or add more CPUs, depending on your specific production model. However, a new application server affects the data- base’s memory requirements because it involves the addition of new database users. A higher volume gener- ally means an increase in read and write activities, which, in turn, may have an impact on the disk subsystem. 2 In a best-of-breed strategy, you always choose the prod- uct from the best vendor for each (technological) area. The different products are then connected with each other via interfaces. 2.4 Summary
  12. 12. 16 ©Galileo Press 2007. All rights reserved. 2 Sizing Methods The sizing method used essentially depends on the initial position you’re in. Basically, there are different methods for an initial sizing, which can be mapped via standard tools, and for a production sizing, which uses production data as a basis for forecasting. In this chapter, we have mentioned several times that although sizing tools are very useful, they are subject to certain limitations. These limitations primarily depend on the way in which business processes and the associated application software interact with each other. For this reason, the following chapter, Sizing Approaches (Chap- ter 3), describes how you can convert user-based and throughput-based sizings into algorithms, and discusses the pros and cons of different sizing approaches.
  13. 13. www.sap-press.com 107 Index 2-tier implementation 47 3-tier implementation 47 80/20 rule 35 A A/P (Average and Peak) 44 Active user 21 Advanced sizing 10 Analysis of customer data 11 of customer processes 11 performance monitor 51 transaction design 60 Application monitor (ST07) 54 Application profile 71 Application server 14, 19, 46, 55 Application team 73 Archiving object 45 Average CPU sizing 49 Average load 48 B Baseline test 62 Benchmark result 30, 36 BI Accelerator Ǟ Business Intelligence Accelerator Blank installation 46, 47 Blueprint phase 8 Business Intelligence Accelerator (BI Accelerator) 18 C Cache 27 CCMS Ǟ Computing Center Management System (CCMS) Chief Information Officer (CIO) 4, 74 Chief Process Innovation Officer (CPIO) 4 Coding custom 11, 59, 62 Computing Center Management System (CCMS) 51, 65, 68 Concurrent user 21 Consolidation phase 8 Core 18 Core process business 10, 65, 75 Core team 73 CPU 3, 15, 18, 66 CPU load 24 CPU time 3, 12, 23, 30, 57 CPU utilization 13 Custom development 8 Customer data analyzing 11 Customer reference installation 23 Customizing 13, 17, 65 D Database 18, 39, 53 Database monitor 53 Database server 13 Database space 13, 39 Data Dictionary 58 Delta sizing 13, 14 Disclaimer 42 Disk growth 53 Disk I/O operations 19, 39 Disk space database 14, 39, 47 DPU Ǟ Logical Deployment Unit (DPU) Dual-stack installation 26 E Employee Self-Services 75 Evaluation phase 74 EWC Ǟ SAP EarlyWatch Check (EWC) Expert sizing 10, 29, 51, 76 Expressiveness of sizing project 7 Extension phase 8 F Frontend network 19, 21, 57 G Garbage in, garbage out 32, 76 GLC Ǟ SAP GoingLive Check (GLC) GoLive 8 H Hardware budget planning 4, 71 Hardware budget sizing 8 Hardware costs 4, 71 Hardware vendor 35, 42, 71 high-volume load tests 24 I I/O (input/output) per second 39 IAS Ǟ International Accounting Standard (IAS) Implementation 2-tier 47 3-tier 47 Implementation phase 8, 71, 76 Implementation project 27, 71, 74 Initial sizing 8, 63, 75 Input error 41, 43 International Accounting Standard (IAS) 33 IT team 73 J Java-based application 25, 47 Java Virtual Machine (JVM) 57
  14. 14. 108 ©Galileo Press 2007. All rights reserved. Index K Key performance indicator 12, 17, 31 L Landscaping 6, 72, 78 Latency 19 liveCache 18 Load test 12, 59 analysis 60 multi-user mode 61 performing 61 planning 59 toolkit 24 tools 60 Local area network (LAN) 17, 73 Logged-on user 21 Logical Deployment Unit (DPU) 46 M Master data sizing 22, 26 Maximum Extended Memory in Transac- tion 57 Memory consumption 13 Memory requirement 40, 52, 56, 57 Methods 7 Minimum requirement 5 N Named user 20 Network load 19 Network traffic 32 Non-disclosure policy 23 O Offline questionnaire 33 Online Analytical Processing 29 Operating system monitor 52 Orientation phase 8 P PAM Ǟ Product Availability Matrix (PAM) Peak load 48, 49 Peak sizing 49 Performance analysis (ST30) 12 Performance monitor 51 Performance trace (ST05) 51, 57 Phased rollout 13 Phases of sizing projects 7 Physical memory 18 Processor 18 Product availability 5 Product Availability Matrix (PAM) 5, 18 Production sizing 8, 12, 53, 67 Programming guidelines 30 Project team 73 Q Quick Sizer 35 average CPU sizing 37 CPU peak sizing 45, 48 design principles 35 documentation 36, 41, 42 functions 36, 40 navigation 41 peak CPU sizing 37 project 36, 41, 47 questionnaires 37, 41, 47 result 38 Save function 41 sizing element 38, 44, 47, 48 R Reference database 23 reference installations 23 Residence time 19, 27 Resizing 12, 13, 63 Resource consumption 15, 24 Rule of thumb 29 S SAP Application Performance Standard (SAPS) 10, 38, 40, 50 SAP EarlyWatch Check (EWC) 67 SAP GoingLive Check (GLC) 63 SAP GoingLive Functional Upgrade Check 15, 63, 68 SAP NetWeaver Business Intelligence 21, 40, 58 Portal 21, 44 Process Integration 4 SAPS 40 SAP Solution Manager 64 SAP Standard Application Benchmarks 23 Scalability 3, 61 Sessions 21 Single-instance project 15 Single-user analysis 12 Single record statistics (STAD) 56 Sizing approach 17 by throughput 22 by users 4, 20 definition 3 expressiveness 7 formula 32 informational value 31 initial 8 methods 7, 8, 11, 16, 27 measurement 12 object 45 principle 3 production 8, 51, 63 production sizing 13 result 40, 46 scope 20 throughput-based 38, 44 tool 11, 29, 51 user-based 20, 38 verification 59, 63 Sizing project 71 application team 73 core team 73 definition 72 documentation 74, 77 execution 71, 74 goal 74 IT team 73 planning 71 procedure 74 project scope 71 stakeholders 72 success factors 71 Software architecture 31 Status 42 System consolidation 13, 15 System GoLive 63, 67 System integration 65 T T-shirt sizing 9, 30 Target utilization 14, 50 Throughput-based CPU sizing 45 Throughput sizing 22, 23 Throughput sizing model 23 Throughput volume 7 Total cost of ownership (TCO) 4 Trace tool 51, 57 Transaction DB02 53
  15. 15. www.sap-press.com 109 Index Transaction ST05 57 Transaction ST06 52 Transaction ST07 54 Transaction STAD 56 U Upgrade phase 8 Upgrade sizing 13, 15, 63, 67, 75 Usage type 47 User active 21 concurrent 21 interaction step 52, 57 logged-on 21 named 20 User-based sizing 20, 38 User interaction step 57 V Verification 77 of sizings 59, 63 W Wide area network (WAN) 17, 73 Work days in Quick Sizer 42

×