SAP Lumira

Sizing Guide
June 10, 2015

Contents
Document Update History ............................................................................................................................ 4
Who should use this document? .................................................................................................................. 5
Prerequisites for Sizing ................................................................................................................................. 5
Terminology .................................................................................................................................................. 6
Think time ............................................................................................................................................. 6
Users ..................................................................................................................................................... 6
Sizing SAP Lumira, Server for teams and SAP Lumira, Server for BI Platform .............................................. 8
Understanding Memory Management ..................................................................................................... 8
Sizing Lumira, Server for BI Platform ........................................................................................................ 9
Lumira, Server for BI Platform Architecture ....................................................................................... 10
Sizing Lumira, Server for teams .............................................................................................................. 12
Sizing SAP Lumira, Desktop Edition............................................................................................................. 13
Memory Settings ..................................................................................................................................... 13
Multi-User Sizing ..................................................................................................................................... 13
Sizing Memory (RAM) ......................................................................................................................... 13
Sizing Disk (User Profile) ..................................................................................................................... 13
Sizing SAP Lumira, Server for HANA............................................................................................................ 14
Lumira, Server for HANA Pre-Sizing Checklist ......................................................................................... 14
Getting Started with HANA and Lumira, Server for HANA ..................................................................... 15
Understanding Lumira, Server for HANA Processing .............................................................................. 15
Lumira, Server for HANA Sizing Methodology ........................................................................................ 16
Sizing Steps and Methodology ............................................................................................................ 16
Assumptions ........................................................................................................................................ 16
Prerequisites ....................................................................................................................................... 16
HANA Cluster Considerations ............................................................................................................. 18
Sizing Calculation ................................................................................................................................ 18
Tuning Options ........................................................................................................................................ 20
Appendix: Obtaining CPU Processing Time using HANA Studio ................................................................. 21
Find the Performance Information ......................................................................................................... 21
Calculation .............................................................................................................................................. 23
Appendix: Sizing SAP HANA ........................................................................................................................ 24

SAP SE Lumira Sizing Guide

 Copyright 2014, 2015 SAP AG. All rights reserved.

No part of this publication may be reproduced or
transmitted in any form or for any purpose without the
express permission of SAP AG. The information
contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its
distributors contain proprietary software components of
other software vendors.
Microsoft, Windows, Outlook, and PowerPoint are
registered trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, OS/2, Parallel
Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390,
OS/400, iSeries, pSeries, xSeries, zSeries, z/OS,
AFP,Intelligent Miner, WebSphere, Netfinity, Tivoli, and
Informix are trademarks or registered trademarks of IBM
Corporation in the United States and/or other countries.

These materials are subject to change without notice.

These materials are provided by SAP AG and its affiliated
companies ("SAP Group") for informational purposes only,
without representation or warranty of any kind, and SAP
Group shall not be liable for errors or omissions with respect
to the materials. The only warranties for SAP Group
products and services are those that are set forth in the
express warranty statements accompanying such products
and services, if any.
Nothing herein should be construed as constituting an
additional warranty.
Disclaimer
Some components of this product are based on Java.
Any code change in these components may cause
unpredictable and severe malfunctions and is therefore
expressively prohibited, as is any decompilation of these
components.
SAP Library document classification: CUSTOMERS &
PARTNERS

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered
trademarks of the Open Group.

Documentation in the SAP Service Marketplace

You can find this documentation at the following address:
http://service.sap.com/sizing

Citrix, ICA, Program Neighborhood, MetaFrame,

WinFrame, VideoFrame, and MultiWin are trademarks or
registered trademarks of Citrix Systems, Inc.
HTML, XML, XHTML and W3C are trademarks or
registered trademarks of W3C, World Wide Web
Consortium, Massachusetts Institute of Technology.
Java is a registered trademark of Sun Microsystems, Inc.
JavaScript is a registered trademark of Sun
Microsystems, Inc., used under license for technology
invented and implemented by Netscape.
MaxDB is a trademark of MySQL AB, Sweden.
SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP
NetWeaver, SAP BusinessObjects and other SAP
products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of
SAP AG in Germany and in several other countries all over
the world. All other product and service names mentioned
are the trademarks of their respective companies. Data
contained in this document serves informational purposes
only. National product specifications may vary.

