I N D U S T R Y

S U B S Y S T E M S

Sizing
The

Foundation for a Successful SAP Implementation

By Anand Vridhagiri Sizing is an important element of a successful SAP implementation. This article describes sizing fundamentals in a SAP R/3 environment, several approaches to sizing, and the pros and cons of the various sizing methodologies. It also briefly discusses the SAP Standard Application benchmark, since this benchmark provides the basis for the sizing methodology. The article concludes with a discussion of the capacity planning process, sizing report, and resources available from the ERP Global Alliances team.

izing is the process of determining the hardware requirements to implement SAP when the number of users is known or can be estimated, and the details of transactions are available. Sizing is based on heuristic experience with the R/3 system and continuous performance measurements; currently the Sales and Distribution (SD) component is the reference component against which all others are weighted. The SAP sizing tool from Dell uses two sizing models: userbased sizing and quantity-structure-based sizing. The input for user-based sizing is the number of users who will work with an application in production. The quantity-structure-based approach uses the numbers and sizes of objects being created, changed, or displayed per component or business process as input.

PowerMatch SAP Sizing Tool

The Dell PowerMatch sizing tool strictly adhers to the SAP sizing methodology and rules.
www.dell.com

The number of active users accessing the system in each R/3 module determines the processor requirements. This number is determined by converting the number of users in each module to normalized SD users through a series of weighting factors between the average loads generated by typical users in each of the modules. The PowerMatch sizing tool offers two sizing recommendations based on expert or custom mode. The Expert sizing tool provides recommendations based on standard algorithms. The Custom sizing approach asks for the processor choice (the speed and amount of cache), then the sizing tool recommends the number of processors, memory, and disk space. The result of this process is a sizing report that details the input provided for the tool, configuration recommendations either in central or distributed mode, and sizing recommendations for development and test servers. The next section provides a brief introduction to SAP standard application benchmarks and resource consumption of various modules to help you better understand the sizing
PowerSolutions 71

SAP APPLICATION MODULES SAP Grouping Financials Modules Financial Accounting (FI) Controlling (CO) Asset Management (AM) Project Systems (PS) Plant Maintenance (PM) Quality Management (QM) Production Planning (PP) Materials Management (MM) Sales and Distribution (SD) Human Resources (HR) Workflow (WF) Industry Solutions (IS)

methodology. Figure 1 shows the various modules in the SAP application.

Standard Application Benchmarks

The R/3 Standard Application Benchmark consists of several script files that simulate the most typical transactions and workflow of an R/3 user. This benchmark uses a predefined SAP client database containing sample company data for the benchmark. The benchmark transactions of each component usually reflect the data throughput of an installation (that is, orders per day, number of goods, movements, and so on). The benchmark does not consider reporting, since the resource consumption of customer-defined reports depends on the volume of data. Each benchmark user has its own master

Logistics

Human Resources Common Systems

Figure 1. SAP Application Modules

THE ROLE OF COMPETENCE CENTER The Dell-SAP Competence Center handles all sizing-related activities. For successful sizing, customers must provide information about the planned logistics, including the number of users, user activity, and details of transactions. Figure 2 shows this process.

SAP

Business Requirements

Feedback/ Experience

Customer

Dell Sizer

Figure 3. The Sizing Form The Competence Center receives the request for sizing and runs it through the sizing tool. The center then sends the sizing report to the customer, followed by a phone conversation to discuss the details of the configuration. If necessary a resizing may be performed; otherwise, a final configuration for the SAP implementation is determined. The Competence Center often becomes involved before the sizing process is performed for existing installations or for an upgrade opportunity. As a best practice, when the implementation is close to completion, the customer should contact the Competence Center before going live to verify the sizing and to ensure that the system will handle future growth. Dell strongly recommends that a knowledgeable SAP consultant gather the customer sizing information.

Hardware Configuration

Technical Requirements

Hardware Partner

Figure 2. The Sizing Process The customer site is the starting point. For new implementations, customers must complete the sizing form (see Figure 3) from the Competence Center or complete and submit one directly from the Dell SAP Alliance Web site at www.dell.com/products/poweredge/partners/sap/sap_form.htm.

72

PowerSolutions

data, such as material, vendor, or customer master data. This approach helps to overcome locking situations in the database. A maximum of 100 parallel benchmark users can be simulated per client and per application (the benchmark client number starts with 900). The SAP Benchmark Council stipulates the maximum number of simulated benchmark users that can be reached with a minimum number of benchmark clients. The benchmark can be run either in the central system or distributed (three-tier) configuration. Although benchmarks are available for most SAP modules, the figure most often communicated is the number of SD benchmark users supported. The SD application, one of the most complex modules available, provides the best single representation of a mixed group of users accessing different modules.

