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.
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.
General sizing information
I would like to know by whom the sizing for on-premise applications should be done.
I would like to better understand the link between sizing and SAP Benchmarks.
I would like to participate in a SAP sizing training: Check "ADM115" on the German country site.
Search for the following keywords in alphabetical order:
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.
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.
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 we introduced the new KPI Single Computing Unit performance (SCU performance). To be as hardware neutral as possible and due to virtualization technologies we use 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. 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.
Previous versions of Quick Sizer (versions 21 - 23) showed the following message when a sizing for SAP CRM, SRM or EWM was done:
For good response times choose CPUs with a good single thread performance, especially for SAP CRM, SAP SRM, and SAP EWM.
With the introduction of the single computing unit performance classes, every sizing element is classified. The classes are A, AA, and AAA.
Overview about Quick Sizer single computing unit performance classes
Class A: This SAP solution benefits from good SCU performance.
Class AA: This SAP solution benefits from a very good SCU performance.
Class AAA: This SAP solution benefits from an excellent SCU performance.
The classes are aggregated along the different result levels (from sizing element to project) and within same time slots.
Aggregation of results to next result level and aggregation within same time slots
Class A: This SAP solution benefits from good SCU performance.
Class AA: This SAP solution benefits from a very good SCU performance.
Class AAA: This SAP solution benefits from an excellent SCU performance.
Example
For more information check SAP note 1501701.
Preconditions
- A valid customer number
For a greenfield sizing, proceed as follows:
- . Create a sizing project with the relevant information, such as number of users
- . Get an initial result for CPU, disk and memory
- . Possibly apply additional guidelines on top
- . Check for sample configurations at www.sap.com/benchmark
- . Provide hardware vendor with Quick Sizer project name (and additional guidelines, if desired)
All sizing guidelines can be found on www.sap.com/sizing.
The SAP business units are responsible for providing standard sizing guidelines. The hardware vendors are responsible for providing hardware that will meet the customer’s throughput and response time requirements. In between the following groups different roles may need to perform (at least an initial) sizing: SAP Sales, Consulting, the implementation partner, the customer’s IT basis team.
Some Statements about Sizing and Virtualization
- . 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.
- . 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).
- . 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.
- . For the right virtualization strategy you should get in touch with your hardware vendor.
- . 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.
- . 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.
- . Virtualization is less suitable for in-memory computing applications. If a system in a virtualized environment will be moved from A to B, then it depends very much on the size and the change rate of memory. Some problems might occur if sufficient memory is not provided. In such a situation maybe even memory under-commitment would be needed. In addition, the move can need much time because the memory has to be synchronized. In extreme situations it might even not be possible to make a (fast) move, because the change rate might be bigger than the move rate.
Search
Use the search function to look for the appropriate sizing methodology for a particular SAP functionality.
Some details on the search function
The program searches for your search string across the visible and invisible parts of Quick Sizer. The results are displayed in the navigation tree. The search is version dependent.
All result lines are marked with an information icon. If the string is found in the visible parts, the search string result will be presented bold and enlarged. If the search string is found in the invisible parts, the entire result line will be presented bold, enlarged, and in italics. If a result only partially contains the search string, only the search string is marked bold and enlarged.
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. 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.
- 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.
- 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).
- 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.
- For the right virtualization strategy, you should get in touch with your hardware vendor.
- 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.
- 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:
- Create a sizing project with the relevant information, such as number of users
- Get an initial result for memory, CPU, and disk
- Possibly apply additional guidelines on top
- Check for sample configurations on HANA Hardware Directory and at www.sap.com/benchmark
- 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-SAPSMP-ST. Support will help you solve the problems.
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 non-HANA-based Quick Sizer and 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.