SAP SE Lumira Sizing Guide

Document Update History

Date

Details

May 2013

Initial document.

Feb 13, 2014

Updated sizing methodology

Feb 17, 2014

Additional information added regarding how HANA works in relation to workflow

estimation

April 8, 2014

Updated Tuning options with additional advice.

April 14, 2014

Added option for measuring HANA impact using Lumira Desktop.

Added multi-user session load calculation.
Added pre-sizing checklist. Added additional detail to the sample sizing.

July 22, 2014

Sizing Methodology for Lumira Server updated. Sizing for Lumira Desktop removed.
Removed sample sizing calculation.

Oct 17, 2014

Added Background: Performance Impact section. Also added HANA cluster

considerations when doing sizing.

Nov 26, 2014

Added Getting Started with HANA and Lumira Server section, which provides
general sizing guidance for customers who dont yet have HANA systems. Changed
typical user think times to 10 seconds (from 600) to account for more typical
Lumira-style workflow.

Dec 3, 2014

General document refinement and clarification.

Feb 23, 2015

Added Lumira Edge and multi-user Lumira Desktop sections.

March 9, 2015

Updated product names, fixed typo in Lumira Server sizing calculation

June 8 2015

Added Lumira, Server for BI Platform section to reflect the Lumira 1.25 release.
Added Terminology section, updated product names, and re-organized few
sections for a better flow.

SAP SE Lumira Sizing Guide

Who should use this document?

This document provides recommendations and best practices to help you deploy and scale the SAP
Lumira product suite.
Use this sizing guide if you are:
Planning to deploy any of the following products:
o Lumira, Server for teams
o Lumira, Server for BI Platform
o Lumira, Server for HANA
Note: Lumira, Server for BI Platform deploys as additional node(s) to your BI 4 landscape; you
should use this guide in conjunction with the BI 4 Sizing Guide as many of the practices
mentioned in the latter document will help you successfully implement your system.
Optimizing or tuning an existing Lumira Desktop or Lumira Server deployment.

Prerequisites for Sizing

To size your deployment effectively and accurately, you need to know the following detailed
information, all of which will be explained further in this document:
If you plan to use virtualized hardware, you will need to know if your IT departments allow
dedicated CPU and memory reservations.
The number of and types of users that intend to use your system.
For multi-user scenarios, you will need to know the concurrency ratio of the users who will be
actively using Lumira products in your organization.

SAP SE Lumira Sizing Guide

Terminology
The following terms are used throughout this guide. You must understand clearly how these terms, as
defined below, map to your organizations setup in order to derive your sizing estimate.
Think time
Refers to the time a user takes between actions that cause a load on a system. Normally a user does not
constantly click on an application. The amount of time a user spends on processing the information
displayed on screen before taking any subsequent action is referred to as think time.
Users
When sizing Lumira in terms of users, there are two dimensions to consider:
User Class: relates to the load in the system generated by user workflow.
User Types: helps you anticipate the concurrency ratio of users in the system.
User Class
Lumira workflows are divided into two user categories: Consumer and Analyst. Typically consumers will
utilize less system resources because their activities are principally related to viewing existing
documents.
Consumers: generally use the system to view cached data presented as information, drill, filter, and
occasionally refresh the data when a document is opened. Multiple consumers in a system would view
the same Lumira document created and distributed by analysts.
Analysts: perform more resource-intensive operations including ad-hoc analysis and customizing
content as required. Analysts use their own exclusive and detail-rich Lumira documents that contain the
most up-to-date data. A typical analyst workflow might involve opening a Lumira document, refreshing
the data, and editing visualizations.
Both consumers and analysts typically spend an average of 10 seconds think time in between on screen
actions.
You should use think time in conjunction with user classes to reach the most accurate sizing estimates.
User classes help you quantify and distinguish system usage and the subsequent load generation for the
two Lumira user categories. In your sizing exercise, workflows by a certain user class may have a
different think time between operations compared to other system users.
Active Concurrent Users
Although users are collectively the total number of user accounts in your system, only some users will be
actively using your system together. Other users will be mainly idle after they log on. For sizing
purposes, you need to determine how many of the active users will be concurrently generating loads on
system resources; this user subset is referred to as active concurrent users.
The following example illustrates how to estimate the active concurrent users.
Lets assume your organization has 3,500 users with accounts for Lumira Server products. You estimate
that only 20% of these users will actually log on to Lumira server. However, these 700 active users will
use Lumira server for only part of their tasks. Lets assume that 20% of the active users will concurrently
view, edit, refresh Lumira documents. Our example would therefore have 140 active concurrent users.