The lowest column of the bar represents the resource consumption of the database. The update task consumption is shown in the middle column of the bar. The highest column of the bar represents the dialog task resource consumption.

How to Approach Sizing

Several parameters can help determine the best approach to sizing. I User behavior can be classified in technical or business terms. An important parameter is the activity profile of users: how often and how frequently a user sends requests to the system. The users think time is the determining factor. I The applications used can impact resource consumption. Each module has its own impact on the resources; special functionality can cause an additional load on the system. I Customization is another key factor. Customer modification can have a strong influence on the resource consumption and the way business transactions are processed. This includes business processes, expected throughput, and tuning of the operating system, database, and the SAP Basis layer.

Resource Consumption
Each R/3 dialog benchmark consumes system resources in different proportions. Figure 4 shows the distribution of resources for a sample hardware and database configuration for Release 4.0. The relative CPU load in the Standard Application Benchmark suite is adjusted to FI, the component with the least CPU consumption.

7 Platform & Release Dependent 6 Rel. CPU-Usage/Dialog Step 5 4 3 2

76% 88% 68% 12%

Database Update Dialog

68%

1
60% 77% 12% 11% 19% 22% 13% 11% 18% 14% 3% 9% 20%

FI

WM

MM

SD

PS

PP

R/3 Business Component

Figure 4. Load Factors Based on R/3 Standard Application Benchmarks 4.0

www.dell.com

PowerSolutions

73

The choice of database, operating system, and specific release of the R/3 system also influence sizing to a lesser degree. Factors That Influence Performance Sizing and capacity planning use the system performance numbers to measure and determine the hardware needs. Two categories of factors influence the performance: one that includes the R/3 version, operating system, and database version which are defined by SAP and the partner; and the secondand most influentialis the customer input, such as number of users, amount of reporting/batch, the load profile, and customization needs. Figure 5 shows that the overall performance depends on a variety of factors. The output of this tool is to calculate the sizing and hardware configuration based on customer input.

performance test-based. These three models are completely independent of each other because each emphasizes different points. The results from each are also different, especially when comparing user-based sizing to throughput-based sizing. The user activity (think time) for user-based sizing is based on estimates and may not accurately reflect the real world. Figure 6 shows the various sizing models and their relationship to accuracy.

User-based Sizing
User-based sizing is the convenient approach to sizing. It simply requires someone to classify the users for different modules based on the user activity. The sizing tool incorporates this input and provides an estimated resource requirement to match the needs of the users described in the sizing form. Since the word user is rather abstract, we need to define a user in the R/3 environment: I A named user is one with an account. Since we have no information pertaining to the activity profile of the named user, such as think time or functional modules used by this user, we do not consider a named user for sizing. I Front ends, or work places, include all related software that have been installed in the network. This number can be different from the number of active users, because several different users can share one front end or a single user can work on multiple front ends. Thus, the number of front ends does not play a useful role in sizing the database or application server. I Sessions comprise the number of open sessions. Although users can open multiple sessions, only one session can be active at a time. Each opened session will require additional memory to store the session context. I Concurrent users work simultaneously or concurrently in the system. Users who are logged on differ from concurrent users because those who logged on processed a logon procedure and can use the system. They must be concurrent at all times, even though they have logged on. I An active user (the one used for user-based sizing) performs a given number of business processes during a given time period. Active users fall into three categories, based on typical activity patterns of users: low, medium, or high (see Figure 7). Note: A dialog step is similar to a screen change, whether it is initiated by the user or the R/3 system. For the FI module, most transactions are simple additions or updates to a single record, and they will have four dialog steps: I User initiates a transaction I R/3 returns a screen and some basic data I User updates information I R/3 returns the status after processing the information

Selecting a Sizing Model

Three different and independent sizing models are used for sizing an R/3 system: user-based, throughput-based, and

SAP and Dell

Customer Number of Users

R/3 Release

DB Release

Performance/ Sizing

Reporting Dialog/Batch

Amount of Reporting/ Batch Load Profile

OS Release

Hardware

Throughput Response Times

Customization

Figure 5. Performance Influencing Factors

For small projects Cost-effective Results not very accurate For larger projects Not a simple process Results relatively accurate Customized approach Expensive and time consuming Results accurate

User-based
Incr ingl eas yA ccu rate

