| I l@ve RuBoard |
The Business Processing Requirements
A decision to implement a mySAP.com system requires a hardware platform to run it on. Regardless if the hardware capacity is already available in house or needs to be acquired, a sizing is usually made in order to understand the potential requirements. The business processing performed by the SAP application is the most important factor in determining the hardware configuration. Estimating the future business transaction volume demand in terms that can be related to hardware configurations is considered the sizing process, or a sizing.
Sizing Process Overview
There are two main types of sizings: new and upgrade/resizings. Sizings for new systems are made with estimates of transaction data (number of documents to be processed) or numbers of users and are expressed in generic terms. These estimates can be made with the help of an application consultant. The data is often collected via a questionnaire and is then processed by a hardware vendor or other consultant familiar with the process. The output is a sizing estimate in generic terms (transactions/hour or equivalent) that can be used to compare against server hardware processing capabilities (capacity planning). Depending on the customer request, a simple sizing proposal is delivered for budgetary purposes, or a full sizing proposal including infrastructure requirements is provided.
The hardware vendors provide sizing services for free but have different levels of experience and methodologies. Some have been performing sizings since SAP R/3 was generally available and other hardware partners simply provide a certified platform without sizing services. SAP has recently staffed a team for helping make sizing estimates, for which they charge a fee, however. Ideally, look to SAP consultants to determine information about the business volume processing requirements, and look to the hardware vendors to determine the hardware needed to process that volume. Regardless to which organization they belong, consultants who have been involved with real-life SAP projects that include both application and hardware performance tuning considerations are best at handling complex sizing considerations.
There is no ideal sizing approach; compromises and assumptions are always made. |
Because new sizings are only based on a best guess or reasonable estimates, some exclusions or exceptions always apply. When a project starts out, some level of customization takes place, which is difficult to account for in the sizing process. In some cases, the only way to perform a reasonably accurate sizing estimate (for critical configurations) is to perform a customer benchmark using the customized SAP application functions. Typical for larger SAP implementation projects, more application functionality is discovered over time and included that may not have been reflected in the original sizing estimate. Consequently, additional sizing estimates become necessary to reflect the changing requirements. In this case, sizing is an iterative process.
TIP
Performance Evaluation on Real Data Volumes
Before going live into production, some hardware vendors offer facilities and services to test customers' specific SAP implementation on appropriate server and disk hardware configurations. The goal is to give confidence to the team by measuring the performance of a particular server platform and on a volume of data that is proportional to the final production database size. This does require a team effort, however.
Capacity Planning (Upgrade or Resizing)
The capacity planning sizing process is used whenever significant changes to the SAP system are expected. Upgrade sizing is when a release change is considered, for example, when going from release SAP R/3 4.0 to 4.6 or newer. Even if the user and transaction load remains the same, there is often an impact on the hardware configuration, which can be estimated by performing an upgrade sizing. A resizing is the effort to estimate the ideal hardware configuration based on over-or (rarely) underutilization of an existing configuration (load-based sizing review). This is usually the first step that takes place before performing an upgrade sizing, ensuring enough hardware is available for the planned upgrade or additional workload.
Once the data is collected and agreed upon, the output of the upgrade or resizing can also be stated in terms as transactions per hour or equivalent, for hardware resource capacity planning. This is the basis for a sizing proposal, which should also include the additional infrastructure improvements needed for the particular release of SAP software.
Figure 3-1
shows the various sizing activities for a typical SAP implementation project. The initial hardware sizings from the hardware partner, SAP's GoingLive and EarlyWatch sizings, and the follow-up release or functional upgrade sizings from the hardware partner are all shown in relative sequence to each other around the production start date.
Figure 3-1. Hardware Sizing in a Project Life Cycle
What is evident from Figure 3-1
is that SAP R/3 projects are implemented in phases and that each new phase brings additional users and increasing hardware requirements. It is important in the initial sizing to specify the phase a sizing is for, otherwise incremental hardware upgrades will be needed too often. When new functionality or the SAP R/3 release is changed, additional sizing estimates are typically made.
SAP's GoingLive or EarlyWatch Checks
To ensure that the system capacity is sufficient for production, SAP offers its GoingLive sizing review a few weeks before going into production. This is not a sizing proposal but simply an analysis of the expected workload on the given hardware CPU and memory resources (disk and network are not considered). Because the GoingLive sizing plausibility check is performed closer to production start, more accurate data is available (such as the final user numbers, customization, and document volume information) than was used to make the original presales proposal.
Larger projects do not go live into production in one large big-bang step but start their production step by step. After taking the first step into production, SAP's service organization makes regular EarlyWatch checks, which can include sizing reviews based on a measured workload and on the planned load, which can be used for upgrade or resizing purposes. The default EarlyWatch reports analyze the CCMS data, which measure peak CPU utilization rates at scheduled time intervals (once per hour).
Both the GoingLive and the EarlyWatch sizing reviews provide a rating of the hardware noted in three colors: red, yellow, or green. A red rating means the CPU or memory resources are not sufficient, and the SAP system should not go into production without major changes. A yellow rating means that the hardware resources are defined at their lower limits for the planned workload. A green rating means that the system is ready to go into production. If additional hardware resources are needed, the hardware vendor is involved to provide a resizing.
Methodology
There are three common methods used to determine the requirements of the business processes:
User-based
Document-or transaction-based
Load-based (current utilization)
The user-and document-based sizing methods are used for initial or new sizings and are theoretical estimates of the expected workload for a given set of business processing requirements. SAP's paper called 揝izing the SAP R/3 System桾heoretical and Practical Considerations�describes the sizing model behind this theoretical approach.
The load-based sizing method takes a more practical approach. The utilization of existing application and hardware resources is taken into account. This is useful when the already-in-production SAP system needs to be resized for additional users or for a release or functional upgrade.
User-Based Sizing
The user-based sizing approach takes into account the number of users using the various application components. The number of users active on an SAP system is one of the most important pieces of information to collect for a sizing. For the most common SAP R/3 sizings, the number of users (or user load) helps determine the server's CPU, memory, and disk configurations. For more advanced or high-end requirements, the user load is only used for memory sizing; a document-or transaction-based approach is more accurate for CPU and disk sizing.
An essential parameter for user-based sizing is the activity level. The activity level or transaction profile means how frequently a user will send requests to the system. A request is a dialog screen update or step (reading or posting data). This is expressed by the user's think time between dialog steps, or as an hourly or weekly transaction rate.
A transaction is defined as an event in the SAP R/3 system that views, creates, or updates a document (or object)梐 document processing step. For sizing purposes across a mix of modules, one transaction is assumed to have an average of three dialog steps or screen updates. |
Given that users only perform dialog activity, and that a certain number of dialog steps equates to one transaction, there are several ways to define these user activity levels and thus the impact on the system. A user in the SAP R/3 context could be any of the following:
A named user is a user with an account. Because there is no information on the activity profile (i.e., think time or functions used) of this user, it is impossible to extract any sizing relevant data from this user definition.
Workplaces or front-ends include all front-ends that have been installed in the network. This number differs from the number of active users because one front-end can be used by several different users, or one user can work on different front-ends. Counting PCs or terminals is not normally used for sizing, but in some cases it can be used as a starting point if no other information is available other than named users.
Sessions comprise the number of SAPGUI sessions open. Standard sizing assumes each user works only with one session at a time, even if multiple ones are opened. For each session, however, some memory is needed to store the session context.
Logged-on users, by definition, are those that have processed a logon procedure to the system and are able to work with it. The total number of logged-on users is kept track of by the system, although not all of them may be active (i.e., taking breaks, on the telephone, using other applications, etc.).
Concurrent users are defined as those working simultaneously or concurrently in the system. This is not used for sizing purposes because it is very difficult to track or measure.
SAP chose instead to only consider those users who are active on the system in their sizing procedures for SAP R/3. Three categories of active users are distinguished between, because these categories represent typical activity patterns of users, with three levels of activity: low, medium, and high:
The low user performs at least one screen update (or dialog step) every five to six minutes. This could be a manager or an information user.
The medium user performs one screen change (or dialog step) every 30 seconds. This is the most common active user profile on an SAP R/3 system and should be considered the default if no other data is available.
The high user performs a screen update (or dialog step) every ten seconds. Although this is the profile of a benchmark user, it could also be a power user in a high-volume data-entry situation. Because this user profile places a very high load on the system, it should be used carefully.
It is important to note that the user profiles defined by SAP are for users active on the SAP system, which can be measured on an existing system. However, it is generally difficult to know before implementing SAP how many users will be active on the system. Users that are licensed but not logged on are not counted for sizing purposes. As a doublecheck, however, the total number of users for the sizing may not exceed the licensed user quantity. Some users may log on the system in the morning just to reserve their space on the system but don't use it very actively. These may qualify as low users as defined by SAP's profile, or they may not be counted at all.
An example could be a company that has 1000 licensed users. Of those, only 600 may actually be logged on the SAP system and even fewer actively using it (with a medium user profile of 30 seconds think time) during the peak periods. Once the SAP system is installed and in production, there are ways to track the activity levels of users. However, performing a sizing before the system goes into production is the tough part that requires a best guess at the numbers. Unfortunately, there is no direct relationship between the number of licensed users and those used for sizing purposes; this is unique to each company.
TIP
Defining Users for Sizing
The number of users active during the online activity is not always known because it is often too early in the project life cycle to determine. Sometimes the number of workstations, PCs (terminals), or workplaces are known, but not the activity levels. In this case, using the total number of users expected to be logged on the system is appropriate, although the average activity level across them all will be lower than what SAP defines as active users (a compromise). However, once more information about the project becomes available, the assumption about the user activity levels would need to be revised.
If a running SAP R/3 system is to be resized or upgraded, it is better to perform a load-based sizing analysis to determine the actual user profile than one based on theoretical estimates. For more help in defining the appropriate user load, contact your hardware vendor.
Assigning Users per Module
The detailed level of user-based sizing allocates the users (with low, medium, and high activity levels) across the various SAP R/3 modules. A simple example (A) could be 10 low and 20 medium users assigned to FI, 100 medium users assigned to SD, and 50 to MM. Assigning users to modules with activity levels is the preferred method of user-based sizing, if the information is available. However, it takes a little longer to gather this information because department managers may need to make estimates as to how many users will be logged on to or active with the various SAP R/3 modules.
When assigning users to modules, a few important tips should be followed in order to keep the hardware sizing proposal within economical limits:
Do not double-count users. Although users may need to use more than one SAP R/3 module, assign each actual user only to one SAP R/3 module, the one used most actively by that person. If it is difficult to assign a group of users to SAP R/3 modules, then apply some level of reasonable statistical spread. For example, for 100 SD/MM users, consider placing 60% in SD and 40% in MM, or whatever ratio makes sense for the business.
Although users can open multiple SAP R/3 sessions on their desktop PC or workplace, they still only have one set of hands and eyes to enter or view data. Reports or other batch processes started by users in the background are accounted for separately. Again, each person should only be assigned to one module for sizing purposes.
The total number of users for sizing may not exceed the number of user licenses purchased. In most SAP R/3 implementations, the number of users for sizing is significantly less than the licensed or named users. In very small projects, however, it may be equal to, but never more than the number of licenses.
Be very careful about assigning any users in the high category with SAP's activity profile of ten seconds think time. This represents the physical human limits of data entry and only applies to certain industries or departments. Although using this worst case user category may lead to a hardware sizing proposal that is significantly overdimensioned (factor 2x or 3x), it can indicate the upper limits of the requirements. Economically, however, the medium user category should be the default unless otherwise verified.
User-based sizing has some limits in accuracy. If the results are very large, they should be compared with the more detailed document-or transaction-based sizing approach, whenever possible.
Document-or Transaction-Based Sizing
Using an estimate of the quantity of business documents (or objects) to be processed is a more accurate sizing method for determining the servers' CPU configuration than a user-based approach. This method considers documents processed (transactions) by normal online dialog activity, batch processing, and other phases of high amounts of processing or document loading. Larger SAP R/3 systems and many Industry Solutions can only be sized using this transaction or document processing approach. It is best to supply both user-based and document-based sizing information in order to get the optimum sizing requirements proposal.
As shown in Figure 3-2
, documents (or objects) can be entered into the system by users during the daily online window, or via batch processing performed parallel or during the off-hours (nightly). Thus, it is crucial to clearly specify the hours or timeframes for the batch processing activity. If the online user load and batch processing run in parallel during the same timeframe, then the hardware sizing proposal increases to account for the additional load (higher peak). If the batch processing activity can be shifted toward times of lower or no user activity, then the peak workload may be less, requiring fewer hardware resources. The main benefit of using a document processing sizing approach is because the actual peaks can be more easily identified than with the user-based averaging sizing approach, resulting in a more accurate proposal for the hardware requirements.
Figure 3-2. Daily Processing Requirements桺eaks and Averages
In some cases, the batch load during off-hours is more resource consuming than the daily user load. A good example is the Point-Of-Sales upload process in mySAP.com for Retail. This is performed nightly after store closing time, along with the replenishment planning run, which needs to complete in time for the trucks to leave in the early morning hours. In most production SAP R/3 installations, however, it is the month-end processing that generates the largest batch processing load.
TIP
Sizing Based on Peak Activity Time Window
Regardless if a new or upgrade sizing, the basis for preparing a sizing or estimate of future demand is always based on peak activity timeframes. This peak timeframe can be during the day when online dialog activity occurs, or during other hours when batch input (from EDI, Internet, or other sources) activity occurs (see Figure 3-2
). For upgrade and resizings, this peak can be measured. For new sizings, a theoretical peak is computed based on the data provided within the user-based and document-based sizing methods.
The types of documents processed in the financial area include invoices, payments, GL journals, asset postings, internal cost allocations, and many more. Typical documents (or objects) processed for logistics include sales orders and inquiries, purchase orders and material movements, stock movements, orders for production, material requirements, planning runs, and many others. For Human Resources, payroll time recording and travel expenses are the common activities that generate documents.
A simple example (B) of document processing requirements could be
Financial documents (invoices, payments, etc.) of 100,000 per month with an average of three line items each during the main online timeframe (ex: 8am to 5pm);
Sales orders and inquiries of one million per month with an average of three line items each during the normal online hours;
Batch input of 7000 sales data documents six nights per week between 22:00 and 24:00 o'clock, also with three line items each (this could also be a point-of-sales [POS] upload into the main SAP R/3 system); and
Material purchase orders of 200,000 per month with six line items each during the normal online hours.
One of the first decisions to be made is in regards to the definition of online hours. In some countries, this may be 8 hours per day, 20 days per month. In other regions, there may be more days per week worked and fewer holidays, leading to an increase in the online window and a decrease to the average transactions processed per hour given the same processing volume.
TIP
Seasonal Peak Loads
The standard sizing approach assumes that the business-processing load is evenly distributed over the year. However, special seasonal dependent peaks may invalidate this assumption. Examples are companies that produce items for the Christmas or winter holidays, or publishers of schoolbooks who need to get their orders out shortly before courses begin.
For sizing purposes, it is assumed that each document or object has an average of three line items or sub-objects. If there are more than three line items specified, the document quantity will be normalized to equivalent documents with three line items each (400,000 material purchase orders with three line items each in example B).
TIP
Limits of Sizing Approaches桟ustomization
Although specifying the quantity of documents to be processed by the system is a more accurate sizing method, it also has some limits. Not all types of transactions can be captured in a theoretical sizing approach. The most common exceptions are customized transactions, or homegrown ABAPs (also Z_ABAPs). These are among the top causes of red lights in EarlyWatch sessions. Customized ABAP codes are not considered in a standard sizing because there is no way (without measuring) to determine their behavior or impact on the system.
The most common impact of customized code is a poorly tuned SAP R/3 system, with a significant increase in I/O activity on the database server (ex: unnecessary full table scans, etc.). In this case, the standard assumptions for a hardware sizing proposal will not match the requirements. In extreme cases, no amount of hardware can meet the needs of a poorly tuned system. If custom code must be included in a sizing, then its performance impact must be measured.
Sizing Users in the mySAP.com Environment
With the new role-based business scenario pricing model from SAP for the mySAP.com environment, a user-based sizing methodology becomes more difficult. With mySAP.com, the same user can perform transactions across multiple applications, including SAP R/3, BW, APO, and so on, depending on what has been implemented. Estimating how many low, medium, and high activity users there are across all of these application components is not trivial, and neither is there a lot of experience yet to provide rules of thumb. In addition, many of the Internet-based software components, such as the SAP Online Store and ITS, are sized with hits per hour instead of users.
The most reliable way to determine the CPU requirements of the server systems in the mySAP.com environment is to focus on the expected business transaction volumes, regardless of their source. For example, the volume of sales orders per day or month should still be predictable for the SAP R/3 system, regardless if they come from online users or from Internet software engines. If a large percentage of transactions on the core SAP R/3 system comes from external sources, such as from an Internet sales application, then estimating the peaks becomes the most important part of sizing activity. Standard sizing assumptions for peak utilization will not apply to these cases.
Load-Based Sizing
Upgrade or resizing does not use estimates of transaction or user-load data but uses measurements of the running SAP system's utilization levels (or current load). Measurements of peak utilization during critical transaction processing timeframes are required as baselines for upgrade and resizing efforts. This data is collected over a typical week or month, depending on what is agreed upon as a representative timeframe. Often the month-end closing is chosen because of the high batch and reporting activities.
SAP's EarlyWatch reports provide utilization of hardware resources, typically at one-hour time intervals. A useful tool to measure peak utilization of CPU and memory resources at five-minute time intervals is HP's OpenView MeasureWare, which is available on many OS platforms. For Windows NT/2000, the built-in performance counters can also measure the CPU utilization rates at smaller time intervals. An example of a more complete service for determining the growth rates of documents and resource utilization is HP's Capacity and Service Level Management offering for SAP.
Resizing
For a resizing estimate of the current system, and as a basis for an upgrade sizing, the following information is needed:
A list of the current server configurations, number and type of processors, memory, and operating system in the production system;
The peak CPU and memory utilization of the existing production servers;
The number of active users on the system, as monitored within the SAP R/3 system.
With this information, the servers' performance can be determined in terms of transactions per hour, or SAP's unit of measure, SAPS (described later), based on their CPU utilization. The ratio of power between the database and application servers can also be determined. In addition, the most important ratio of the number of transactions per hour (or SAPS) for each user can be determined. The result is a customer-specific user profile determined from the existing utilization of resources. This custom profile can be used to determine the new hardware requirements if additional users must be added to the system.
This resizing approach can also be used when the SAP R/3 release is changed. It cannot be used alone if adding new functionality to the system, because that changes the user activity profile determined in the resizing effort. An example load-based resizing is presented later in this chapter.
Upgrade Sizing
To upgrade an existing system with new functionality or modules, along with a release change and additional users, requires a combination of a load-based sizing and a new sizing. The load-based information is used to resize the existing hardware to an optimum level given the current utilization. However, to determine the impact of new functionality or modules used, the information about the delta or new requirements needs to be collected for the upgrade as if it was a new sizing.
Collecting the Data
The most difficult part in collecting good estimates of user and transaction-load data is finding the right person or team to provide this information. The IT manager is the best person to determine the IT infrastructure requirements based on the service levels needed. The typical IT manager is not exposed, however, to the business processing volumes; yet this is the most important information to collect for a reasonably accurate sizing.
When an SAP project begins, usually a team, either within the company or hired consultants, is responsible for the business process or functional implementation of the SAP application. The team members can best determine the expected numbers of users logged on the system. They also determine which release levels of SAP software are used, which business functions or modules are implemented, and which application configuration (or customizing) is planned. The managers in the various functional departments (finance, sales, purchasing, etc.) are the best persons to provide data about the existing business practices, volume of documents processed, or user quantities.
If the SAP system is already in production, the current load can be measured to help establish a baseline configuration. However, the additional planned load estimates must still be expressed in user numbers or documents to be processed, which is information usually supplied by the SAP functional team, not the IT organization.
The Sizing Questionnaire
The actual mechanics of recording the information needed for a user-based or document-based sizing can be done with the aid of a questionnaire. It is useful to have a written record of the input data even if online electronic tools are used to evaluate it. Hardware vendors and SAP all provide questionnaires of some sort. The basic sections of each questionnaire focus on gathering the user load, the quantity of transactions or business documents to be processed, as well as their timeframes. Sometimes the infrastructure requirements, including disaster recovery, availability, and networking, are covered as well.
Sizing Tools
There are many ways to process the given estimates of user numbers and document or transaction data. The requirements can be computed from the given data either manually or with the help of a tool. However, the number-crunching is not the value added part: The sizing method and business processes must be understood and explainable by the sizing consultant.
In very large SAP projects, the standard sizing tools and assumptions made, whether by SAP or by hardware partners, do not always apply. These require some level of expert sizing by an experienced consultant to improve the quality of input for the sizing tools (using a sizing tool without asking good questions may lead to a garbage-in/garbage-out situation).
SAP QuickSizer
For the standard sizing cases, SAP created an online web-based sizing tool called the QuickSizer, available on the mySAP.com Marketplace web site, www.sap.com or service.sap.com. (Understanding the principles and limitations of this tool is necessary for proper usage.) This online sizing tool can be used to enter and process the numbers of users per module and the business document volume data. This can be used for the current release of SAP R/3, for a few mySAP.com Industry Business Units (IBUs), and for a limited set of mySAP.com application components. The SAP QuickSizer is purposely designed for the common sizing cases. It was not originally designed as an expert-sizing tool for all situations. Thus, sizing consulting help from the hardware vendors is still a worthwhile investment. The theory and algorithms behind the computation of the CPU, memory, and disk capacity requirements are updated by SAP on a regular basis and are published in various papers, available at the same web address as the QuickSizer.
Hardware Vendor Tools
Several hardware vendors provide methodologies and tools for collecting (questionnaires) and processing the information. Their sizing tools are usually aimed at supporting their sizing consultants for offline usage directly with the customer. Sizings can be made with older SAP R/3 releases to help with resizing or upgrade sizing activities. The SAP QuickSizer only supports sizings for the current SAP R/3 release. The hardware vendors' sizing approaches are well adapted to the presales phase when no running system can be analyzed to gather data.
Computing the Requirements
The factors that influence the throughput and response time of the SAP system include both the customer requirements as well as the hardware and software versions chosen. The focus of this section is on determining the customer requirements, expressed in both the throughput and the response times needed (see Figure 3-3
).
Figure 3-3. Factors That Impact Performance
Benchmarks and Load Factors
Because it is not possible to measure all combinations of hardware platforms with the SAP software applications and modules, the basis for comparison is the normalization of the resource demand of the various modules. These are the relative performance weighting factors, or load factors. For an SAP R/3 system, each module is assigned a load factor. For example, the modules FI, MM, SD, and PP are assigned load factors relative to each other based on the benchmark results. An FI user requires less CPU resources than an SD, MM, or PP user. These load factors are release dependent. SAP publishes the user-based sizing load factors in its 揂lgorithms for the SAP QuickSizer�paper available on the mySAP.com Marketplace web site.
SAP makes benchmarks available for most of its SAP R/3 application modules. Based on these performance tests, benchmark load factors can be derived for each module in relation to a standard. A benchmark user is not a real user, however. The SD benchmark uses only a few of the possible SD transactions available. Most SAP R/3 implementations for SD are customized with more functionality so that its user-based sizing load factor is higher than the benchmark one. For example, the SD user-based sizing load factor is 5 but its benchmark load factor is ~2.5 (for sizing purposes). For modules with less functionality, such as FI, the benchmark load factor is the same as the one for user-based sizing.
The load factors for user-based sizing are recommended values. Changing these to higher values can be done if the application consultant providing the sizing data specifies additional functionality used (application hot spots). In addition, the recommended load factors used for sizing may change from release to release of SAP R/3.
The load factors used for user-based sizing already consider some typical customizations of the SAP R/3 module functions and processes, which is why, for example, SD user load factor is higher than its benchmark load factor. |
Table 3-1
shows the user-based sizing load factors for the FI, MM, and SD modules. Since SAP R/3 release 4.6, SAP has increased the load factor for SD relative to all other modules by 10%. Given that SD is the basis (constant) for SAP's sizing methodology, the load factors for the other modules relative to SD have essentially been decreased by 10%.
SAP R/3 Release(s) | FI | MM | SD |
|---|---|---|---|
3.x, 4.0, 4.5 | 1.0 | 3.0 | 5.0 |
4.6B | 0.91 (= 1/1.1) | 2.73 (= 3/1.1) | 5.0 (constant) |
With SAP R/3 releases 3.x through 4.5, the sizing mathematics used nice round numbers (1, 3, 5, etc.) because they were essentially based on FI, which had a standard load factor of one (1). However, because SAPS are based on SD, and SD functionality has changed significantly over time, the sizing load factors had to be adjusted.
Application Hot Spots
Many of the SAP R/3 modules can be implemented with additional functionality not accounted for in the standard load factors. This is referred to as functionality hot spots. For the SD module alone, there are many of these, including functions and processes such as:
Online availability check and pricing
Product Configuration
Dynamic Credit Checks
Production Planning Orders and BOMs (Bill of Materials)
Batch Determination
There are many other functionality hot spots, which application consultants are best able to identify. The performance impact of these hot spots can range anywhere from 20% to 200% or more of additional load. In some specialized cases, the additional load can be over 1000%, or ten times the existing functionality. The important point is that if specific functionality is to be used, it should be included in the sizing estimates. This is typically done by increasing a module load factor by an estimate based on experience with the new functionality.
Measuring Customized Code
To measure specific code or functionality, there are two options available. Mentioned previously, a customer performance benchmark can be made on a server and data configuration that is representative of the final production volumes.
A lower cost alternative is to simply measure the CPU time for each dialog step in the specific business process on a particular server and disk platform. This can be compared to the benchmark software configuration, which then allows a load factor to be developed for that function or process. This method can be used in addition to the larger performance evaluation to help predict its outcome. For more information about customer performance tests, refer to SAP's whitepaper 揅onducting Customer Performance Tests.�/p>
Once the custom load factor is determined, it can be used as input in the document-or user-based sizing methods.
Response Times and CPU Utilization
The response time is how long the system takes to reply once a dialog screen is submitted for processing. Response times are important to keep low during the online dialog processing time window, typically from 8am to 6pm daily, depending on the organization.
The average response time in an SAP R/3 system only measures the round-trip travel time from the application server to the database server and back to the application server. It does not include the travel time or delay across the public network to the user's workstation or PC, or the multiple communication steps between the latest SAPGUIs and the application servers. The network chapters (Chapters 7
�a href="0130280844_cnode77.html">
11
) cover network design for SAP in more detail.
The standard average response time for sizing proposals is less than two seconds. In order to keep the response time this low, the system's CPU utilization should be less than 70%. This is the knee in the performance curve for most SMP servers where additional load causes longer response times. Figure 3-4
shows the typical response time pattern of single and multiprocessor servers.
Figure 3-4. Response Time and CPU Utilization
Assumptions for CPU Utilization
For user-based sizings, where only the average user workload can be determined (no peaks), the SAP QuickSizer uses 33% CPU utilization. The remaining CPU utilization is reserved for peaks generated by users and used to keep response times below two seconds. For document-or transaction-based sizings, where the peaks are known or more directly accounted for, the SAP QuickSizer uses a 65% CPU utilization factor.
Some hardware vendors may use different CPU utilization levels in their sizing methodology based on their experiences on their particular hardware platform. Hewlett-Packard, for example, uses the CPU utilization level of 70% or below for document-or transaction-based sizing. The approaches are similar, especially considering that there is no such thing as an ideal sizing approach.
Response Time Limits
A proposal can be made for a system with less than one-second response time, as long as the CPU utilization assumptions used to determine the hardware are adapted. This leads to an increase in the hardware requirements. However, this can only be estimated based on standard functions and processes (not customized code), and not below a certain minimum response time.
TIP
Recommendation: Two CPUs Minimum
From Figure 3-4
, it is evident that a single processor has a higher response time than two or more processors, even at lower utilization levels. This is one of the primary factors for the recommendation to always use at least two processors in a production SAP application or database server, even if one CPU could handle the required throughput.
Throughput Units of Measure
Throughput is the volume of transactions that are processed within a given amount of time. It is important to have high throughput whenever limited time windows exist or when peak periods of online dialog usage occur. Although the throughput could be high for a system running at 100% CPU utilization, the response time for a logged-on user would be unacceptable (see Figure 3-4
).
Throughput of an SAP system can be expressed in terms of transactions per hour processed. SAP created a hardware independent unit of throughput measure called SAPS. One hundred SAPS are equal to 6000 SD dialog steps or 2400 SD transactions per hour. The throughput a particular server configuration can achieve is release dependent because the SD functionality changes for each SAP R/3 release.
One SAPS = 24 SD transactions per hour One SD benchmark user = 5 SAPS |
What are SAPS? Thinking in terms of SAPS per user is not so easy. Therefore, an additional way of expressing throughput is in standard transactions per hour (formerly FI-Txn/Hour) that have a normalized load factor of 1.0. To convert the number of SAPS into standard transactions per hour, simply multiply by the SD benchmark load factor of 2.5 and by 24 SD transactions per hour. One SAPS equals 60 standard or normalized transactions per hour (1�.5�4). This may be useful when comparing hardware vendor sizing proposals.
Alternatively, Dialog Steps per Hour can also be used to express throughput. The benchmark ratio between SD dialog steps and SD transactions per hour is 2.5 (6000 dialog steps divided by 2400 SD txn/hr). So one SAPS equals 150 SD dialog steps per hour (1�.5�.5�4).
User Activity Levels桾xn/Hour
The activity level in transactions per hour (txn/hr) of an SD benchmark user can be determined by referencing the definition of SAPS. If 1 SD benchmark user is equal to 5 SAPS, and 1 SAPS is equal to 24 SD transactions per hour, then 5 SAPS equals 120 transactions per hour (5�4). The high user for sizing has the same activity level as a benchmark user, or 120 txn/hr. A medium user would have one-third the amount, or 40 transactions per hour, and a low user one-tenth of a medium user, or 4 transactions per hour.
Sizing Examples
In order to illustrate the theory of how the business requirements are computed, a few examples are provided next.
Standard Sizing
A simple way to perform a user-based sizing is to estimate the number of users active on the system and multiply this by one single, average load factor across all of the modules or functions used. For example, if the first implementation is only using the financial modules, then a load factor between 2 and 3 might be appropriate. For the logistics functions (except production), a load factor between 4 and 5 is appropriate. A load factor of 5 or more is appropriate when using the production planning module. (Note that the individual module load factors for user-based sizing are published by SAP and are subject to change.)
To illustrate this method, we can build upon the user-based sizing example (A). There were 170 medium users specified with financials and logistics. With an average load factor of 4 and 40 txn/hr for medium users, we would achieve 27200 standard transactions per hour. Converting this to SAPS (divide by 2.5 and by 24) gives 453 SAPS as the business processing requirement for online dialog activity at 33% CPU utilization. Because SAP's QuickSizer states all SAPS requirements at 100% CPU utilization, the result divided by 33.3% gives 1360 SAPS.
The computed result of 1360 SAPS at 100% CPU utilization for the business requirements is release independent. This is because a standard load factor across all modules was chosen and is not expected to change significantly because of the large amount of SD users (SD is the reference load factor in SAP's sizing methodology across all releases). If the mix of SAP R/3 modules in this sizing example would shift significantly away from SD, then the average load factor would change, depending on the release.
User-Based Sizing per Module
Table 3-2
presents the user-based sizing example (A) with 10 low and 20 medium users for FI, 100 medium users for SD, and 50 medium users for MM. The goal is to find out how many SAPS or standard transactions per hour these users and modules represent.
R/3 Module | Number of Users | User Activity Level | R/3 4.6 Module Load Factor | Standard-Txn/hr Result |
|---|---|---|---|---|
FI | 10 | Low (4 txn/hr) | 0.91 | 36 |
FI | 20 | Medium (40 txn/hr) | 0.91 | 728 |
SD | 100 | Medium (40 txn/hr) | 5.0 | 20000 |
MM | 50 | Medium (40 txn/hr) | 2.73 | 5460 |
�/FONt> | �/FONt> | Standard (LF = 1) Txn/hr= | 26224 | |
�/font> | �/fONT> | Total SAPS at 33% CPU Utilization [a] = | 437 | |
�/FOnt> | �/font> | Total SAPS at 100% CPU Utilization [b] = | 1311 [c] | |
[a]
To convert standard txn/hr (load factor \u-4043 1) to SAPS, divide them by 2.5 SD benchmark load factor and by 24 SD txn/hr per SAPS.
[b]
SAP QuickSizer results are always stated at 100% CPU utilization (multiply by 3).
[c]
This result is the same as SAP QuickSizer's (4.6) result of 262 SD BM Users (divide by 5).
The load factors must first be determined based on the SAP R/3 release. The ones for SAP R/3 release 4.6 can be used as listed in Table 3-1
. With the user quantities and profiles for each SAP R/3 module, plus the module load factors, the equivalent standard transactions per hour (txn/hr) can then be determined.
Notice that the requirement computed is similar to the previous standard sizing result (1311 versus 1360 SAPS) where only a general logistics load factor was used. This is because there are only a small number of users and most of the heavy usage is in the SD module. With a larger quantity of users across different modules, the more accurately computed load factor across the modules can make a significant difference in the CPU requirements. In addition, the 1311 SAPS result equates to 262 SD benchmark users (divide by 5).
An important question to ask is about the activity level of the users. In both our user-based sizing examples, active users were assumed based on SAP's definitions. The sizing result would be different if these users were named or licensed users, or logged on but not all active at the same time. It is important to agree upon the user activity levels to get equivalent hardware requirements sizing proposals from the various hardware vendors.
Document-or Transaction-Based Sizing
Table 3-3
presents an example of a document-based sizing to determine the CPU requirements. It is important to collect the quantity of documents to be processed and the timeframe in which they need to be processed. This is used to determine the peak processing periods. Only the highest peak is then used to determine the sizing requirements.
Type of Documents Processed | No. of Documents per Period | Avg. No. of Line Items | R/3 4.6 Module Load Factor | Peak | Daily Timeframe Std-Txn/hr [a] | Nightly Timeframe Std-Txn/hr [b] |
|---|---|---|---|---|---|---|
FI Invoices, Payments | 100,000 per month | 3 | 0.91 | +75% | 995 | �/font> |
SD Orders (batch) | 500,000 per month | 3 | ~5 | +75% | 27344 | �/Font> |
SD Sales Data Load | 7000 in 1 hour month | 3 | ~5 | +0% | �/Font> | 35000 |
MM Purchase Orders | 200,000 per month | 6 | 2.73 | +75% | 11943 | �/foNt> |
�/Font> | �/Font> | Total Standard (LF 5 1) Txn/hr = | 40282 | 35000 | ||
�/FONT> | �/fONT> | Total SAPS at 65% CPU Utilization [c] = | 671 | �/foNt> | ||
�/Font> | �/Font> | Total SAPS at 100% CPU Utilization [d] = | 1032 | 583 | ||
[a]
The average daily workload assumes 8 hours per day,20 days per month,which is specific.
[b]
The nightly workload is computed based on the timeframes speci ?ed for the batch processing. This is usually sized at 100% CPU utilization.
[c]
To convert standard txn/hr (load factor 1)to SAPS,divide them by 2.5 SD benchmark load factor and by 24 SD txn/hr per SAPS.
[d]
SAP QuickSizer results are always stated at 100% CPU utilization.
With the data provided in Table 3-3
, the sizing requirement can be determined by averaging the monthly (or yearly) load down to an hourly transaction load for the online (daily) timeframe. With straight averages, however, a peak factor must be added unless other data is provided, such as batch processing or high-load phases. The minimum peak factor to consider is an additional 75%. A higher peak factor can be applied with knowledge of functionality hot spots. The daily workload can then be compared to the nightly batch processing, which is already provided as a peak workload quantity (also known as a high-load phase). Only the greater of the two is used to determine the hardware requirements. In addition, dialog and batch processes are considered to have the same effect on the CPU requirements, only the think times are different. (Note: The nightly batch process is typically configured to consume 100% CPU utilization on the application server.)
The average number of line items or sub-objects is commonly difficult to estimate during the initial sizing evaluation. Unless otherwise known, the default values are usually adequate for an initial sizing estimate.
TIP
Combining Averages and High-Load Phases
If data is available to specify high-loading phases during the day, or with parallel batch processing during the day, these are added by default to the computed average from user-based sizing. In some cases, however, they should be used in place of the user-based sizing values. The goal is to determine the peak processing period during the day by analyzing the individual timeframes. A sizing consultant can help determine which combinations of user-based averages and high-load phases to include in the sizing analysis and to help verify that regardless of which tool is used, the correct peak is computed. Otherwise, a much larger or insufficient hardware configuration may result.
The SAP QuickSizer's algorithms for document quantity-based sizing calculations are more complex than the simplified approach shown. SAP uses load factors for each individual transaction or document-processing step that differ from the standard user-based module load factors based on measurements using a reference server. Theoretically, this can provide even more accuracy for the quantity structure-based sizing. The method shown here may be less accurate, but it is a reasonable approach for handling document-or transaction-based sizing data without depending on a tool.
Master Data
Although not shown in the example, changes to master data may also need to be factored into the computation for the average hourly processing requirements (which the SAP QuickSizer does not consider). In some cases, the changes to master data can represent a significant volume of transactions.
ALE, Interfaces, Extractors
When sending documents from one SAP R/3 system to another, Application Link Enabling (ALE) is used. To size for the impact of ALE usage, SAP recommends adding 10% to the number and type of documents being sent. For example, if the 100,000 sales orders are sent per month, assume 110,000 in the sizing due to ALE. If only user-based sizing data is available, add 10% more users to the SAP R/3 module that contains the documents being sent. The additional communication load due to ALE is added to the sending system. The receiving system is sized with the incoming quantity of documents in the normal sizing method without the special communication uplift.
Other communication requirements or interfaces, such as BAPIs, iDOCs over xRFC to/
from a BBP system, for example, file transfers, and so on, generally require 10% additional resources. However, this 10% is applied specifically to the volume of documents/objects being transferred or to the respective SAPGUI transactions. The extra 10% for communication overhead is not applied across the board to the entire system.
Data extractors are software programs in the SAP R/3 system (known as plug-ins) that manage the extraction of data from the SAP R/3 OLTP system into other systems, such as SAP BW and APO. Depending on the volume of data being extracted and on the timing, this may have a significant performance impact on the SAP R/3 database server. For most cases, data extraction is scheduled in the off-hours or slower periods of the day. In the larger congurations, where the SAP R/3 database server is already at its limit, there are few good timeframes available to use for extraction.
For most SAP landscapes with SAP R/3 and SAP BW systems, for example, SAP expects there to be no overall loss in performance on the SAP R/3 OLTP system due to data extraction. The increased extraction I/O is balanced out by fewer reports being run on the SAP R/3 system due to increased usage of reporting functionality in SAP BW. This depends highly on the customer's SAP BW and SAP R/3 implementation.
Other mySAP.com Business Applications
This chapter has so far focused only on the sizing aspects relevant to SAP R/3, the OLTP business application component in the mySAP.com environment. SAP, however, has a few other business applications.
mySAP.com Industry Solutions
The mySAP.com Industry Solutions have special business processes to consider, but they leverage the core sizing methodology of estimating users, business documents to be processed, peak workload, and the server hardware's release-specific SAPS. To support the specialized business process requirements, separate questionnaires are available for a few of them, such as mySAP.com for Retail, Utilities, and others. Most others, however, are simply sized based on the core logistics or financial modules already present in SAP R/3.
The SAP QuickSizer has a special section for the Industry Business Units (IBUs), however this is presently limited to Utilities and Retail. The key items to consider when sizing IBUs are the additional workload (or documents to be processed) on the core SAP R/3 modules, the release the IBU is based on, as well as the IBU-specific processes.
SAP Business Information Warehouse (BW)
A standard OLTP application is focused on data entry, which places the most workload on the application itself. The OLTP scaling is directly proportional to the database server's power. Data warehousing with OLAP, however, is focused on reporting and analyzing the data, which places most of the workload on the database server.
Sizing a data warehouse system like SAP BW is very different from determining the OLTP business processing requirements for SAP R/3. Although an initial sizing may be possible, there are so many variations, making a standard theoretical approach difficult. The ideal way to size an SAP BW system is with actual data from an SAP BW project.
The SAP BW sizing method available on the SAP QuickSizer is a simple user-based approach to help determine which of the standard sizing configurations apply. These range from an extra small (XS) 2-way server to an extra large (XL) client/server configuration with 8-way or larger servers. These are useful only to help get the SAP BW project started.
The user data sizing result is computed in terms of normalized SAP BW users, which the hardware partners can use to determine the configuration of application servers needed (CPU and memory). SAP BW users are logged on to and run queries and reports from the application servers. The application server's CPU and memory configuration plays an important role in the overall query response time.
What determines the database server's CPU, memory, and disk configuration is the quantity and complexity of the data modeling and the data loading requirements. The number of the Infocubes and the number of dimensions in each are the primary factors in determining the disk capacity requirements in an SAP BW system.
SAP Advanced Planner and Optimizer (APO)
The SAP APO component can be used to offload the planning activities (CRP and MRP) from the SAP R/3 system. These planning runs are essentially large batch processes, which are dependent on how many items to process, their level of detail, and relationships (such as BOM) to other items. The important processes are demand planning, supply network planning, and production planning and scheduling. SAP has one sizing questionnaire to collect information about all of these processes.
The important elements to size for are the database volume size, the database and application server's CPU and memory configurations, as well as the liveCache's CPU and memory configuration. Again, the SAP QuickSizer presents a simple sizing approach using the small, medium, and large server configurations, which scale from 1� users and an all-in-one-box to over 50 APO users with three or more separate servers. An important consideration when starting out on an APO project is to use servers that have headroom to upgrade both memory and CPU. Some hardware vendors may have more experience with APO benchmarks, making a more exact sizing possible.
mySAP.com Workplace Server
The important parameters for the mySAP.com Workplace Server are the total number of logged-on users for the memory and disk sizing and the maximum number of users logged on in one hour for CPU sizing. These users are sized at one-fourth of a low user with the BC module load factor. The throughput result is measured in SAPS or equivalent transactions per hour.
Internet Transaction Server (ITS)
Sizing the SAP ITS is a matter of determining the number of hits per day (or second) expected on the web site, and the number of active users accessing SAP R/3 through the ITS. SAP has published a paper with measurements where a single Intel PentiumPro 4-way 200MHz server achieved 60 hits/second in an environment with single SAP R/3 4.0B system. (An 8-way 550MHz Intel-Xeon server has over four times the processing power.) The actual ITS performance will differ with each release and with the complexity of the environment. HP's experience with ITS and BBP have shown that up to twice the hardware may be needed than recommended in SAP's original ITS sizing document.
Other Applications or Components
SAP publishes sizing papers for a few other mySAP.com business application components, including SAP CRM, SAP SEM, and others. Because many of these components are new to the market, the sizing experience is limited and based primarily on laboratory measurements. However, if the components have an SAP kernel, their sizing requirements very often can be expressed in throughput terms similar to SAP R/3 (SAPS or equivalent transactions per hour).
| I l@ve RuBoard |
No comments:
Post a Comment