SAP Lumira Sizing Guide -...

September 29, 2016

SAP Lumira

Sizing Guide

2 SAP SE Lumira Sizing Guide

Contents Document Update History ....................................................................................................................... 5

Who should use this document?.............................................................................................................. 6

Prerequisites for Sizing ............................................................................................................................ 6

Terminology ............................................................................................................................................ 7

Think time ....................................................................................................................................... 7

Users ............................................................................................................................................... 7

Sizing SAP Lumira, Server for teams and SAP Lumira, Server for BI Platform ............................................ 9

Understanding Memory Management ................................................................................................. 9

Sizing Lumira, Server for BI Platform .................................................................................................. 10

Lumira, Server for BI Platform Architecture.................................................................................... 11

Tuning Options .............................................................................................................................. 13

Sizing Lumira, Server for teams .......................................................................................................... 14

Sizing SAP Lumira, Desktop Edition ........................................................................................................ 15

Memory Settings ............................................................................................................................... 15

Multi-User Sizing ............................................................................................................................... 15

Sizing Memory (RAM) .................................................................................................................... 15

Sizing Disk (User Profile) ................................................................................................................ 15

Sizing SAP Lumira, Server for HANA ....................................................................................................... 16

Lumira, Server for HANA Pre-Sizing Checklist ..................................................................................... 16

Getting Started with HANA and Lumira, Server for HANA .................................................................. 17

Understanding Lumira, Server for HANA Processing........................................................................... 17

Lumira, Server for HANA Sizing Methodology .................................................................................... 18

Sizing Steps and Methodology ....................................................................................................... 18

Assumptions .................................................................................................................................. 18

Prerequisites.................................................................................................................................. 18

HANA Cluster Considerations ......................................................................................................... 20

Sizing Calculation ........................................................................................................................... 20

Tuning Options .................................................................................................................................. 22

Appendix: Obtaining CPU Processing Time using HANA Studio............................................................... 23

Find the Performance Information..................................................................................................... 23

Calculation ........................................................................................................................................ 25

Appendix: Sizing SAP HANA ................................................................................................................... 26


Appendix: Sizing Lumira, Server for BI Platform ..................................................................................... 26


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. Oracle is a registered trademark of Oracle Corporation.

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

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.

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

Documentation in the SAP Service Marketplace You can find this documentation at the following address: http://service.sap.com/sizing

http://service.sap.com/sizing


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.

Sep 29 2016 Added guidance SAPS value and recommendations for Hana Online Documents in

Lumira, Server for BI Platform section to reflect the Lumira 1.31 release.

Added recommendations for Lumira 1.31 in Tuning Options section.

Added reference Dataset details for Lumira 1.31 in Appendix section.


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.

http://scn.sap.com/docs/DOC-33126


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.


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.


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.

http://scn.sap.com/docs/DOC-33126http://www.sap.com/bivirtualizationhttp://www.sap.com/bivirtualizationhttp://www.sap.com/bivirtualization


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.

Document Type Categories Recommended Maximum Active Concurrent Users

Hana Online documents*

Medium Document 25 35 50

Recommended Configuration

Scenario

Minimum memory required (RAM in GB) 32 48 64

SAPS Value 8550 25700 25700

Table 1.a: Sizing Recommendations for Lumira, Server for BI Platform (Online)

Document Type Categories Recommended Maximum Active Concurrent Users

Offline documents* Medium Document 10 12 15

Small Document 15 25 35

Recommended Configuration Scenario

Minimum memory required (RAM in GB) 32 48 64

SAPS Value 8550 25700 25700

Table 1.b: Sizing Recommendations for Lumira, Server for BI Platform (Offline)

* Refer to Dataset details in the Appendix section.

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

https://websmp207.sap-ag.de/~sapidb/012002523100001293012015E/https://websmp207.sap-ag.de/~sapidb/012002523100001293012015E/


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

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: 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.

http://scn.sap.com/docs/DOC-63551http://scn.sap.com/docs/DOC-26507


Tuning Options Recommended Server configuration has a significant influence on performance. You may choose to investigate these topics, when attempting efforts to make your usage as efficient as possible:

Following are few server configuration parameters that could improve scalability. However, its recommended to update the following parameters in your deployment landscape & check with a basic load test.

Lumira Server properties: -Dhanaview.connection.pool.size=100

-Xms1024m Tomcat Server:

-XX:+CMSClassUnloadingEnabled

-XX:+UseConcMarkSweepGC

Increase the Maximum Memory pool to 4096Mb


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 4 8

500,000 32GB 8 10

100,000,000 32GB 8 4

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.


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 in-memory 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.

https://service.sap.com/~sapidb/011000358700001095842012E


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?


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.


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?


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.


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.

https://help.sap.com/hana/SAP_HANA_Administration_Guide_en.pdfhttps://help.sap.com/hana/SAP_HANA_Administration_Guide_en.pdf


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.


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:

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


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

http://scn.sap.com/community/developer-center/hana


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:


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%


Appendix: Sizing SAP HANA Sizing resources for HANA and most SAP products can be found here https://websmp102.sap-

ag.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.

Appendix: Sizing Lumira, Server for BI Platform Documents used for Lumira, Server for BIP sizing

Document Definition

Hana - Online Document

Document without blending

Document with blending

Document physical size ~915KB ~441KB

Total No. of rows across multiple datasets 642613 280839

Total No. of columns across multiple datasets 118 125

Total No. of cells across multiple datasets ~75M ~39M

Number of Datasets 1 2

Number of Stories 1 1

Number of visualization 7 9

Blending Enabled No Yes

Table 5: Typical data set used for Lumira, Server for BI Platform (Hana online doc) *The sizing recommendations remain the same for documents with blending and without blending

https://websmp102.sap-ag.de/performance-scalabilityhttps://websmp102.sap-ag.de/performance-scalabilityhttp://scn.sap.com/community/hana-in-memory/blog/2013/01/17/sap-hana-sizing


Document Definition Offline Document

Small Document Medium Document

Document physical size ~1.4MB ~252MB

Total No. of rows across multiple datasets 22972 2347119

Total No. of columns across multiple datasets 34 76

Total No. of cells across multiple datasets ~0.7M ~59M

Number of Datasets 2 5

Number of Stories 1 1

Number of visualization 5 7

Blending Enabled No No

Table 6: Typical data set used for Lumira, Server for BI Platform (offline doc)

SAP Lumira Sizing Guide -...

Documents

Transcript of SAP Lumira Sizing Guide -...