Practical Guidelines and Techniques for Sizing

Your SAP Landscape for Optimal Performance

and Scalability
Sebastian Schmitt, SAP
September 26, 2022
Public
Disclaimer

This presentation outlines our general product direction and should not be relied on in making a
purchase decision. This presentation is not subject to your license agreement or any other
agreement with SAP. SAP has no obligation to pursue any course of business outlined in this
presentation or to develop or release any functionality mentioned in this presentation. This
presentation and SAP's strategy and possible future developments are subject to change and may
be changed by SAP at any time for any reason without notice. This document is provided without a
warranty of any kind, either express or implied, including but not limited to, the implied warranties of
merchantability, fitness for a particular purpose, or non-infringement. SAP assumes no responsibility
for errors or omissions in this document, except if such damages were caused by SAP intentionally
or grossly negligent.

Public 2
Agenda

Sizing Best Practices

Sizing Tools: What and When to Use

Demo Quick Sizer

Post Go-Live Sizing

Wrap-up

Public 3
Sizing Introduction and Basics
Sizing questions may come in different flavors

” ”
Can SAP software payroll 5+ million When I check www.sap.com/sizing, there
employees and pensioners is no sizing guideline for
in less than two hours? FIN-FSCM-TRN. How can I do a sizing?

” ”
We are running on SAP ECC 6.0 We are running on anyDB and we
and we want to upgrade want to upgrade our ECC system
to SAP ECC 6.0 EhP8 to SAP S/4HANA

Translate business requirements into hardware requirements

– in an iterative process

Public 4
Sizing-Relevant KPIs (Key Performance Indicators)

 Processing times of business transactions or tasks

CPU
 Cost factor: Number and processing power of servers

 Allocated to a user or background process

Memory  Garbage collection, acceleration, planning capabilities, buffers, caches
 Cost factor: Physical memory slots

 Data that resides on the database

Disk size  File read and write activity to storage
Disk I/O
 Cost factors: Backup/recovery depends on size of database

 Transferred amount of data

Front-end
 Network time and roundtrips
Network Load
 Cost factor: Leasing bandwidth

Public 5
Sizing Introduction and Basics

SAP Application Performance Standard (SAPS) is a hardware-independent measurement unit

that describes the throughput of hardware in an SAP environment.

Laptop
 1 processor Definition of SAPS:
 8 cores
 Approx. 15,000 SAPS  Derived from Sales & Distribution (SD) Standard Application
Benchmark
Commodity server
 4 processors
 112 cores  100 SAPS = 2,000 fully-processed order line items per hour
 Approx. 250,000 SAPS

High-end server
 32 processors For more information on SAPS, see www.sap.com/benchmark
 896 cores → Measuring in SAPS
 Approx. 1,000,000 SAPS

SAPS are provided as output of SAP’s customer sizing tools and SAPS are used to quantify the
CPU power of a system

Public 6
Sizing Goals in Different Phases of a Customer Project
Go
Live
Project Business Realization Final Going Live
Preparation Blueprint Preparation & Support

1. Very early to plan hardware expenditures

2. A few months before live start to verify assumptions
▪ Determine the overall performance requirements

Upgrade Migration Functional Business

Changes Units

3. During production stages to ensure operations and verify/adjust estimations made earlier. “Trigger events” include:
▪ Upgrade database, operating system, SAP application
▪ Reconfigure system landscape
▪ Change business process
▪ Rollouts: more users or other load
Public 7
Different types of sizing

Greenfield Sizing Brownfield Sizing Bluefield Sizing

Sizing of new applications from scratch Extension / migration of an SAP system Re-implementation of an
existing system
Hardware Budget Sizing Re-Sizing Selective Data Transition*
Smaller companies ▪ Tools: SAP system monitors ▪ Tools: S/4HANA & BW/4HANA
▪ Tools: Sizing Guidelines, Quick Sizer (user) ▪ Goal: Extend an existing system by load Sizing Reports
▪ Re-Implementation with
▪ Very simple algorithms − e.g.,100 additional users who'll do the same as the current productive
Selective Transactional Data
▪ Assumptions, likelihoods

