Special 2-Part Session: Part
2: SAP BusinessObjects
Dashboards Best Practices:
Top 20 Factors That Affect
Your Dashboard Usability,
Integration, and Performance
Dr. Bjarne Berg
COMERIT
© Copyright 2013
Wellesley Information Services, Inc.
All rights reserved.
In This Session …
•
•
•
•
•
Look at how to design for performance and how to size a BI 4.x
environment correctly
Explore how to use SAP HANA for dashboarding
Explore some of the methods to dramatically improve SAP
NetWeaver BW-based dashboard performance
Identify factors that can lead to poor performance in design of
dashboards and what connection options work best to ensure
performance
Step through demos that illustrate high-performing, complex, and
interactive dashboards in action
This is Part 2 of a 2-part session. For more information, see the Special 2-part
session: Part 1: SAP BusinessObjects Dashboards best practices: Lessons to
design and deploy interactive dashboards session.
1
What We’ll Cover …
•
•
•
•
•
•
•
Introduction
Designing for performance
SAP BusinessObjects BI 4.x sizing guidelines
SAP HANA dashboard performance options
SAP NetWeaver BW dashboard performance tricks
Performance and stress testing
Wrap-up
2
Functionality vs. Performance — What Wins?
3
What We’ll Cover …
•
•
•
•
•
•
•
Introduction
Designing for performance
SAP BusinessObjects BI 4.x sizing guidelines
SAP HANA dashboard performance options
SAP NetWeaver BW dashboard performance tricks
Performance and stress testing
Wrap-up
4
Dashboard Objects That Can Cause Slow Performance
These are dashboard objects that you need
to carefully consider before employing
5
The Speed and Performance of Web Services
•
Dashboards can
link to external Web
services
•
This dashboard
uses both a
newsfeed and
Google maps
•
This can slow down
the performance
due to external
server loads,
security scans, and
network speed
6
Excel Performance Considerations — What to Avoid
•
•
The logic you build into your Excel spreadsheet is also compiled into
the Flash file when you export it
Since some “daisy-chain” functions are very time consuming, you
should be careful not to add too many conditions in the data
 Lookup functions and conditioning that should be avoided include:

Lookups





Mid strings (MID)
Right and left strings (RIGHT/LEFT)
Horizontal Lookups (HLOOKUP)
Vertical Lookups (VLOOKUP)
Condition



General conditioning (IF)
Count if a condition is true (COUNTIF)
Sum if a condition is true (SUMIF)
Complex logic and nested logic create large SWF files and take a long time to open. Try
to keep as much of the calculations and logic in the query instead of the spreadsheet.
7
Connectivity
•
A key factor is to decide what connections to use. BICS is preferred, but
has some limitations in mapping graphs to queries. MSUs are slower,
but have more flexibility. Acceleration and in-memory data stores help
significantly.
Source: SAP
8
More Key Factors That Determine Dashboard
Performance
•
•
•
•
•
•
Concurrent number of users during peak load times of system
Logical design of dashboards
 Simple, complex, and incredibly complex
 Number of records retrieved by the dashboards
Network capacity
Database speed of source data
Number of instances
 This is used for spreading
service loads on multiple nodes
Number of CPUs and available memory of each server
9
What We’ll Cover …
•
•
•
•
•
•
•
Introductions
Designing for performance
SAP BusinessObjects BI 4.x sizing guidelines
SAP HANA dashboard performance options
SAP NetWeaver BW dashboard performance tricks
Performance and stress testing
Wrap-up
10
Hardware: Server-Side Requirements
From a server sizing perspective you need:
Minimum CPU
 4 x 2.0 GHz Core CPU
Minimum Memory of Server
 Min of 8.0GB memory – 16GB recommended
(but more based on number of users)
Minimum Disk Space
 If you only install English: 11GB Windows;
13GB AIX/Solaris; and 14GB for Linux
 If you install all languages: 14GB Windows;