Throughput-based

Performance Test-based

Figure 6. Sizing Models PowerSolutions

74

This varies with other modules and may have more or less dialog steps per transaction. The User-based Model Load factors are important in the user-based model because of the impact of different application components, business processes, and user behavior. The following resource consumption is considered for this model: I CPU: Load factor model CPU resource consumption of different user types, business processes, and R/3 components. The standard application benchmarks and CPU measurements of business processes are used to determine the CPU load factors. I Memory: Memory utilization relies on user-specific and shared resources, including the user context, as well as the user work processes and shared buffers. Memory consumption = shared buffer + context number of users R/3 components influence the size of the shared buffer and the size of the user context. The memory requirements for the database server and an application server vary. Disk space: The user activity profile can help when calculating how many business processes of an R/3 component will be processed by each user during a certain time The SAP sizing tool interval. The R/3 data from Dell uses model determines the amount of disk space two sizing models: needed to store business documents of a certain user-based and business process. Once we quantity-structurehave the data archiving and document retention based sizing. times, we have all the information necessary to forecast database size. Network bandwidth: Between the presentation server and application server, network traffic averages 2 KB and one round trip for each dialog step. To calculate the total response time measured on the presentation server, the network latency must be added to the application server response time.

ACTIVE USER CATEGORIES Active User Category Low

Pattern An occasional user who averages 400 dialog steps (screen changes) per week, which is about 10 dialog steps per hour or one every six minutes The user who processes an average of 4,800 dialog steps per week, which is equivalent to 120 dialog steps per hour or one dialog step every 30 seconds The user who averages 14,400 or more dialog steps per week, which is about 360 dialog steps per hour or one every 10 seconds. A typical power user working in a call center or doing data entry can be classified as a high user

Medium

High

Figure 7. Active User Categories

accuracy in defining a user activity, which can lead to improper sizing. Future user growth is another area generally not considered. This model could result in performance bottlenecks as the company grows. For these reasons, this approach has a large element of risk for a large implementation.

Throughput-based Sizing
Customers who can estimate the expected data volume, details of the transactions, and throughput per R/3 component can use this approach for sizing. Here are some assumptions to consider for this sizing: I Most business processes used in the system are comparable to the business processes tested in the R/3 Standard Application Benchmarks and optimized for high throughput. I The system performance or scalability is not impacted significantly by any special customer add-ons. I Reporting generally takes place during time periods where the load on the system is small as compared to the peak load. Hence, reporting is ignored as input for this type of sizing. I The system bottleneck is always considered to be related to the CPUs and not to the memory, network, or the I/O subsystemwhether it is a central system or a distributed system of implementation. I A computer running in a central system mode and capable of handling 6,000 dialog steps per hour in the SD benchmark has 100 SAPS (a SAP-defined unit for measuring business throughput in a hardware-neutral format). An application server running 100 SAPS
PowerSolutions 75

User-based Approach is Popular Simplicity and ease of sizing input makes the user-based approach the most popular choice for a small to medium implementation. The drawback, however, is the lack of
www.dell.com

can also handle the requirements of 100 SAPS as a database server. Throughput-based Model The following resource consumption is considered for this model: I CPU: Standard application benchmarks are used to determine the CPU times (service times) for each transaction and service (dialog, update, and database) on a reference CPU. The SD benchmark measures the number of SAPS of the reference CPU.
I

experience, especially during early stages of implementation, is that the development workloads are much higher than production workloads. System Landscapes The R/3 environment consists of Development (DEV), Quality Assurance (QAS), and Production (PRD) systems. All customization and development work is performed on the DEV system. After all the changes have been unit tested, these changes can be transferred to the QAS system for further system testing. Once the quality assurance team has thoroughly tested the configuration in the QAS system and signed off, the configuration can For successful sizing, be copied to other system clients and to the production customers must system, which contains the provide information companys live data used for production. about the planned The system landscape is the distribution of the DEV, logistics, including the QAS, and PRD systems in an number of users, user R/3 environment, as activity, and details described below. landscape. Single-system All systems in a single-system of transactions. landscape reside in the same R/3 system, but perform different functions, such as development, quality assurance, and production. The disadvantage of this landscape is that once development is done and production begins, it is not possible to return for more development. The production must be stopped if more development and testing is required. Two-system landscape. In this landscape, the production is hosted on one system while both DEV and QAS are placed on another system. Performing both development and quality-assurance testing on the same system means that once a tested program is transported to the production system, there is no turning back. This landscape has an additional significant advantage: The production system is isolated from the other systems, which results in a stable environment. Three-system landscape. This landscape is the best solution: Each moduledevelopment, quality-assurance testing and application testing, and productionis placed on a separate server. The advantage of this approach is that the production server is independent of the development server and does not need to be halted to implement continuous developmental activity. In addition, the production system has the same runtime environment as the quality-assurance

