Hardware sizing decision tree

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.

SAPS

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.

Sizing and Response Times

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.

Table2: Aggregation of results to next result level and aggregation within same time slots

Example:

• SAP ERP SCU performance A for 10am to 12 am and SAP CRM SCU performance AAA for 11am to 1pm
• Aggregation to result level 'Project' shows:
  • For time slots: SCU performance A from 10am to 11am and AAA from 11am - 1pm
  • Total result: AAA (for 24 hours)

For more information check SAP note 1501701 and SAP insider article Do You Have the Right Hardware for Your SAP Solution? 

Sizing Process

Preconditions

• A valid customer number

For a greenfield sizing, proceed as follows:

1. Call Quick Sizer (classic or HANA)
2. Create a sizing project with the relevant information, such as number of users
3. Get an initial result for CPU, disk and memory
4. Possibly apply additional guidelines on top
5. Check for sample configurations 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 Guidelines. 

Sizing Responsibilities

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.

Virtualization

Some Statements about Sizing and Virtualization

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.
2. 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).
3. 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.
4. For the right virtualization strategy you should get in touch with your hardware vendor.
5. 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.
6. 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.
7. 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.