SAP SE Lumira Sizing Guide

In our example, 3,500 users translated to 140 active concurrent users - a 4% concurrency ratio. Typical
concurrency recommendations vary depending on the size of the deployment and other factors
including the kind of workflows users perform.
When sizing Lumira Server products, specify your inputs in terms of active concurrent users.
If you expect a concurrency ratio that is higher than normal, you should expect a heavier load and would
need to compensate accordingly. If you require guidance to estimate the user concurrency ratio in your
organization, please consult your SAP representative.

SAP SE Lumira Sizing Guide

Sizing SAP Lumira, Server for teams and SAP Lumira, Server for BI Platform
The following are common sizing recommendations for Lumira, Server for teams / BI Platform; they are
based on the same underlying BI Platform architecture.
1. A CPU core refers to a physical (not hyper-threaded) core on a physical machine. In a virtual
machine, this is the equivalent to a logical processor.
2. Merged data sets are more complex to process, and can require more memory and processing
resources.
3. The refresh and edit workflows are memory-intensive operations requiring new copies of the
data to be loaded in the in-memory data engine.
4. It is recommended that you build your system to have at most an average 65% CPU utilization
rate to support potential bursts in activity. Performance of both physical and virtual systems can
degrade when the CPU utilization rate exceeds 80%.
5. The maximum memory utilized should not exceed the physical memory available. Refer to the
FRS disk recommendations mentioned in the BI 4 Sizing Guide.
SAP strongly recommends that BI virtual machines have reservations for the memory
and logical CPUs assigned to them.
For more in-depth information on BI and Virtualization, please refer to the SAP BI 4
Virtualization section at www.sap.com/bivirtualization.
Note: The recommendations outlined in this section do not apply to Lumira Desktop or Lumira, Server
for HANA as they have different architectures.

Understanding Memory Management

By default Lumira, Server for teams or Lumira, Server for BI Platform, allocate 85% of the available
memory of host machines at start up to the in-memory data engine. This is why it is recommended to
deploy your Lumira, Server for teams, and Lumira, Server for BI Platform on dedicated machines.
When two concurrent users view the same Lumira document, a single copy of the document is loaded
and shared on the in-memory data engine. However, when the document is refreshed or edited by one
of the users, a new and separate copy of the document is created and loaded on the data engine.
Memory resources are released under the following scenarios:
1. When a user logs out of the system.
2. In Lumira, Server for teams, when the user navigates back to the documents listing page.
3. In Lumira, Server for BI Platform, when the user closes the Lumira document tab.
Note: if another concurrent user continues to view the same document, the allocated memory
resources are not released.

SAP SE Lumira Sizing Guide

Sizing Lumira, Server for BI Platform

Lumira, server for BI Platform brings SAP Lumira content into your SAP BusinessObjects BI platform
deployment. The SAP BusinessObjects BI platform enforces security on Lumira documents, and allows
access and categorization in the same manner as other BI platform content, allowing you to seamlessly
adopt SAP Lumira within your organization.
This information is provided as a starting point for your deployment planning. Your experience may vary
depending on:
The complexity of documents created
The data set size
Complexity as well as general user workflow.
The sizing estimate below should only be used as a starting point as it is based on the
workflows outlined in Table 1. We strongly recommend volume testing to validate your
sizing estimate based on the expected usage in your deployment.
Maximum Cell Size
(no. of rows * no. of columns)

Recommended Maximum Active Concurrent Users

60,000,000

10

12

15

700,000

15

25

35

Recommended Configuration Scenario

Minimum memory required (RAM in GB)

32

48

64

Minimum CPU Cores

24

24

Table 1: Sizing Recommendations for Lumira, Server for BI Platform

