Businesswoman presenting Benchmarks on graphical screens

Sizing

Sizing means determining hardware requirements such as memory, CPU power, disk space, I/O capacity, and network bandwidth. It is an iterative process to translate business requirements into hardware requirements, and is usually performed early in the project.

Hardware sizing decision tree

Performance & Scalability

The sizing decision tree guides you through your next sizing project. Depending on your needs, you will find helpful information and links. If you can’t find appropriate information in the decision tree, please don’t hesitate to contact us.

Greenfield Sizing

Sizing of a new SAP applications from scratch.

Brownfield Sizing

If you have an SAP system running that you want to extend with new functionality (delta sizing: brownfield and greenfield approach) and/or add new users (re-sizing) or migrate to SAP HANA perform brownfield sizing.

Cloud Sizing

If you want to conduct a sizing for applications which are running in the cloud.

Sizing FAQs

Have a look at the sizing and Quick Sizer FAQs if you want to learn more about sizing and Quick Sizer.

Learn more about hardware sizing

Get to know the most common sizing terminology.

Sizing a certain SAP application (Search)

Use the Search function that in integrated in Quick Sizer.

About hardware sizing

Sizing means determining the hardware requirements of an SAP System such as network bandwidth, physical memory, CPU power in SAPS, and I/O capacity. The size of the hardware and database is influenced by both business aspects and technological aspects. This means that the number of users using the various application components and the data load they put on the network must be taken into account.

Sizing FAQs

Sizing translates business requirements into hardware requirements based on assumptions. That means determining the hardware requirements of an SAP System such as network bandwidth, physical memory, CPU power, and I/O capacity. The size of the hardware and database is influenced by both business aspects and technological aspects. Therefore, the number of users using the various application components and the data load they put on the network must be taken into account.

SAP offers standard sizing methods and tools for SAP solutions: Depending on the solution, SAP provides t-shirt sizings (simple algorithms with many assumptions), formulas (simple or more complex), questionnaires without formula (for structured questions), Quick Sizer (based on users and throughput), performance monitoring, and customer performance tests. You can perform greenfield and delta sizings with Quick Sizer from SAP, a web-based tool developed in close cooperation with SAP’s Technology Partners. Using the Quick Sizer is free of charge and offers you links to SAP’s Technology Partners.

SAP Application Performance Standard (SAPS) is a hardware-independent unit of measurement that describes the performance of a system configuration in the SAP environment. It is derived from the Sales and Distribution (SD) benchmark, where 100 SAPS is defined as 2,000 fully business-processed order line items per hour.

In technical terms, this throughput is achieved by processing 6,000 dialog steps (screen changes), 2,000 postings per hour in the SD Benchmark, or 2,400 SAP transactions.

In the SD benchmark, fully business-processed means the entire business process of an order line item: creating the order, creating a delivery note for the order, displaying the order, changing the delivery, posting a goods issue, listing orders, and creating an invoice.

Please note:

SAP introduced a new unit to measure the performance of an SAP system, called aSAPS (advanced SAPS) which is a consequent evolution of SAPS. aSAPS are based on the SAP quote-to-cash (Q2C) benchmark, where 100 aSAPs are defined as 2,000 fully processed business order line items per hour in combination with the execution of two OLAP queries per hour. For more information, please have a look here.

User of the Quick Sizer have the option to display the CPU sizing result either in aSAPS or in SAPS. This can be done both under “Project Information” and on the “Result Page”. Please note: On the “Result Page”, you can change whether the results shall be displayed in SAPS or in aSAPS. But the initial decision which was taken on the “Project Information” page cannot be changed on the “Result page”.

Check http://sap.com/benchmarks for more information.

The SAP Business Units are responsible for providing standard sizing guidelines. SAP´s Hardware Partners are still responsible for the final sizing and configuration of the hardware systems. SAP teamed up with the SAP Technology Partner to develop a joint sizing tool. The Quick Sizer collects all hardware-neutral input parameters and thus simplifies the sizing process. In between the following groups different roles may need to perform (at least a greenfield) sizing: SAP Sales, Consulting, the implementation partner, the customer’s IT basis team.

Unfortunately, sizing is not an exact science. The more accurate the input to the sizing tool, the greater the accuracy of the overall result and thus your configuration will be. Sizing is not a one-time job, but an iterative process. Invest time in re-evaluating your sizing. This time will be well spent and can result in a higher degree of accuracy for your productive system.

The results stem from measurements on various operating systems undertaken by SAP and its Technology Partner. To make sure that the results are valid for different platforms, the results are no exact figures, but rather categories. It is the task of the respective Hardware Partner in partnership with the customer to determine the exact figures. The operating system is not an input variable in Quick Sizer.

There are several solutions that are not covered in Quick Sizer itself. However, for most industry solutions we have sizing guidelines on how to size them. We will gradually extend the Quick Sizer with new components.

Sizing is always based on the most current level of the SAP solutions. An SAP ERP upgrade sizing can be handled applying following SAP Notes:

1723135 - Resource requirements for SAP ERP Central Component 6.0 EHP6

1974405 - Resource requirements for SAP ERP Central Component 6.0 EHP7