Memory: The user-based sizing model is better than the throughput-based approach in the memory category. Since the user context dominates the memory requirements, user details rather than transactional details dictate the memory requirements. Disk space: Tables with many inserts and those that store business data for a long period of time play a vital role in determining disk space requirements. As a next step, the system determines the net size of the table rows as well as the net size of the indexes for each row. Additional input parameters for the disk space calculations include the number of lines in each table, which can be derived from the amount of business processes, and the retention period, which determines how long the table entries will be stored before they can be deleted. The last factor to consider is the space required for an off-the-shelf system without business data or the data that comes with a fresh installation. Network bandwidth: The user-based model, not the throughput-based model, determines the required network bandwidth. This depends on the number of users accessing the presentation server.

Throughput Assumptions May Produce Misleading Results What appears to be a great advantage in this case can soon turn into the largest hurdle. The relative thoroughness of this approach can lead to more accurate sizing compared to the user-based approach. However, the assumptions about the data throughput can often produce misleading results if some of the assumptions are not valid or are actually incorrect. There is also a risk that during the implementation of the business processes, some previously defined requirements must be readjusted as the implementation is being done.

Development and Test System Sizing

The development and test system configurations are often determined by sizing workloads as a straight percentage of the production system. The main problem many customers
76 PowerSolutions

system. The drawback of this approach is its requirement for more hardware and additional administrative tasks.

CUSTOMER INPUT FOR USER-BASED TRANSACTIONS Module Low 10 20 10 20 Medium 10 20 10 30 High 10 5 5 20

A Sample Sizing Report

Once the sizing process is complete, a sizing report is issued and presented to the customer. The contents of the report will include the following: I Customer input about the various modules in the case of user-based transactions (Figure 8 shows an example) I Hardware configuration requirements based on a central or distributed system The Dell sizing report offers both SCSI and Fibre Channel storage solutions. When clustering solutions are requested, a separate section covers the implementation details. Figure 9 shows an example of hardware configuration of a distributed system with both database and application servers.

CO FI MM SD

Figure 8. Customer Input for User-based Transactions

A meaningful estimate of the number of users that will run the system, a clear vision or expectations of the transaction requirements, and behavior are the foundations for good sizing and implementation. The Dell PowerMatch SAP sizing tool translates business requirements into technical requirements for selecting an economically balanced system that matches a companys business goals. N

Experience: The Key to Accurate Sizing

User-based sizing might be appropriate for small businesses since business requirements are often determined by the number of users performing specific business tasks. Users are grouped per business task according to their estimated usage activity, based on which sizing recommendation is provided. Quantity-structure-based sizing is recommended for medium and large businesses. This sizing method uses the number of users plus additional information about the number of business processes and business objects. Prevention is better than cure. An accurately sized system performs well and behaves as expected when it goes live. The key to accurate sizing is experience. Anand Vridhagiri (Anand_Vridhagiri@dell.com), a member of the Dell ERP Global Alliance team, has worked in high-performance computer design, performance analysis and optimization, database systems, and enterprise resource planning for more than nine years. He has been actively involved with the Transaction Processing Performance Council (TPC), Computer Measurement Group (CMG), and IEEE. Anand has an M.S. degree in Electrical Engineering from New Mexico State University and is a Microsoft Certified Systems Engineer (MCSE).

HARDWARE CONFIGURATION OF A DISTRIBUTED SYSTEM Hardware Servers Processor (Quantity) L2 Cache RAM External Storage Host Bus Adapter Hard Disks Database Server 1 PowerEdge 6300 Pentium III Xeon @ 550 MHz (4) 2 MB 2 GB 1 PowerVault 650F 1 Qlogic 64-bit PCI 2 x 9 GB (RAID 1) + 7 x 18 GB (RAID 5) 2 x 9 GB (RAID 1) 1 Intel Pro+/100 Application Servers 4 PowerEdge 6300s Pentium III Xeon @ 550 MHz (4) 2 MB 2 GB On-board controller 2 x 9 GB (RAID 1)

Network interface card

1 Intel Pro+/100

Figure 9. Hardware Configuration of a Distributed System with Database and Application Servers www.dell.com PowerSolutions 77