1. Your hardware should at least meet the minimum hardware specifications outlined in SAP
Lumira, server for BI Platform Product Availability Matrix (PAM).
2. To avoid the user load impacting other BI platform workflows, it is recommended that the
Lumira, Server for BI platform runs on dedicated hardware resources according to the
configurations outlined in the table above. There is no hard limit cut-off that the in-memory
data engine can support. The engine will utilize the available memory resources.
3. The sizing recommendations are specific to the hardware configurations outlined in Table 1. For
larger deployments involving more than 35 active concurrent users, we recommend that you
add more nodes to your deployment rather than adding additional Lumira servers to an existing
node to avoid potential memory resources allocation conflicts. If your deployment requires 350
active concurrent users, you should consider deploying 10 nodes each with 64GB RAM and 24
CPU cores.
The recommendations listed in Table 1 are necessary to support the following user load:
Typical Analyst Workflow
Log on to BI launch pad

SAP SE Lumira Sizing Guide

Open Documents tab

Browse to specific BI launch pad folder
Select document from BI launch pad folder
View his/her own document
Refresh document
Close BI launch pad
Log out
Table 2: Typical Analyst workflow used for Lumira, Server for BI Platform sizing tests
For the workflows used, all users view different document and then refresh. We have factored in an
average idle think time of 10 seconds in between each operation. The workflow involves loading and
updating data into the in-memory data engine.
Lumira, Server for BI Platform Architecture
The Lumira, Server for BI Platform architecture adds a few additional components to your BI 4
landscape. A technological representation of the system is provided below:

Lumira Server:
The Lumira Server processes Lumira content on BI Platform. This server hosts the in-memory data
engine which is used as an offline data processing engine for Lumira. It is a separate product from HANA
but borrows many concepts such as in-memory, column store, parallelization, and compression. Like
other documents in BI Platform, Lumira documents are also saved in the Input / Output File Repository
servers. The data is loaded into the in-memory data engine only when a user opens a Lumira document.
Lumira Scheduling Service:

10

SAP SE Lumira Sizing Guide

Lumira Scheduling Service is a service within the Adaptive Job Server. This server enables the scheduling
of Lumira documents.
Lumira Web Application:
The BI Launchpad and CMC applications are embedded in the Lumira Web Application to allow access to
Lumira content in the BI applications.
Lumira Restful Web services:
Lumira Restful Web Services provides the web services required by Lumira Desktop to interact with the
BI Platform such as login or to save Lumira document.
Refer to the following links for more Lumira, Server for BI Platform details.
http://scn.sap.com/docs/DOC-63551: contains the latest information regarding Lumira, Server
for BI Platform functionalities and support statements.
http://scn.sap.com/docs/DOC-26507: refer to the Architecture Process Flow section for a step
by step explanation of how Lumira user loads are processed within a BI Platform deployment.

11

SAP SE Lumira Sizing Guide

Sizing Lumira, Server for teams

Lumira, Server for teams is an analytics server designed for small teams of users.
This information is provided as a starting point for your deployment planning. Your experience may vary
depending on:
The complexity of documents created
The data set size
Complexity as well as general user workflow.
The recommended sizing estimate below should only be used as a starting point as it is
based on the workflows outlined in Table 3. We strongly recommend volume testing to
validate your sizing estimate based on the expected usage in your deployment.

Maximum Cell Size

(no. of Rows * no. of
Columns)

Minimum memory
required (RAM in GB)

Minimum CPU Cores

Recommended Active
Concurrent Users

10,000

8GB

500,000

32GB

10

100,000,000

32GB

Table 3: Sizing Recommendations for Lumira, Server for teams

Note: Table 3 is based on the tests on Lumira, Server for teams 1.23.

The recommendations listed in Table 3 are necessary to support the following user load:
Typical Analyst Workflow
Log into Lumira, Server for teams
List available documents
View his/her document
Refresh current document
Save current document
Close Lumira Document (Navigate back to listing page)
Log out
Table 4: Typical Analyst workflow used for Lumira, Server for teams sizing tests
For the workflows used, all users view different document and then refresh. We have factored in an
average idle think time of 10 seconds in between each operation. The workflow involves loading and
updating data into the in-memory data engine.