Upgrade Sizing
Medium to large companies
▪ Tools: SAP system monitors
▪ Tools: Sizing Guidelines, Quick Sizer (throughput)
▪ SAP Notes
▪ Usage of standard tools
▪ Goal: Upgrade SAP software
▪ Focus on core business processes

* Special case
Migration Sizing Shell copy: Re-implementation
without transactional data, but with
▪ Tools: S/4HANA and BW/4HANA Sizing Reports old customizing and master data
▪ Goal: Migrate ECC or BW system to S/4HANA or BW/4HANA

Delta Sizing
▪ Tools: ▪ Goal: Extend an existing system by new functions
− SAP system monitors − e.g., you are live with SAP S/4HANA and want to add SAP EWM Not applicable
or SAP S/4HANA embedded analytics
− Sizing Guidelines, Quick Sizer for additional load

Expert Sizing
▪ Additional guidelines ▪ Analysis of custom coding
Large or complex projects
▪ Custom calculations ▪ Custom sizing guidelines
Public 8
Universally Applicable Statements on Sizing

“
20% of the transactions and scenarios
create 80% of the load

Reliable sizing can only be done with

“  Scalable application software

 Scalable hardware
 Meaningful and nearly complete volume
throughput or active user information

Sizing results in KPIs

“ 


Main memory
CPU
Disk size
 Disk I/O
 Front-end bandwidth requirements

“
Landscaping and configuration
are related, but are separate tasks
Public 9
Ensuring scalability with performance tests – Approaches

Single user ▪ Quality and implications of accesses to

test persistence layer
▪ Linear resource consumption
▪ Small test system ▪ Parallel processing mechanisms, load
▪ (QA, development), one user Analyze & measure balancing
scalable behavior ▪ Memory usage and memory leaks
▪ Disk requirements
▪ Front-end network load

Performance predictions
for high volume environment
Multi user test
(Volume)

▪ Equivalent to multi-user test, stress test, Verify assumptions

load test, benchmark
Public 10
Benchmark Runs vs. Production Scenarios

Be aware
High-water SD benchmarks load the system to the limit
▪ CPU utilization ~ 100%
▪ Memory in server often exceeds the required memory
Production systems should run at a medium load
▪ CPU utilization 30-65%

Sizing recommendations refer to a SAPS value measured with an SD benchmark at a CPU utilization
of ~100% and <1 second response time

Note
You can directly use the SAPS value from sizing to search in the benchmark results list for a
hardware fulfilling the recommendation
Using the recommended hardware would result in a CPU utilization of 65% for your
production system

Public 11
Finding the correct sizing approach

Sizing Decision Tree Sizing Blog

HANA Sizing Decision Tree

Public 12
Agenda

Sizing Best Practices

Sizing Tools: What and When to use

Demo Quick Sizer

Post Go-Live Sizing

Wrap-up

Public 13
Official SAP Sizing Page: www.sap.com/sizing

Guidelines
 Access Sizing Guidelines
 Access Sizing-related Materials

Tools
 Access Quick Sizer *
 Sizing Decision tree
 Others

Training opportunities

FAQs

* Requires login credentials

Public 14
Standard sizing tools

Initial calculation method Questionnaire without

Educated guess formulas
For structured questions

T-Shirt sizing
Simple algorithms with many
assumptions Quick sizer
Supports user-based and
throughput-based sizing
Formulas
Simple or more complex

Sizing reports Monitoring tools

For migration sizings For post go-live sizings

Public 15
Initial Calculation Method

Initial Calculation Method

Educated guess

Advantages Disadvantages
▪ Quick and easy ▪ Must include many assumptions
▪ Delivers ballpark estimate ▪ ”Educated” guess

EXAMPLE Challenge: Need to process 5000 advertisements per week

 Make assumptions
− 5 work days per week, 8 hour work day → 5000/(5*8) = 125 ads per hour (250 ads during peak times)
− 5 dialog steps to process 1 advertisement
− Max. server processing time per dialog step: 1 sec.
− Calculation: 250 ads * 5 DS * 1 sec processing time = 1250 seconds
− CPU capacity (1h): 3600 seconds

Public 16
T-Shirt Sizing

