Download Session Title

Preventing, Diagnosing,
and Resolving the 20
Most Common
Dashboard
Performance Problems
Dr. Bjarne Berg
Comerit
© 2012 Wellesley Information Services. All rights reserved.
14
1
13
Seminar Roadmap
12
Best-in-Class
Deployment,
Dashboards
Testing & Change
Management
• Dashboards vs. reports
•
•
•
•
•
Key dashboard roll-out decisions • Answers to dashboard FAQs
• SAP BusinessObjects Dashboards
Mobilizing your dashboard
4.0 overview
Support organization
• Product updates and
Volume, stress, and UAT
implementation criteria
Training and change management • Recent changes to dashboard
terms
Options &
Prototyping
11 Performance
& Security
10
We are here
2
• Common causes of poor
dashboard performance
• Effective performance testing
• Performance-enhancing design
techniques
• Preventing unauthorized access
to dashboards
• Password protection
Customization,
and SSO
Branding &
Governance
• Hands-on lab: Advanced techniques
• Web service integration and Adobe
Flex Builder
• Panel discussion: Dashboard Projects
• Ownership and branding
9 • Post-production changes
8
7
•
•
•
•
•
Scoping vs. requirements gathering
KPI definitions
Required skills and resources
Data connectivity deep dive
Key criteria to retrieve data sets
Landscape,
Connectivity &
Sizing
• Hands-on lab: Build a dashboard
with BOBJ Dashboards 4.0
• Sizing and scaling recommendations
• User management and access
5
control
®
• SAP NetWeaver BW
Accelerator and
SAP HANA
6
3
4
Background
•
•
We already covered hardware sizing, compatibility, and server
options in an earlier session; so now we will look at the
application, design, and interfaces
We will specifically look at dashboard design, query design,
connectivity impacts, in-memory processing options, as well as
dashboard performance monitoring options
2
Functionality vs. Performance: What Wins?
3
What We’ll Cover …
•
•
•
•
•
•
•
•
Choosing the right connectivity and back end
Exploring query performance
Thinking about the dashboard design
Increasing query performance with infrastructure and in-memory
processing
Leveraging pre-caching capabilities and aggregates
Obtaining strategies for performance testing: Load and stress
Looking at EarlyWatch Reports and the performance checklist
Wrap-up
4
Problems #1 and #2: Connectivity and Performance
•
As we covered in the earlier session, the type of connectivity
matters for the performance
•
BICS connectors perform well
•
Avoid the MDX interface
(it is slow)
•
Avoid direct
access to the
InfoProviders
since this
bypasses
the BI analytical
engine in SAP
NetWeaver® BW
Source: SAP AG, 2012
Always pick the fastest interface available for the data source you are building dashboard on
5
Problem #3: Data Connectivity — SAP Crystal Reports and
SAP BusinessObjects Live Office
•
•
•
You can use transient providers
to create real-time dashboards on
top of SAP ERP data
You can also use SAP Crystal
Reports for detailed drill-down
analysis
If you always use the “refresh on
load” option for Live Office
connections, your users will
experience periodic slow
performance
By leveraging the aggregation in SAP Crystal
Reports, you can also get faster SAP
Dashboards (formerly Xcelsius®) response
time
6
Problem #4: Back End — Build on a Solid
Performance Foundation
Modularize the data and create
sub-sets of data for really fast
dashboarding
Generic “metrics” data tables
can be created for
summarized KPI and
scorecard dashboards
The summary, or snapshot, data
can be accessed much faster
than underlying data tables with
millions of records
Problem #5: Back End — Dashboard Performance
Architecture
In this example, the company uses snapshots for performance reasons
•

Dashboards for
executive users

Pre-delivered SAP
BusinessObjects
Web Intelligence
reports for casual users

Ad hoc SAP BusinessObjects Web
Intelligence reports for power users
The dashboards are only built on
the low-volume daily snapshot
cube (this is also placed in SAP
NetWeaver BW Accelerator for very
high performance)
8
What We’ll Cover …
•
•
•
•
•
•
•
•
Choosing the right connectivity and back end
Exploring query performance
Thinking about the dashboard design
Increasing query performance with infrastructure and in-memory
processing
Leveraging pre-caching capabilities and aggregates
Obtaining strategies for performance testing: Load and stress
Looking at EarlyWatch Reports and the performance checklist
Wrap-up
9
Problem #6: Query Read Modes
•
There are three query read modes that determine the
amount of data to be fetched from a database and sent to
the application server
1. Read all data
 All data is read from a database and stored in user