12

SAP SE Lumira Sizing Guide

Sizing SAP Lumira, Desktop Edition

Memory Settings
SAP Lumira, Desktop Edition is configured out of the box to handle most customers needs. If you are
working with very large data sets, you can configure SAP Lumira, Desktop Edition to allow greater
memory (RAM) usage by changing the following entry in the configuration file C:\Program Files\SAP
Lumira\Desktop\SAPLumira.ini:
-Xmx1024m
The default setting as shown is maximum 1GB of heap memory (RAM). You may need to set this value
higher to accommodate larger data sets, taking into account that you will need more available RAM.
By default Lumira Desktop allocates 85% of the available memory of your machine at start up to the inmemory data engine.

Multi-User Sizing
SAP Lumira, Desktop Edition supports deployment in multi-user environments such as Citrix and
Windows Remote Desktop Services. Be sure to check the SAP Lumira, Desktop Edition PAM for
supported platforms.
There are two general approaches to multi-user application delivery: multiple sessions in the same
machine or per-user virtual machines. Lumira works with both configurations and the sizing is identical.
Sizing in general for multi-user environments is to multiply the memory requirement by the number of
expected concurrent users. For disk storage, multiply the total number of expected users assigned to a
server by the disk storage requirement.
Sizing Memory (RAM)
Each users session requires memory in which to operate. Sizing of a multi-user deployment follows the
single-user machine specifications in the PAM: 4GB of RAM. Be sure to check the PAM for up-to-date
platform specifications and requirements.
Sizing Disk (User Profile)
Each Desktop Edition user has preferences and per-user configuration that needs to be saved. This
information is stored in the users profile on disk. The amount for sizing purposes is 100MB of disk
storage per user. This amount doesnt account for saved document storage. As an administrator, you
may or may not allow users to store Lumira or other types of documents in their user profile on the
server. If you do, you should account for this additional storage requirement.

13

SAP SE Lumira Sizing Guide

Sizing SAP Lumira, Server for HANA

Lumira, Server for HANA is designed to provide BI services specifically for HANA. The following sections
discuss the sizing of Lumira, Server for HANA.
Lumira, Server for HANA is designed to scale to large range of deployments and users. The number of
users, types of users, usage patterns, number of BI tools included in the Lumira family, kinds of data set
supported by HANA as well as the deployment options supported by the suite all factor into a series of
variables that affect the successful deployment of Lumira. No configuration fits all customers. The
purpose of this document is to help guide you through the Sizing Exercise for Lumira, Server for HANA.
Sizing HANA services is very different compared to sizing of other types of Enterprise software. BI in
general is a very resource intensive task. In addition, BI can be very bursty, since the load relies a lot on
the interaction of users. The act of extracting information from a potentially large amount of data
requires adequate amounts of processing power and exercises all the subsystems of a HANA system.
Having the right amount of capacity in your system is crucial to success.
Given its architecture, sizing for HANA is different than traditional BI sizing. Historically BI systems relied
on database servers and intermediate caching that all had a large dependency on disk subsystems and
were sized with an I/O orientation. HANA executes analytics in-memory. This makes the sizing analysis
very different: its CPU-oriented.
No tool or document can replace human judgment. So while this document attempts to cover as many
aspects of the Sizing Exercise as possible, Sizing Experts at SAP should always be consulted.

Lumira, Server for HANA Pre-Sizing Checklist

These are the things you need to do before you start your sizing exercise:

How many active concurrent users need to be supported by the deployment? See Active
Concurrent Users for more information.

What types of users will be using each tool? Consumers (consumption workflow) and Analysts
(design workflow)? See User Class for more information.

Do you know how users will use Lumira? Do they require always up-to-date data or can they
operate with cached results? How users use the tools affects the workload they produce.

What types of data sources will your users access? Is your data located on a HANA server for
testing?

How will you measure user workflow impact on HANA? Will you measure the user workflow via
Lumira Desktop or Lumira, Server for HANA?

How many HANA machines are to be involved in the Lumira analytics? Do you have a cluster of
HANA machines with data distributed among the nodes?

14

SAP SE Lumira Sizing Guide