T-Shirt Sizing
Predefined tables with sizing output

Advantages Disadvantages
 Quick and easy to understand  Must include many assumptions
 Functional and architectural information  Usually doesn’t reflect customer reality

EXAMPLE Excerpt from CPM Sizing

Guide

Public 17
Formula

Formula
Simple or more complex, manual
calculation

Advantages Disadvantages
 Is closer to customer reality  Suggests an accuracy that sizing
 Allows for more variables cannot deliver
 Relatively transparent approach  Can easily be misunderstood

EXAMPLE Excerpt from Front-End Network

Requirements

Public 18
Offline Questionnaire

Offline Questionnaire
Structured questions

Advantages
Disadvantages
▪ Detailed customer information
▪ SAP must be contacted for a result
for a proper sizing
▪ Versioning
▪ Relatively transparent approach

EXAMPLE Excerpt from Banking

Questionnaire

Public 19
Finding the correct sizing tools
Quick Sizer, SAP’s online sizing tool

Characteristics
▪ Structured sizing questionnaires
▪ Input for
– Greenfield sizing & Delta Sizing
– GoingLive Check
▪ Hardware vendor contact list

Facts and Figures

▪ Available online since 1996
▪ Three Quick Sizer versions available: HANA-based, HANA-based Cloud, Non-
HANA-based
▪ Free of charge
▪ As of 2021: avg. 20,000 new projects per year

Scope
▪ SAP Key applications
– SAP S/4HANA
– SAP HANA Platform
– SAP BW/4HANA
– etc.
▪ Sizing by users and/or by throughput
Public 20
Agenda

Sizing Best Practices

Sizing Tools: What and When to Use

Demo Quick Sizer

Post Go-Live Sizing

Wrap-up

Public 21
Sizing Models in Quick Sizer

Quick Sizer
User-based sizing Throughput-based sizing
Users Business throughput
 Low, medium, high activity
Considers time periods
 Application components
 Residence time
 Assumptions for load on CPU and disk
 Average working day
Result  Peak load time frame
 Average and peak CPU
Result
 Disk size
 Average and peak CPU
 Disk I/O
 Disk size and growth
 Memory
 Disk I/O
 Memory

Public 22
 Demo

Quick Sizer

Public 23
Sizing and Configuration

Create a Quick Sizer project and provide input on the business

1 usage/requirements of the customer into the Quick Sizer project.

SIZING
The Quick Sizer tool calculates the sizing result (memory, disk space
2 and disk I/O, and CPU) based on the input

Check the list of certified AnyDB or SAP HANA hardware to see which
hardware or IaaS providers offer hardware configurations that match the
3 sizing result.
Virtualized environment: Approx. 10% additional resources are needed for the
virtualization software. This heavily depends on the workload CONFIGURATION

Provide the sizing result (or the Quick Sizer project number) to the
4 hardware vendor and get proposal for appropriate hardware
configuration and prices.
Public 24
Agenda

Sizing Best Practices

Sizing Tools: What and When to Use

Demo Quick Sizer

Post Go-Live Sizing

Wrap-up

Public 25
Sizing Goals in Different Phases of a Customer Project
Go
Live
Project Business Realization Final Going Live
Preparation Blueprint Preparation & Support

1. Very early to plan hardware expenditures

2. A few months before live start to verify assumptions
▪ Determine the overall performance requirements

Upgrade Migration Functional Business

Changes Units

3. During production stages to ensure operations and verify/adjust estimations made earlier. ”Trigger events” include:
▪ Upgrade database, operating system, SAP application
▪ Reconfigure system landscape
▪ Change business process
▪ Rollouts: More users or other load
Public 26
Introduction – Sizing Approaches on Productive Data

Assumptions
▪ The system is properly tuned for optimal performance
▪ The focus is on net consumption of business processes on the hardware

▪ Note: Resource consumption strongly depends on:

– Business process: Customizing, customer extensions
– Combination of hardware and software: Configurations
– Recommendations refer to used resources, not allocated resources

Public 27
Production Sizings
General procedure

