An overview of Quick Sizer and Quick Sizer Design Guidelines
The goal of sizing is to plan hardware expenditures required to run SAP software. Hardware requirements can be expressed in terms of CPU processing power, projected disk growth, memory and network for WAN connections. When analyzing a productive system, you quickly learn that roughly 20% of all transactions account for 80% of the capacity requirements. SAPs sizing guidelines take this ratio into consideration: the Quick Sizer and its related guidelines help you transform information about your most important business processes into high-level requirements for CPU, memory and disk.
The Quick Sizer is an online application on the SAP Service Marketplace that consists of a questionnaire and provides two sizing methods, user sizing and throughput sizing for customers and partners. If information about your planned SAP implementation is limited and you do not have more than 200 concurrent users, we suggest a user-based sizing. If you have more detailed knowledge of the mySAP Business Suite and how you plan to implement it, throughput sizing is the recommended option. Since throughput sizing requires more detailed information, it yields more accurate estimates of the hardware resource requirements.
SAP has derived the sizing guidelines implemented by the Quick Sizer by measuring the hardware resource consumption of realistic business processes. This is achieved with the help of SAP Standard Application Benchmarks, in-house measurements at SAP, and actual customer system experience.
Sizing is done on the basis of sizing elements, i.e. business objects or transactional documents that are the result of a business transaction in SAP software. For example, in the course of a standard Sales & Distribution (SD) process as defined in the SAP SD standard application benchmark, the following business objects are created and thus can be sized in the Quick Sizer: customer order, delivery note, goods issue, and billing document. Each sizing element is associated with particular hardware cost factors such as CPU, memory or disk. Lets look into these cost factors in a bit more detail.
1.1 Sizing the CPU
Both the user sizing and throughput sizing calculate the CPU resource consumption.
In the user sizing, the Quick Sizer assumes a certain CPU load depending on the business process and the user activity. This is a rather broad approximation but it makes the sizing very easy.
The more detailed method is the throughput sizing. To determine the CPU requirements, the Quick Sizer needs to know the number of sizing relevant objects, their size, and the time frame in which they are being processed. The number of data changes and displays also influences this processing power.
To make the sizers life easier, the Quick Sizer makes a number of assumptions, for example, it does not distinguish between document processing in background or in dialog mode. Also, it calculates the same CPU consumption for “creating with reference” and without reference. Possible optimizations for mass processing, for example, in invoicing or goods movement, are not taken into consideration. That way, the assumptions are more expensive in some cases, and less expensive in others.
The result for CPU sizing is divided into requirements for the application and the database layer and is specified in SAPS (SAP Application Performance Standard), rather than GHz. SAPS is a hardware independent CPU performance unit devised to describe the throughput power of a server, as CPU measurements are highly configuration dependent. It refers to the SD standard application benchmark (www.sap.com/benchmark): 2,000 fully business-processed order line items per hour equate to 100 SAPS.
This is important to know because the number of SAPS a specific configuration can achieve may change between releases. If, for example, the resource consumption of release B differs from that of release A the number of line items processed by the configuration will change, and the number of SAPS will be different, too. For example, a configuration that delivered 10,000 SAPS in release A will deliver 9500 SAPS in release B, if release B has a 5% higher resource consumption.
At www.sap.com/benchmark SD you can view sample configurations and the number of SAPS they have achieved.
1.2 Sizing the Disk
The disk size calculation in user sizing is analogous to that of CPU consumption. That means, the Quick Sizer assumes a specific disk value per user and workday. In throughput sizing, disk growth is determined by the number of objects per year, their size and the length of time they will remain in the system before they are archived.
The following data instances that potentially have a certain influence on the disk size are considered as exceptions and are therefore disregarded:
- System source data defined by the minimum system requirements
- Objects that reside in the system for a very short time only. Typically this includes “intermediate” or temporary data such as Idocs, WORKFLOWs, SPOOL jobs, batch input jobs, job logs, data that is deleted automatically, purchase requisitions, planned orders created by the Materials Requirement Planning run, incompletion protocols and due lists created by an order.
- Master data usually does not contribute greatly to the overall disk sizing. In general, preference should be given to document type data because they are larger. If very large master data exists, we recommend an expert sizing where actual custom data are analyzed.
In the disk sizing method the Quick Sizer ignores tables which are either small or rarely used, hardware dependent table compression and custom tables and indexes.
For reasons of better disk growth analysis, the Quick Sizer provides information about data archiving possibilities, such as projected disk growth after one year, after the retention period, and information, if archiving objects are available.
1.3 Sizing the Memory
In general, the highest contributor to memory consumption is the memory required by online users. System settings such as buffers and caches may also influence the memory requirements of the application server. To account for this, the Quick Sizer assumes one application server as a memory offset and adds the user specific memory requirements according to your entries. In Java applications, the memory required by Garbage Collection also plays an important role and therefore is included in the Quick Sizers memory sizing. The liveCache, which is used for business planning purposes, basically only consists of memory.
In user-based sizing, memory requirements are determined by the net consumption of the online users. All other memory requirements, for example those of the operating system, need to be added when the final configuration or system landscape is planned.
In general, only user sizing provides memory sizing, with the exception of the Java application Enterprise Portal and the Advanced Planner and Optimizer (APO) whose liveCache is driven by memory. These throughput sizings also yield memory requirements
For more information on sizing see service.sap.com/sizing (Service Marketplace ID required).