What are the basic CPU and memory capabilities of each HANA machine involved in the Lumira
analytics?

Getting Started with HANA and Lumira, Server for HANA

This section is meant to guide customers on initial acquisition of HANA hardware for the purpose of
performing analytics with Lumira, Server for HANA. These are very general guidelines for customers who
do not have an existing HANA system on which to do sizing measurements.
Starter HANA Configuration for Lumira, Server for HANA
Hardware Profile:
CPU:
2 sockets, for a total of 16 cores
Memory:
128 GB RAM minimum. 256 GB recommended
Medium HANA Configuration for Lumira, Server for HANA
Hardware Profile:
CPU:
4 sockets for a total of 32 cores
Memory:
Minimum 256 GB RAM
When considering a small or medium system, it is recommended that you choose a medium system
when anticipating more than 25 active concurrent users. The deciding factor for number of users should
include the complexity of your data as well. You should also choose a medium or larger system when
expecting individual dataset sizes greater than 1GB or 2 million rows.
Larger systems require Sizing help from the HANA Center of Excellence or your SAP representative. The
Sizing guidance methodology provided in this document is expected to be used in such an engagement
as well as HANA sizing resources.

Understanding Lumira, Server for HANA Processing

Lumira, Server for HANA has very little impact on HANA. For Lumira, Server for HANA, there is a very
minor amount of processing involved in handling the user session: so small it has near zero impact
unless you are serving 100s of users from one HANA box.
The impact on HANA is the analytics you run. Lumira will display data and visualizations based on your
data and views, etc. If you create calculated views that are very complex (e.g. JOIN operation or a
calculated expression, etc.), that will cause a lot of processing when displayed by multiple Lumira users.
If you have a number of users running Lumira, that query impact will be multiplied by the number of
active concurrent users. That is where sizing becomes very important: you need to predict the load that
your users will create and make sure you have enough HANA power to accommodate it.
Unlike a traditional BI system which leverages intermediate caching and disk-based database system,
Lumira, Server for HANA is built natively in HANA and pushes most of the calculations down to the index
servers and processes the queries in-memory. As a result, there may not be a substantial difference in
the load generated in the system by either a consumer or an analyst. Whenever a user performs an
action that changes the state of the current view, all the calculations are executed again and dynamically
provide you with the updated content.

15

SAP SE Lumira Sizing Guide

Clustering
If you have a cluster of HANA machines, its important to know that the analytic impact depends on
where the data is stored. For example, if machine A has Lumira, Server for HANA installed and the data
being analyzed is stored on machine B, the impact of the Lumira analytics will be on machine B since
that is where the data is and that is the HANA node that will be doing the processing of the queries on
that data.
In-Memory Multi-User Computing
HANA runs data analytics and queries in-memory. This makes sizing different since the processing is
CPU-oriented. When HANA runs a significantly complex analytic query, the processing is spread across
all the CPUs in the machine in order to complete the processing with the greatest speed.
In a multi-user scenario, queries are executed concurrently via multiple threads. In situations where a
complex query takes notable time to process, any subsequent queries may need to wait until the
complex query is processed if all threads / CPUs are not available. See the Tuning Options section below
for performance-related tips.

Lumira, Server for HANA Sizing Methodology

Sizing a Lumira, Server for HANA deployment requires pre-planning so that calculations and predictions
can be made about the needs of the system. The number of users and the workflow of those users can
be used to predict load on the system. The types of data sets used have an effect on the load and needs
of the system as well.
Note: Sizing Lumira, Server for HANA applies to both on premise deployments and also HANA Enterprise
Cloud (HEC) deployments.
Once the user requirements are defined, the system can be defined that will achieve the required
amount of processing.
Sizing Steps and Methodology
The approach to sizing is to work through the requirements of your data sets on the HANA system and
then sizing for the load that is added by the Lumira tool workflows. These steps take into account the
data sets that will be used and the number and types of users that will access it. The goal is to predict
the workload that will be produced and ensure that adequate HANA resources are available.
Assumptions
It is assumed that the memory requirements of the HANA machines has been determined and
appropriate deployment calculations for hosting that data have been made. See the section below
regarding basic HANA sizing.
Prerequisites
The goal of the sizing exercise is to calculate the peak load that will be placed on the system. In order to
proceed with the steps below, you need to know the following:
Users: How many active concurrent Consumers and Analysts will be using the system?
16