For the Quick Sizer, post go-live sizings (except delta sizing of new SAP solutions) are out of scope. The release is not an input variable in the Quick Sizer, but there is a high dependency on the SAP ECC Release. Ideally, Quick Sizer is based on the most current SAP version. Check also the sizing decision tree for this topic.

There are two different widely independent performance KPIs for systems - throughput and server response time for single processes.

Systems are designed and optimized for highest throughput or fastest response times or lowest power consumption or other features such as RAS (redundancy, availability, serviceability). The combination of characteristics with every hardware is unique.

In order to increase the awareness, SAP has introduced the new KPI Single Computing Unit performance (SCU performance). To be as hardware neutral as possible and due to virtualization technologies SAP uses the term Single Computing Unit performance instead of Single Thread Performance.

There are some SAP applications that benefit from a good Single Computing Unit performance of the application server. This is especially valid for SAP CRM, SAP SRM and some business processes in SAP EWM. When sizing one of these SAP applications, customers should discuss this topic with their hardware partners. Hardware partners should make sure that the Single Computing Unit performance of the planned system is sufficient to fulfill the response time expectations of their customers.

For more information check SAP note 1501701 and the HANA Quick Sizer Rough Guide.

  1. Even in a virtualized environment, sizing will remain important and necessary, e.g. to determine the size of your virtual and physical server and/or to determine peaks to plan moves of virtual systems.
  1. In a consolidated environment it is essential, to not only measure the system load within the single system. Instead it is essential to relate the measurements to the overall load situation of the physical server. Each system might be influenced by its neighbor systems, so that bottleneck investigations of a single system always require sanity checks on the other systems. This kind of effects might be found in aspects of system operation (file system performance and latency, network bandwidth and latency, CPU and memory resources).
  1. In general, with virtualization you can realize cost savings because of load balancing and system/server consolidation. Therefore, you can realize savings in terms of energy and cooling.
  1. For the right virtualization strategy, you should get in touch with your hardware vendor.
  1. In a consolidated environment you can add or increase services, as long as there are still computing resources available and as long the system is still able to respond within the expected response characteristics. Since SAP systems are typically sized for peak utilization the co-location of services on the same server will often lead to a lower utilization than expected (especially, if peak situations occur at different point-in-time. This is only valid for the CPU, not for the memory. The same amount of memory that was sized for a non virtualized landscape must be also available in your virtual environment (there should be no swapping in a virtualized environment). Therefore, in a virtual environment the memory is more often the bottleneck than CPU and disk.
  1. There is an overhead through virtualization which means that more hardware is needed (for the overhead of the virtualization software), however there are possibly potential cost savings through virtualization (e.g. CPU over-commitment). First experience and measurements have shown that approx. 10% of additional resources are needed for the virtualization software. Please note that it depends heavily on the workload. The overhead might be much higher for particular cases.

Quick Sizer FAQs

Quick Sizer is a Web-based tool designed to make the sizing of the SAP solutions easier and faster. It has been developed by SAP in close cooperation with all platform partners and is free of cost. With Quick Sizer you can translate business requirements into technical requirements. Simply fill in the online questionnaire, an up-to-date survey that is based on business-oriented figures. The results you obtain can help you select an economically balanced system that matches your company's business goals.

The purpose of Quick Sizer is to give customers and prospects an idea about the initial hardware size of the system necessary to run the proposed workload. Quick Sizer calculates resource categories for memory, CPU, disk size, and disk I/O. Configuration or landscaping is out of scope.

Precondition is to have a valid customer number.

For a greenfield sizing, proceed as follows:

  1. Call Quick Sizer (HANA-based, HANA-based Cloud, non-HANA-based)
  2. Create a sizing project with the relevant information, such as number of users
  3. Get an initial result for memory, CPU,  and disk
  4. Possibly apply additional guidelines on top
  5. Check for sample configurations on HANA Hardware Directory and  at www.sap.com/benchmark
  6. Provide hardware vendor with Quick Sizer project name (and additional guidelines, if desired)

All sizing guidelines can be found on www.sap.com/sizing.

Many key performance indicators are extremely hardware-dependent. SAP has close cooperation models with a multitude of hardware and technology partners. The sizing estimates can be turned into an actual hardware recommendation by a specific hardware partner that really satisfies your needs. 

You find more background information here.

Please create an OSS message using component XX-SER-SIZING

You can set archiving flags for sizing elements on Quick Sizer questionnaires. If the flag is set, Quick Sizer checks, whether a corresponding archiving object exists. If the flag is set and there is no corresponding archiving object, the system displays an information message. If there is an archiving object, you get the name of the archiving object on the result page (levels "Results, statistics, inputs" and "Sizing elements").

Setting of the archive flag does not influence the calculation of Quick Sizer.

Check also further information about data archiving in the HANA-based Quick Sizer.

Quick Sizer should only be used for Greenfield sizing, not for productive sizings such as re-sizing. Delta sizing is an exception: If you want to size new functionalities on top of an existing system, you can use the Quick Sizer. 

You could run a report to obtain the relevant number of business objects, but you can only see what is currently in the system. If you regularly archive data, for example, these data are not included in the statistics and would render a misleading result.

twitter pixeltwitter pixeltwitter pixeltwitter pixeltwitter pixeltwitter pixeltwitter pixeltwitter pixeltwitter pixeltwitter pixeltwitter pixeltwitter pixel