15GB AIX/Solaris; and 16GB for Linux
11
SAP BusinessObjects Sizing for Performance
Dashboards
SAP has
provided a sizing
tool for the BI
environments. It
is based on
Flash and is
actually a
dashboard itself.
Output Area
(Sizing Results)
Download it:
www.sdn.sap.com/irj/scn/index?ri
d=/library/uuid/1055c550-ce452f10-22ad-a6050fff97f1
Input Areas
(items and users)
This tool can help you size your BI 4.0 environments with few key assumptions and inputs
12
The Sizing Tool — Entering Users
First, you have
to enter the
estimated
active
concurrent
users (ACU) for
the following
user types:
• Information
Consumers
•
Business
Users
•
Expert Users
13
Dashboard User Classification
The tool provides online
definitions of the user types and
guidelines on how to determine
active concurrent users (ACU).
This is defined as approximately
10% of the active users.
Many dashboard users in large
organizations may be classified
as Information Consumers.
They may not wait five minutes
between clicks, but typically do
little drill down and filtering.
14
Dashboard Size Impacts
The next step is to make an assumption on the size of dashboards
• The sizing tool classifies small dashboards as having 25 rows in the
result set, medium having 250, and large dashboards having 2,500 rows
•
Assumptions: The tool was based on supporting two queries per
dashboard and benchmarked for accessing two relational data sources.
One with six dimensions with 77,000 entries and 400,000 line items, and
one with six dimensions with 7,000 rows and 40,000 line items.
15
Dashboard Environment Sizing Output
•
The output of the tool is measured in SAP Application Performance Standard (SAPS).
100 SAPS is defined as 2,000 fully business processed order line items per hour.
•
It is a measure that hardware vendors can use to decide which of their configurations
can meet your performance requirements. All hardware vendors are familiar with this
measure and this is what you will provide them when requesting a hardware quote. 16
Memory Requirements for Dashboards and BI 4.x
The sizing tool also provides a sizing estimate for
the hardware memory required for each of the tiers.
This is measured in Gigabytes.
17
Saving Your Assumptions and Results
Your BI and dashboard sizing effort can be saved or printed from
the tool and you can have many scenarios (i.e., best/worst case)
18
Sizing Demo
19
Sizing Companion Guide
The 45 page sizing
documentation covers most
SAP BusinessObjects
tools and provides
recommendations and insights
into what assumptions the
tools rely on
Download it at:
http://tinyurl.com/ctlseb4
20
The Different Tiers in SAP BI
•
•
•
First we have the application tier. This includes
the Web Application Services such as the Central
Management Console (CMC), and the BI Launch Pad.
 SAP recommends adding a Web Application Server for each 500
ACUs and that at least 5GB heap memory is assigned and 900 threads
are configured.
The next is the intelligence, or management tier. This includes
the dashboard cache service, File Repository Service (FRS), and the
CMS.
 Only the first input and output File Repository Service (FRS) pair to
register in the CMS is the active pair. If you add more FRSs, these are
assumed to be passive backups for fault tolerance and failures.
Lastly we have the processing tier. This includes the Adaptive Job
Service and the Processing Services for the various BI tools.
 Each BI tool has different memory and processor requirements.
21
Dashboard Performance — Some
Recommendations
•
You can scale the number of instances based on the active
concurrent users (ACUs), and SAP has made some
recommendations:
 The CMS can handle up to 500 ACUs per instance and you can
currently scale this to eight instances (will be increased in next
release). You can add more CMSs if you see over 80%
utilization of the CPUs.
 The dashboard cache can handle up to 400 ACUs per instance
and you can add as many instances you want (no limitations),
but you are unlikely to need more than one.
 The dashboard processing is normally one per machine with no