SAP SE Lumira Sizing Guide

Workflow: Common user workflows are necessary to know. Expected user workflows need to be
accounted for since that is the load that needs to be accommodated. If you expect users to open five
documents and refresh them all at the same time, that is five times the load of one user. Knowing how
the users will actually use the system is important.
It is very important to know if the common workflow of the users is going to include refreshing
documents and if so, how frequently. Thats an important part of the load prediction and thus the sizing
estimate. The use of query result caching in HANA is an important factor here. Caching can significantly
help reduce load on the system if it is acceptable and allowed in the business context. I.e., it may be fine
for users to see slightly outdated data (seconds or minutes old). Conversely, if all users have a unique
security context that prevents query sharing, then caching will not have much effect on performance.
The following diagram demonstrates how various user workflows may fit together to form the overall
load on a HANA system.

Figure 1: Sample of overlapping workflows

Average Query Response Time: The amount of time it takes to run representative queries against your
data is required. Average and/or 90th percentile response time needs to be measured using
representative data sets from the customer.
Tip: HANA Studio can be used to obtain query execution time. The best method for measuring query
performance is done with Lumira, Server for HANA, using user simulation scripts run by Apache JMeter
or HP LoadRunner. However, in the absence of Lumira, Server for HANA, prediction and simulation can
be done using Lumira Desktop connected to a HANA system.
Scripts should be written to simulate expected workflows of users. User simulation is meant to
approximate the actions of users, incorporating the steps they take through the product. Be sure to
allow for think time at the appropriate places in the workflow. Once user workflows are modelled, the
goal is typically to have the ability to instantiate multiple script sessions to simulate multiple users. You
then analyze the performance of the system as load is increased.

17

SAP SE Lumira Sizing Guide

HANA Cluster Considerations

If you are doing sizing on a cluster of HANA machines, it is important to do the following workflow
analysis and then determine which of the HANA machines performs the most processing. From a sizing
perspective, you want to determine if your HANA cluster can handle the load you predict it needs to
accommodate. In the sample workflows you perform, the peak load (and thus sizing capacity) is capped
by the highest loaded HANA node.
The reason for this is that HANA performs the analytics and query calculations on the node that holds
the data. The result of your representative workflows may show one HANA machine doing more
processing than another in accordance with the data distribution and the analytics on it.
In the case that a HANA node will not scale to the number of users you need, the main course of action
is to redistribute the data within your cluster to spread out the processing. You may have capacity within
your existing cluster or you may need to acquire more HANA hardware to achieve your needs.

Sizing Calculation
Sizing Lumira, Server for HANA is done by factoring together the number of users, the user types and
their expected activity frequency and the time required to execute an average query.
Step 1: Workflow Analysis
In this step you measure the single-user execution time of each step of the identified workflows.
This can be done in one of two ways:
1. Using Lumira Desktop with HANA
requires Lumira 1.16 or newer.
2. Using Lumira, Server for HANA on HANA
Query execution times are measured by turning on Query Tracing in HANA Studio to determine how
much time is spent querying data for a given step of a workflow.
For more information on Query Tracing, see the Performance Trace tool, documented in the HANA
Admin Guide.
For each step of a workflow, make sure to allow enough time for the completion of the step so that all
the data has been delivered to the browser. Waiting for one minute between steps is generally
recommended.
For Each Workflow
Measure the CPU processing time
Step 2: Processing Load Calculation
In this step, determine the percentage of processing capacity that each workflow consumes, taking into
account the users role type and associated think time. The CPU processing time for the workflow is
measured by HANA and shown using HANA Studio. Finally, determine how much of the total processing
capacity is consumed as a percentage.

18

SAP SE Lumira Sizing Guide

Note: CPU Time is the amount of processing power available during a period of time. For example, if a
system has 10 CPUs and the workflow to be measured takes 60 seconds, the system sitting idle would
be assumed to have 60 x 10 = 600 seconds of CPU time available. When HANA Studio reports CPU usage,
it reports it as a measure of CPU time used.
For Each Workflow:

Use HANA Studio to measure the CPU processing time (PROCESS_CPU_TIME)

Note: do this for all HANA nodes in a cluster, then take the processing time from the most
loaded node. See the HANA Cluster Considerations section above for more information.

Divide the full user time for the workflow by the CPU processing time to get the percentage of
system load produced.
Note: calculate the full user time as the amount of time all the CPUs provide during the user
workflow time. E.g., if the workflow takes 60 seconds and the machine is a 10 CPU system, that
HANA system will have had 600 seconds of CPU time available during that time period.

Multiply the number of required active users by the system load percentage to determine the
full system impact of this workflow
If the load on the HANA system is nearing its limit, you need to consider changes to
accommodate the load (by obtaining more HANA resources, changing the workflows,
redistributing the data in a cluster, etc.).

Step 3: Multi-User Session Load

Each user of Lumira, Server for HANA has an impact on the server. This is the processing required to
manage the users session and deliver content as requested. This is not to be confused with the analytics
load, which is calculated above and impacts the HANA servers where the data resides.
For each active user of the system, 1/20th of a CPU should be included in the sizing calculation. The
memory system impact of a user session is negligible for the purposes for sizing.
Step 4: Deployment
In this final step, sum the system impact of all the workflows to determine the number of HANA
machines required. For example, if the percentages sum to more than 100, additional HANA machines
will be needed to support the predicted user load.
Notes:
This sizing algorithm assumes peak usage of the system is no worse than an evenly distributed pattern of
workflows. It assumes that adding the percentage of system load by all workflows is valid. If you
anticipate greater peak load and want to ensure that peak load is supported in a responsive manner,
you should adjust your workflows, user think times and number of active users accordingly.

19

SAP SE Lumira Sizing Guide

Tuning Options
The following aspects of queries can have a significant influence on performance. You may choose to
investigate these topics when attempting efforts to make your HANA usage as efficient as possible:

20

High cardinality (dimensions with 100,000+ unique values)

Time Dimensions
Calculation Views (can be slower than a similar Analytic View)
Joins against one or more tables (as opposed to a single fact table that includes all necessary
dimensions).
Avoid unnecessary complexity in models built on your data
For very large data volumes (hundreds of millions of records or more), partition the data
Take advantage of HANA features such as query result caching where possible

SAP SE Lumira Sizing Guide

Appendix: Obtaining CPU Processing Time using HANA Studio

HANA records CPU processing time statistics at all times. In order to determine the CPU processing time
for your workflow, you should first attempt to arrange exclusive use of the HANA system in order to
isolate the measurements to just the side-effects of your workflow.
HANA Studio is required to obtain the performance statistics. You can obtain HANA Studio here:
http://scn.sap.com/community/developer-center/hana

Find the Performance Information

Once you open HANA Studio and have connected to your HANA environment, you open the Catalog and
located the _SYS_STATISTICS node as shown here:

Find the tables node and open the table HOST_SERVICE_STATISTICS, as shown here

21

SAP SE Lumira Sizing Guide

The next step is to determine the baseline idle CPU usage for the Index Server. Find two points in time
that define an idle period as shown below:

Scrolling farther to the right, locate the PROCESS_CPU_TIME column and make note of the CPU time at
the start and end of the time period, as shown below:

22

SAP SE Lumira Sizing Guide

Calculation
Overall Time Duration: 4:04 to 4:05 60 seconds
The number of seconds of CPU time is determined by multiplying the number of seconds times the
number of CPUs in the system. For a 10 CPU system in this example: 60 * 10 = 600 seconds of CPU
time
CPU Time used: 76,725,080 76,723,740 = 1340 ms 1.3 seconds
Percentage of HANA processing power used: 1.3s 600s = 0.002166 0.22%

23

SAP SE Lumira Sizing Guide

Appendix: Sizing SAP HANA

Sizing resources for HANA and most SAP products can be found here https://websmp102.sapag.de/performance-scalability
Find the SAP In-Memory Computing area

An additional HANA Sizing resource on the SAP Community Network is the article, SAP HANA Sizing.

24

SAP SE Lumira Sizing Guide