Prerequisites
▪ The system is live
▪ The hardware and software are scalable
▪ Different goals
– Re-Sizing: only add volume, no modified processes
– Delta Sizing: add different functions
– Upgrade sizing: only upgrade SAP software

Procedure
▪ Monitor CPU utilization, table growth, and memory use
– Relate it to a meaningful business entity, such as the number of concurrent users or the number of active projects
▪ Different procedures according to goals
– Re-sizing: Add the load coming in through the additional users and projects causing the same load structure
– Delta sizing: Treat like a new sizing and add calculated load
– Upgrade sizing: Determine additional requirements and add calculated load
▪ Judge whether your current hardware is sufficient, or whether you may need to buy new hardware
Public 28
How to Monitor Current Resource Utilization

Available monitors
▪ Disk Analysis DB02, DB monitor of hardware vendor
– (DB Performance Tables & Indexes)
▪ CPU Analysis ST06, ST03N, STAD, ST03G
– (Workload Analysis, Statistical Records, Global System Workload Analysis)
▪ User Analysis STAD, ST03G
– (Application Monitor, Statistical Records)
▪ Memory Analysis SM04, STAD
– (User List, Statistical Records)
▪ Front-End Network Load STAD, ST03N, ST03G
– (Statistical Records, Workload Analysis)

As a rule, 20% of the processes cause 80% of the load

▪ Analyze
– Growth rate of 20 largest tables
– Average and peak CPU load
– Average and peak memory utilization

Public 29
Upgrade Sizing
Straightforward procedure for upgrade sizing

You have analyzed the current system resource consumption for

▪ Disk space
▪ CPU consumption
▪ Memory consumption
In a first step, use the SAP standard notes, which are based on weekly regression
measurements of top 100 transactions

Example
▪ Current monthly disk growth = 200 GB
– Note + 5%: 200 GB * 1.05 = 210 GB growth
▪ Current avg. CPU utilization = 54% DB, 48% App server
– Note + 5%:
▫ DB 54 * 1.05 = 56.7%
▫ App 48 * 1.05 = 50.4% App server
▪ Current memory used = 16.4 GB
– Note: +15% : 16.4 * 1.15 = 18.9 GB

Public 30
Productive Sizing
How to monitor current resource utilization

Selection of available monitors

▪ Disk Analysis DB02, DB monitor of hardware vendor
– (DB Performance Tables & Indexes)
▪ CPU Analysis ST06, ST03N, STAD, SDF/SMON
– (Workload Analysis, Statistical Records, Global System Workload Analysis)
▪ User Analysis STAD, SDF/SMON
– (Application Monitor, Statistical Records)
▪ Memory Analysis SM04, STAD, ST02, SDF/SMON
– (User List, Statistical Records)
▪ Front-End Network Load STAD, ST03N
– (Statistical Records, Workload Analysis)

As a rule, 20% of the processes cause 80% of the load

▪ Analyze
– Growth rate of 20 largest tables
– Average and peak CPU load
– Average and peak memory utilization

Public 31
Determining CPU/Memory Utilization – ST06

Check
 Number of CPUs/cores
 CPU utilization
◼ Current and historic
◼Detail Analysis Menu
 Available and free
memory

Public 32
Determine HANA Memory and Disk (SAP Note 1872170) Requirements

Report /SDF/HDB_SIZING
▪ Described in SAP Note 1872170 – Suite on HANA sizing report

Scope
▪ Runs on SAP NetWeaver® systems based on SAP HANA
▪ Not suitable for BW (refer to SAP Note 2296290 – New Sizing Report for BW/4HANA)

Functionality
▪ Estimates the maximum memory and disk consumption of the database
▪ Additional functionality needs to be sized with the HANA Quick Sizer (delta sizing)

Public 33
Standard Scenarios for Production Sizings – a Mixture of Different
Approaches
+ Load + Quick Sizer + Quick Sizer
Increase in % Project Project

+ Upgrade + Load + Upgrade

Increase in % Increase in % Increase in %

Quick Sizer
Current Current Current
Project
Workload Workload Workload

Greenfield Sizing: Brownfield Sizing: Brownfield / Greenfield Brownfield / Greenfield