limitations (the server automatically spawns and manages child
processes). If you need more, add more instances.
22
Real-World Examples
Tool
Area
SAP BW
BW Version
Named Users (#)
Dashboards Concurrent Users (#)
Simultaneous Requests (#)
Named Users (#)
Analysis
Concurrent Users (#)
Simultaneous Requests (#)
Named Users (#)
WebI
Concurrent Users (#)
Simultaneous Requests (#)
Server Memory
Server Disk
Hardware PC Memory (standard)
PC CPUs (standard)
Portal version
Server Operating System
Other
Flash version
Database Version
Performance overall (1-10) *Subjective
Manufacturing
Company
7.3
192
7-8
5-10
45
6
4-5
16 GB
100 GB
4 GB
2.33 GHz
(dual core)
WebSphere
AIX
11
SQL express
9
Airline
7.3
503
30-35
4-10
84
22
5-15
16 GB
95 GB
2 GB
Pharma
distributor
7.0 Enpk 1
168
26
4-20
8 GB
120 GB
2 GB
2.0 GHz
2.0 GHz
(dual core)
SAP
SAP
Win 2008
Win 2008
11
10
SQL express SQL express
8
8
Paper
company
Retailer
7.3
109
11-14
3-8
63
7
2-3
~30
7
2-3
8 GB
70 GB
4 GB
2.3 GHz
(dual core)
SAP
Win 2008
11
SQL
7
7.0 Enpk 1
309
22
5-15
46
6-8
7-10
1604
60-70
18-40
32 GB
230GB
4 GB
2.3 GHz
(dual/quad core)
SharePoint
Win 2008
11
SQL
9
These are real examples from companies that have been using BI 4.0 for at least 6 months
23
What We’ll Cover …
•
•
•
•
•
•
•
Introductions
Designing for performance
SAP BusinessObjects BI 4.x sizing guidelines
SAP HANA dashboard performance options
SAP NetWeaver BW dashboard performance tricks
Performance and stress testing
Wrap-up
24
Why In-Memory Processing?
Focus
Technology
1990
2013
Improvement
CPU
0.05
389.32
MIPS/$
MIPS/$
7796x
Memory
0.02
97.5
MB/$
MB/$
Addressable
Memory
216
264
248x
Network
Speed
100
100
Mbps
Gbps
1000 x
Disk
Data Transfer
5
732
MBPS
MBPS
4875x
146x
Source: 1990 numbers SAP AG, 2013 numbers, Dr. Berg
Source: BI Survey of 534 BI professionals, InformationWeek,
Disk speed is growing slower than all other hardware components,
while the need for speed is increasing
25
An Example of an SAP HANA System
•
The long-term idea with HANA is to replace the databases under SAP
NetWeaver BW and SAP ERP with in-memory processing databases,
instead of traditional relational databases. This means much faster
query response time and a smaller database.
HANA is an appliance
that can be implemented
fast, is cost effective,
and can super-charge
the data delivery and
calculations in your
dashboards!
26
Rapid Development: Dashboard on HANA
Step 1: Creating Tables and Loading Data to HANA Using SAP
Data Services
See complete first demo at:
www.insiderlearningnetwork.com/dr_berg/blog/2012/11/02/demo:_loading_non-sap_data_to_hana
With sound and high-def
27
Rapid Development: Dashboard on HANA
(cont.)
Step 2: Building HANA Views
See complete scenario in SAP HANA: An Introduction by Bjarne Berg and Penny Silvia,
SAP PRESS; 2nd ed (May, 2013), pages 263-289
28
Rapid Development: Dashboard on HANA
(cont.)
Step 3: Picking up HANA Views in a Universe
See complete scenario in SAP HANA: An Introduction by Bjarne Berg and Penny Silvia,
SAP Press; 2nd ed (May, 2013), pages 204-212
29
The Dashboard Result
30
What We’ll Cover …
•
•
•
•
•
•
•
Introductions
Designing for performance
SAP BusinessObjects BI 4.x sizing guidelines
SAP HANA dashboard performance options
SAP NetWeaver BW dashboard performance tricks
Performance and stress testing
Wrap-up
31
The Need for Targeted BEx Queries
•
For the supporting BEx queries, it
is important that they:
• Are copied over and renamed
to reflect where used
• Filters are added where
appropriate
• CKF and RKFs are precalculated in the data store
(DTP) so that queries are
faster
• Sorts are avoided in query and
done on the dashboards
instead by end users, if
needed
• Data are mapped to “details”
tab for each panel to display
only what is needed
BEx queries are targeted to each
dashboard and some will require
more then one query. The design
will depend on what your company
already has in place, but back-end
work is normally required.
32
The Need for Back-End Design — Snapshot Cubes
•
In this example, snapshot cubes are added for performance
reasons
An alternative is
to limit data
scope and
develop the
dashboards on
low-volume
snapshot cubes
Theses can also
be placed in SAP
BWA or HANA
for very high
performance
33
The Need for Back-End Design — Summary Cubes
•
Sometimes, summary cubes are
required to speed performance of
queries
•
Depending on existing design,
MultiProviders may also be
added
•
APD is the preferred way of
populating these InfoProviders
The summary, or snapshot data,
can be accessed much faster than
underlying data tables with millions
of records
34
What We’ll Cover …
•
•
•
•
•
•
•
Introductions
Designing for performance
SAP BusinessObjects BI 4.x sizing guidelines
SAP HANA dashboard performance options
SAP NetWeaver BW dashboard performance tricks
Performance and stress testing
Wrap-up
35
The SAP BusinessObjects Load Testing Form
Dashboard Name:
•
•
The load testing is
intended to show any
performance issues prior
to the go-live
Estimated number of named users
Concurrent
User Type
Number
Factor
Users
Casual Users (less then 2-5 times monthly)
20%
Power Users (daily)
40%
Executive Users (2-10 times monthly)
25%
Total:
While all areas cannot be
tested, this will give you
an idea on bottlenecks
Batch script created (i.e. Java script)
Load Testing
Test lab setup
Number of PCs required
(concurrent users divided by 5)
5 copied of script installed on each PC
Execution
Start scripts on each PC
(continuous loop)
Pass
Issue
Findings
Monitor BOBJ BI Server Load
•
For large scale go-lives,
you should consider
having test PCs in
multiple locations
Monitor BW App sever load
Monitor BW Server load
PC load time
(average of 10 dashboard loads)
Comments
36
The SAP BusinessObjects Stress Testing Form
•
Stress testing is very similar
to load testing
•
The difference is that the
number of concurrent users
are expected to be doubled
•
Not all companies will use a
stress test, nor pass it
 This is due to the
unrealistic concurrent
load and the high
hardware costs of
meeting them
Dashboard Name:
Estimated number of named users
Concurrent
User Type
Number
Factor
Users
Casual Users (less then 2-5 times monthly)
40%
Power Users (daily)
80%
Executive Users (2-10 times monthly)
50%
Total:
Stress Testing
Test lab setup
Number of PCs required
(concurrent users divided by 5)
Batch script created (i.e. Java script)
5 copied of script installed on each PC
Execution
Start scripts on each PC
(continuous loop)
Pass
Issue
Findings
Monitor BOBJ BI Server Load
Monitor BW App sever load
Monitor BW Server load
PC load time
(average of 10 dashboard loads)
•
However, it provides very
useful information
Comments
37
The Dashboard Performance Checklist
1. The hardware servers — Check sizing
2. The server locations and networks — Check loads
3. Query review — Look at database and calculation time and design
4. Interface review — Make sure you are using the best for the data source
5. Dashboard review — Look at Excel logic, container usage, number of Flash
6.
7.
8.
9.
objects, sorts, size of result set, and simplification opportunities
In-memory review — Look at cache usage, hit rations, and SAP NetWeaver BW
Accelerator usage
Review data sources — Examine if snapshots can be leveraged and look for
possibilities to create aggregates
Examine compatibilities between browsers, Flash, and Microsoft office
versions
Review PC performance issues — Memory, disk, and processors
Performance is complex, look at more than one area
(e.g., Web portal bottlenecks and LDAP servers)
38
High-Volume User Management and Access
Control
•
•
•
•
Plan for a gradual rollout to a limited number of users
Keep the numbers comparable, if possible
 This will allow you to predict system loads and performance issues
by stipulations from real performance data
 I.e., roll out to 50 users each week
Simplified versions of high-impact dashboards may be created for
casual users
 I.e., a dashboard with only one query and summarized data with
limited navigation and passing of variables
Create a hardware contingency plan and budget
accordingly
Only in rare cases should you use a big-bang approach.
Since user patterns are hard to predict, this may cause
significant performance issues.
39
What We’ll Cover …
•
•
•
•
•
•
•
Introductions
Designing for performance
SAP BusinessObjects BI 4.x sizing guidelines
SAP HANA dashboard performance options
SAP NetWeaver BW dashboard performance tricks
Performance and stress testing
Wrap-up
40
Where to Find More Information
•
•
•
•
•
Ray Li and Evan DeLodder, Creating Dashboards with SAP
BusinessObjects (2nd Edition) (SAP PRESS, 2012).
 ISBN-10: 1592294103
David Lai and Xavier Hacking, SAP BusinessObjects Dashboards 4.0
Cookbook (Packt Publishing, 2011).
 ISBN: 1849681783
SAP BusinessObjects BI 4.0 Sizing Estimator
 www.sdn.sap.com/irj/scn/index?rid=/library/uuid/1055c550-ce45-2f1022ad-a6050fff97f1
Dashboard and Presentation Designer (Xcelsius) forum on SDN
 http://forums.sdn.sap.com/forum.jspa?forumID=302
Official Product Tutorials – SAP BusinessObjects Dashboards
 www.sdn.sap.com/irj/boc/dashboards-elearning
41
7 Key Points to Take Home
•
•
•
•
•
•
•
Use the SAP Sizing tool for initial sizing estimates
Size your system based on concurrent users and SAPS
Use realistic data volumes, users, and dashboard complexity in
your assumptions
Use the SAP system guides on the SAP Service Marketplace, but
plan to operate your system at max. 70% load for “spare capacity”
Keep the SAP BusinessObjects BI 4.0 environment on a separate
stack from SAP NetWeaver BW
Make sure the PCs have enough memory
Examine the “standard” PC of the users and developers; pay
attention to connectivity, screen size and resolutions, CPUs, and
all software release versions to assure compatibility
42
Your Turn!
How to contact me:
Dr. Bjarne Berg
Bberg@Comerit.com
Please remember to complete your session evaluation
43
Disclaimer
SAP, R/3, mySAP, mySAP.com, SAP NetWeaver®, Duet®, PartnerEdge, 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. Wellesley Information Services is neither owned nor controlled by SAP.
44