memory space
2. Read data during navigation
 Data is read from a database only on demand during
navigation
3. Read data during navigation and when expanding the hierarchy
 Data is read when requested by users in navigation
Reading data during navigation minimizes the impact on the
application server resources because only data that the user requires
will be retrieved
10
Problem #7: Recommendation — Query Read Mode for
Large Hierarchies
•
•
For queries involving large hierarchies, it is smart to select “Read
data during navigation” and when expanding this option to avoid
reading data for the hierarchy nodes that are not expanded
Reserve the Read all data mode for special queries
 I.e., when a majority of the users need a given query to slice and
dice against all dimensions, or data mining
 This places heavy demand on database and memory resources,
and may impact other SAP NetWeaver BW processes
 A query read mode can be defined on an individual query or as
a default for new queries (transaction RSRT)
Recommendations for OLAP universes and SAP BusinessObjects Web Intelligence analysis




Use of hierarchy variable is recommended
Hierarchy support in SAP BusinessObjects Web Intelligence for SAP NetWeaver BW
is limited
The Use Query Drill option significantly improves drill-down performance
Look at the Query Stripping option for power users
11
Problem #8: Reduce the Use of Conditions and Exceptions
Reporting
•
•
•
Conditions and exceptions are usually processed by the
application server
 This generates additional data transfer between database and
application servers
If conditions and exceptions have to be used, the amount of data
to be processed should be minimized with filters
 When multiple drilldowns are required, separate the drill-down
steps by using free characteristics, rather than rows and
columns
BENEFIT: This results in a smaller initial result set and, therefore,
faster query processing and data transport, as compared to a
query where all characteristics are in rows
This approach separates the drill-down steps. In addition to accelerating query
processing, it provides the user more manageable portions of data.
12
Performance Settings for Query Execution
This decides how many records are read during navigation
Examine the
request status
when reading
the InfoProvider
In SAP NetWeaver
BW 7.x, the BI
Analytical engine
can read deltas into
the cache. Does not
invalidate existing
query cache.
Turn off/on parallel
processing
Displays the level of
statistics collected
When will the
query program be
regenerated based
on database
statistics?
13
Problem #9: Filters in Queries Used in Dashboards
•
Using filters contributes to reducing the number of database
reads and the size of the result set
 Thereby significantly improving query runtimes
Filters are especially
valuable when associated
with large dimensions
where there are a large
number of characteristics,
such as customers and
document numbers
14
Problem #10: The RSRT Transaction to Examine Slow
Queries
P1 of 3
The RSRT transaction is one of the
most beneficial transactions to
examine the query performance and
to conduct “diagnostics” on slow
queries from the SAP NetWeaver
BW system
15
Do You Need an Aggregate: Some Hints
P2 of 3
This suggests that an Aggregate
would have been beneficial
16
Get Database Info
P3 of 3
In this example, the Basis
team should be involved to
research why the Oracle
settings are not per SAP’s
recommendation
The RSRT and RSRV codes
are key for debugging and
analyzing slow queries
HINT: Track front-end data transfers and OLAP
performance by using RSTT in SAP NetWeaver BW 7.3
(RSRTRACE in SAP BW 3.5)
17
Problem #11: Debug Queries Using the RSRT Transaction
Using RSRT you can execute the
query and see each breakpoint,
thereby debugging the query and
seeing where the execution is
slow
Try running slow queries in debug mode
with parallel processing deactivated to
see if they run faster
18
Recommendation for Key Figures in OLAP Universes
•
•
•
A large number of key figures (KFs) in the BEx query will incur a
significant performance penalty when running queries, regardless
of whether the key figures are included in the universe
Only include key figures used for the dashboard in the BEx query
(keep it small)
This performance impact is due to time spent loading metadata
for units, executed for all measures in the query
•
•
After SAP BusinessObjects Enterprise XI 3.1 FP 1.1, the impact of large
numbers of key figures was somewhat reduced by retrieving metadata
information only when the unit/currency metadata info is selected
However, this is still best practice
19
Problem #12: The Performance Killers — Restrictive
Key Figures
•
When Restrictive Key Figures (RKF) are included in a query,
conditioning is done for each of them during query execution
 This is very time consuming, and a high number of RKFs can