New SAP Application from Upgrade (Upgrade Sizing) Sizing: New functions Sizing: Upgrade (Upgrade
scratch or load increase (Re- (Greenfield: Quick Sizer) or Sizing) & new functions
Sizing) load increase (Re-Sizing) (Greenfield: Quick Sizer)
Public 34
Agenda

Sizing Best Practices

Sizing Tools: What and When to Use

Demo Quick Sizer

Post Go-Live Sizing

Wrap-up

Public 35
 Three-Party Collaboration Model

Sizing is the joint responsibility of

Hardware Vendors Customer customer (LoB), SAP and HW
Contributions Expectations from sizing Vendor.
▪ Different hardware ▪ Optimal performance
Sizing Recommendation
configurations together
▪ CPU (SAPS)
▪ Suggestion for HW config. ▪ Custom coding needs expert
with technology partners
▪ Service level agreements ▪ Memory (GB) Contributions sizing
▪ Database space (GB) ▪ Response time ▪ Different businesses require
▪ Disk I/O operations per sec requirements different sizings
▪ ▪ Throughput requirements
Frontend bandwidth mbps
▪ Provides business input
▪ Different applications need
different amounts of CPUs
▪ Additional needs might come from
additional (not sized) usages
SAP
Contributions Under-sizing can be reason for
▪ Regression testing for new performance issues.
releases
▪ Standard sizing guidelines
▪ Sizing verification Over-sizing can be reason for high
processes TCO of customers.

Public 36
Factors that Influence Sizing
LEGEND: Responsibility of: Technology Partner | SAP | Customer

Customer Coding,
HW Platform System Settings Customizing Third-Party
▪ Processor ▪ Parameterization ▪ Set up of business ▪ Performance impact
technology ▪ Interfaces processes ▪ Scalability
▪ Disk technology ▪ Organizational structures ▪ Business process design
▪ Security settings
▪ Network technology ▪ Business process design
▪ Unicode
▪ System infrastructure ▪ A2A, B2B scenario

SAP Software Data Volume Disk Growth User Behavior

▪ Release ▪ Time for volume ▪ Avoiding data ▪ Concurrency
▪ OLTP or OLAP processing ▪ Archiving strategies ▪ LAN/WAN
▪ Industry solutions ▪ Background processing, ▪ Information Lifecycle ▪ Internet/intranet
parallel jobs Management ▪ Activity, e.g.:
▪ Reporting − *-Search
− Efficient navigation

Customer Profile

Public 37
Risks in a Sizing Project

 Challenge to obtain sufficient usage information as sizing

input
INCOMPLETE INPUT
 Often caused by communication issues
DATA
Risks in a Sizing Project

 Insufficient sizing input is compensated by assumptions,

which should be documented

 While it is perfectly ok to work with assumptions you must

ASSUMPTIONS ARE
ensure that a verification process is included in the project
NOT VERIFIED plan

CUSTOM CODING &  Are very hard to predict: Make sure there is a verification
SPECIAL DATA process
CONSTELLATIONS  Make sizing measurements, if required

Public 38
Key Points to Take Home

▪ Sizing means translating business requirements into hardware requirements

▪ The success of the sizing exercise almost entirely depends on the quality of the data
▪ Sizing involves very different people and teams within an organization
▪ Expert sizing is recommended for custom development
▪ Greenfield sizings for new applications should be done with the Quick Sizer
▪ Sizing is not configuration
▪ For productive sizings, you have to analyze your system utilization

Public 39
Sizing Information and Tools
Sources of published sizing documentation

www.sap.com/sizing
▪ Sizing methodology
▪ Access Quick Sizer
▪ Access Sizing Guidelines

www.sap.com/benchmark
▪ Certified benchmark results
▪ Descriptions of the available benchmarks

www.sap.com/performance
▪ Tips for performance improvements

Public 40
Thank you.
Contact information:

Sebastian Schmitt
SAP SE
Product Management
sebastian.schmitt@sap.com
Cell: +49 151 18874932

© 2022 SAP SE or an SAP affiliate company. All rights reserved. See Legal Notice on www.sap.com/legal-notice for use terms, disclaimers, disclosures, or restrictions related to SAP Materials for general audiences.