seriously hurt query performance
•
My Recommendation: Reduce RKFs in the query to as few as
possible
 Also, define calculated key figures and RKFs on the
InfoProvider level instead of locally within the query. Why?
Benefit: Formulas within an InfoProvider are returned at runtime and held in cache
Drawback: Local formulas and selections are calculated with each navigation step
20
Dashboard Performance Killers: Calculated Key Figures
•
•
Calculated Key Figures (CKF) are computed during
runtime, and many CKFs can slow down the query
performance
How to fix this
 Many of the CKFs can be done during data loads and physically
stored in the InfoProvider
 This reduces the number of computations, and the query can use
simple table reads instead
 Do not use total rows when not required (this requires additional
processing on the OLAP side)
Recommendation for OLAP universes
• RKF and CKF should be built as part of the
underlying BEx query to use the SAP NetWeaver BW
back-end processing for better performance
• Queries with a larger set of such KFs should use the
“Use Selection of Structure Members” option in the
Query Monitor (RSRT) to leverage the OLAP engine
21
What We’ll Cover …
•
•
•
•
•
•
•
•
Choosing the right connectivity and back end
Exploring query performance
Thinking about the dashboard design
Increasing query performance with infrastructure and in-memory
processing
Leveraging pre-caching capabilities and aggregates
Obtaining strategies for performance testing: Load and stress
Looking at EarlyWatch Reports and the performance checklist
Wrap-up
22
Problem #13: Dashboard Performance Hint — The Number
of Rows in the Result Set
Limit the number
of rows in your
result set to
between 100-500
In exceptional
cases, when you
have leveraged
other performancetuning methods,
you may extend
this to up to 1,000
rows
The Length of each record (# of columns) and
the data type also impacts performance
Returning query result sets with few records of a numeric type or with
keys and indicators provides for the best dashboard performance
23
Divide and Get Performance
Drill-down options
•
•
Link to Details
Dashboard
Split your dashboards into logical units and get new data when drilldowns are executed
This keeps the result set for each query small, and also decreases the load time for
each dashboard
24
Problem #14: 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 calculation and logic in the query instead of the spreadsheet.
25
Problem #15: The BI Analytical Engine and Sorting
•
•
Sorting is done by the BI Analytical Engine
 Like all computer systems, sorting data in a
report with large result sets can be time consuming
Reduce the number of sorts in the “default view”
 This will provide the users with data faster. They can then
choose to sort the data themselves.
User Sorts themselves
Hint: Reducing the text in the query will also speed up the query processing time
26
Problem #16: Dashboard Objects That Can Cause Slow
Performance
These are dashboard objects that you need
to carefully consider before employing
27
What We’ll Cover …
•
•
•
•
•
•
•
•
Choosing the right connectivity and back end
Exploring query performance
Thinking about the dashboard design
Increasing query performance with infrastructure and in-memory
processing
Leveraging pre-caching capabilities and aggregates
Obtaining strategies for performance testing: Load and stress
Looking at EarlyWatch Reports and the performance checklist
Wrap-up
28
Problem #17: It Is All About Performance, Performance,
Performance
•
•
It is hard to build a fast dashboard with many
queries and panels without SAP NetWeaver
BW Accelerator
 This provides in-memory processing of queries
that is 10-100 faster
What we simply do is place the data in-memory and retrieve it
much faster
 There is also some limited OLAP functionality that can be built
into SAP NetWeaver BW Accelerator 7.3, but most data
processing still occurs in the BI Analytical engine
You can also place non-SAP data in-memory
using SAP BusinessObjects Data Services
29
Number of Queries
SAP NetWeaver BW Accelerator Performance Increases:
Real Example
Number of Queries
Seconds
The major
improvement is to
make query
executions more
predictable and
faster overall
Seconds
30
BI Analytical Engine’s Query Executing Priorities
Information Broadcasting/
Pre-Calculation
Information Broadcasting/
Pre-Calculation
Query Cache
Query Cache
Aggregates
SAP NetWeaver
BW Accelerator
InfoProvider
Query Execution
Without SAP NetWeaver
BW Accelerator
Query Execution
with SAP NetWeaver
BW Accelerator
Source: SAP AG
Aggregates can be replaced with SAP NetWeaver BW
Accelerator while the memory cache is still useful
31
Looking Inside SAP HANA: In-Memory Computing
Engine (IMCE)
Metadata
Authorization
Transaction
Manager
Manager
Manager
Relational
Engine
SQL Script
SQL Parser
-Row Store
-Column Store
Calculation
Disk Storage
Data
Volumes
Log
Session
Manager
Engine
MDX
Volumes
Load
Controller
Replication Server
BusinessObjects Data Services
You can also move data to SAP HANA and access the data in-memory;
this creates a much faster response time for all your dashboards
32
SAP HANA: Sources and Target Interfaces
SAP BusinessObjects 4.0
HANA Appliance
ERP
BICS
Real-time
Database
SQL (JDBC/ODBC)
Sybase
In-Memory
Replication
Computing
Server
Engine
DBSQL
Others
SQL (JDBC/ODBC)
SAP BusinessObjects Data Services
SAP BW
MDX (ODBO)
Third Party
A great benefit is the real-time loading of SAP HANA from ERP;
this can provide real-time analytics to end users
33
What We’ll Cover …
•
•
•
•
•
•
•
•
Choosing the right connectivity and back end
Exploring query performance
Thinking about the dashboard design
Increasing query performance with infrastructure and in-memory
processing
Leveraging pre-caching capabilities and aggregates
Obtaining strategies for performance testing: Load and stress
Looking at EarlyWatch Reports and the performance checklist
Wrap-up
34
Problem #18: Different Uses of the MDX and OLAP Cache
•
The OLAP Cache is used by SAP NetWeaver BW as the core
in-memory data set
 It retrieves the data from the server if the data set is available
•
The cache is based on first in  last out
 This means that the query result set that was accessed by one
user at 8:00 am may no longer be available in-memory when
another user is accessing it at 1:00 pm
 Therefore, queries may appear to run slower sometimes
The MDX cache is used by MDX-based
interfaces, including the OLAP universe
35
Use the BEx Broadcaster to Pre-Fill the Cache
Distribution Types
•
•
You can increase query speed by
broadcasting the query result of commonly
used queries to the cache
Users do not need to execute the query from
the database
 Instead, the result is already in the system
memory (much faster)
36
The Memory Cache Size
•
•
•
The OLAP Cache is, by default, 100MB for local and 200MB for
global use
 This may be too low ...
Look at available
hardware and work
with your Basis team
to see if you can
increase this
If you decide to
increase the cache,
use the transaction code RSCUSTV14
The OLAP Cache is not used when a query contains a Virtual Key
Figure or virtual characteristics or when the query is accessing
a transactional DSO or a virtual InfoProvider
37
Monitor Application Servers and Adjust Cache Size
To monitor the usage of the cache on each of the application servers,
use transaction code RSRCACHE, and also periodically review the
analysis of load distribution using ST03N – Expert Mode
P.S.! The size of the OLAP Cache is physically limited by the
amount of memory set in system parameter rsdb/esm/buffersize_kb
The settings are available in RSPFPAR and RZ11
38
The Four Options for OLAP Cache Persistence Settings
CACHE OLAP Persistence Settings
When
Note
Default
Flat file
What
Change the logical file
BW_OLAP_CACHE when
installing the system (not valid
name)
FILE
Medium and small result sets
RSR_CACHE_DBS_IX
RSR_CACHE_DB_IX
Optional
Cluster table
Optional
Binary Large Objects
(blob)
Best for large result sets
Available
since SAP
NetWeaver
Blob/Cluster
BW 7.0 SP 14 Enhanced
T-code
RSR_CACHE_DBS_BL
RSR_CACHE_DB_BL
No central cache directory or lock Set
concept (enqueue). The mode is RSR_CACHE_ACTIVATE_NEW
not available by default.
RSADMIN VALUE=x
39
Problem #19: Correct Aggregates Are Easy to Build
We can create proposals from
the query, last navigation by
users, or by BW statistics
Create aggregate proposals based on queries
that are performing poorly
•
Create aggregate proposals based
on BW statistics. For example:
 Select the runtime of queries to
be analyzed
 Select the time period to be
analyzed
 Only those queries executed in
this time period will be
reviewed to create the proposal
40
Activate the Aggregate
The process of turning 'on' the
aggregates is simple
1. Click on Jobs to
see how the
program is
progressing
41
Fill the Aggregate with Summary Data
What We’ll Cover …
•
•
•
•
•
•
•
•
Choosing the right connectivity and back end
Exploring query performance
Thinking about the dashboard design
Increasing query performance with infrastructure and in-memory
processing
Leveraging pre-caching capabilities and aggregates
Obtaining strategies for performance testing: Load and stress
Looking at EarlyWatch Reports and the performance checklist
Wrap-up
43
Problem #20: Performance Testing — Load and Stress
•
•
Load testing is done to 20% of the named user base
 Turn off the cache (we assume all hits “new data”)
 Execute the dashboard URLs using a tool or a simple
JavaScript
 Monitor database, portal, and BI system load
 Log response time and have multiple browsers and PCs hitting
the data from multiple locations (network testing)
Stress testing is done to 40% of named user base
 The test is done the same way as on the load testing, just with
more “users”
 The system may not be able to pass at this level, but the breakpoints are identified
All dashboard systems should be load tested
to 20% of user base prior to Go-Live
44
Bonus Problem #1: Server Locations and Network Capacity
•
Having a central global install of SAP BusinessObjects BI 4.x with
many users can cause significant network load and performance
issues
Consider the network topology, capacity, and the user
locations before implementing global dashboards
45
What We’ll Cover …
•
•
•
•
•
•
•
•
Choosing the right connectivity and back end
Exploring query performance
Thinking about the dashboard design
Increasing query performance with infrastructure and in-memory
processing
Leveraging pre-caching capabilities and aggregates
Obtaining strategies for performance testing: Load and stress
Looking at EarlyWatch Reports and the performance checklist
Wrap-up
46
Bonus Problem #2: EarlyWatch Reports in SAP Solution
Manager
•
•
•
EarlyWatch reports provide a simple way to confirm how your
system is running and to catch problems
 A “goldmine” for system recommendations
EarlyWatch Reports have been available since SAP Solution
Manager version 3.2 SP8
The more statistics cubes you have activated in SAP NetWeaver
BW, the better usage information you will get
 Depending on your version of SAP NetWeaver BW, you can
activate 11-13 InfoCubes
 Also, make sure you capture statistics at the query level (set
it to “all”)
System issues can be hard to pin-down without access
to EarlyWatch Reports. Monitoring reports allows you
to tune the system before a user complains.
47
Information About a Pending “Disaster”
This system is
about to crash
The system is
growing by 400+ GB
per month, the app
server is 100%
utilized, and the DB
server is at 92%
This customer
needed to improve
the hardware to get
the query
performance to an
acceptable level
48
Bonus Problem #3: The Dashboard Performance Checklist
1.
2.
3.
4.
5.
6.
7.
8.
9.
The hardware servers — Check sizing
The server locations and networks — Check loads
Query review — Look at database and calculation time
and design
Interface review — Make sure you are using the best for the data source
Dashboard review — Look at Excel logic, container usage, number of
Flash 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)
49
What We’ll Cover …
•
•
•
•
•
•
•
•
Choosing the right connectivity and back end
Exploring query performance
Thinking about the dashboard design
Increasing query performance with infrastructure and in-memory
processing
Leveraging pre-caching capabilities and aggregates
Obtaining strategies for performance testing: Load and stress
Looking at EarlyWatch Reports and the performance checklist
Wrap-up
50
Where to Find More Information
•
•
•
Chris Dinkel, “Tuning SAP BusinessObjects Solutions for Optimal
Performance: Tips from the Trenches” (The SAP BusinessObjects
Seminar, 2011).
Steve Bickerton, “SAP BusinessObjects Tuning” (SAP AG, April
2011).
 www.scribd.com/doc/89894543/BOCX-Speaker-PerformanceTuning-Steve-Bickerton
SAP Service Marketplace for sizing guidelines
 https://websmp104.sap-ag.de/sizing and follow the Sizing
Guidelines menu path
 SBO_BI_4_0_Dashboard_designer.pdf
 Need to be a customer to access this
 Requires login credentials to the SAP Service Marketplace
51
7 Key Points to Take Home
•
•
•
•
•
•
•
Dashboards are all about performance, performance, and
performance
You have to spend time on the back end performance tuning
Avoid direct querying of high data volumes; create summaries
instead
Consider in-memory processing for all critical dashboards
Your interface to the data will impact the performance —
Avoid MDX
Size your hardware one size “too big” — It is hard to make a
second first impression
Use a gradual rollout of your dashboards, monitor the
performance, and conduct load and stress tests before any
major go-lives
52
Your Turn!
How to contact me:
Dr. Bjarne Berg
[email protected]
53
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.
54