Performance and Sizing Guide - Analysis, edition for OLAP v0.2

Performance and Sizing Guide
SAP BusinessObjects Version BI 4.x
Analysis, edition for OLAP
Draft Version 0.2
September, 2011
Author: Mickey Wong

LOREM IPSUM DOLOR SIT AMET, CONSECTETAUR ADIPISICING
2
TABLE OF CONTENTS
INTRODUCTION .................................................................................................................................... 3
ARCHITECTURE OVERVIEW ................................................................................................................ 4
ACRONYM AND TERMS........................................................................................................................ 6
TEST CONFIGURATION ........................................................................................................................ 7
Test Driver ..................................................................................................................................................7
Workflow Definition ....................................................................................................................................7
Anne Workflow .............................................................................................................................................7
Conrad Workflow ..........................................................................................................................................8
Scenario Definition .....................................................................................................................................9
Query Size Definition..................................................................................................................................9
DEPLOYMENT CONFIGURATION ........................................................................................................10
OPTIMAL USER LOAD .........................................................................................................................11
OPTIMAL MEMORY USAGE.................................................................................................................13
Maximum Memory Allocation ................................................................................................................... 13
Web Application Server Memory .............................................................................................................. 13
APS Memory ............................................................................................................................................. 13
Memory Usage per Member and Cell ........................................................................................................ 13
PERFORMANCE AND SIZING FACTORS .............................................................................................14
Number of CPU Cores............................................................................................................................... 14
MDAS Session Limit ................................................................................................................................. 15
Query Size ................................................................................................................................................ 16
SCALABILITY.......................................................................................................................................19
Vertical Scalability .................................................................................................................................... 19
Horizontal Scalability................................................................................................................................ 19
Distributing APS Instances....................................................................................................................... 20
LOAD BALANCING ..............................................................................................................................21
DEPLOYMENT BOTTLENECKS............................................................................................................22
BW ............................................................................................................................................................ 22
APS........................................................................................................................................................... 23
TUNING RECOMMENDATIONS ............................................................................................................25
Performance Recommendations .............................................................................................................. 25
Sizing Recommendations ......................................................................................................................... 25
BOE Configuration.................................................................................................................................... 26
Servers ...................................................................................................................................................... 26
Services Run By APS ................................................................................................................................. 27
Auditing and Monitoring Settings .................................................................................................................. 27

PERFORMANCE AND SIZING GUIDE – ANALYSIS, EDITION FOR OLAP
3
INTRODUCTION
The purpose of this document is to provide guidance on how to configure your BusinessObjects deployment to
provide optimal performance and increase the effective user load for the Analysis, edition for OLAP product. This
document presents test results and architectural knowledge which form the basis of the recommended tuning
procedures for Analysis, edition for OLAP. The intended audience is anyone who is responsible for setting up
BusinessObjects for users of Analysis, edition for OLAP, which would include internal product development
group members, field services consultants, support engineers, and ramp-up customers. This guide will also
serve as an overview of how Analysis, edition for OLAP works, and therefore is a recommended resource for
new hires in the product development group.
There is a Sizing Guide for Analysis, edition for OLAP which is available from the SAP Marketplace. This
document should serve as an informal companion to and not be endorsed as a replacement for the official sizing
guide.

4
ARCHITECTURE OVERVIEW
The following diagram provides a high-level overview of the 3 different processing tiers that are applicable for
Analysis, edition for OLAP.
The Adaptive Processing Server is one of many servers managed by SAP BusinessObjects BI platform and is
built using the Platform Java Server Framework, which in turn is built on top of the Lean Java Server. Multiple
Adaptive Processing Servers may be active to provide fault tolerance and support horizontal scalability.
Multi-Dimensional Analysis Services (MDAS) provides the data access, visualization, and exporting functionality
for Analysis, edition for OLAP. The MDAS is hosted by the Adaptive Processing Server.
The following block diagram shows the major components and communication protocols involved when Analysis,
edition for OLAP is in use.
Client Tier Server Tier Data Tier
Web
Application
Server
OLAP
ServerAdaptive
Processing
Server

5

6
ACRONYM AND TERMS
The following is a list of definitions for acronyms and terms referred to throughout this document:
A-OLAP: Analysis, edition for OLAP
The official product name.
CMS: Central Management Server
MDAS: Multi-Dimensional Analysis Services
Required service for A-OLAP.
APS: Adaptive Processing Server
Server managed by BOE and used to run MDAS.
Web App Server: Web Application Server
BOE: BusinessObjects Enterprise
Commonly used alternative name of SAP BusinessObjects BI platform.

7
TEST CONFIGURATION
The following sections describe the test configuration used to generate the results presented in this guide.
SAP BW is the OLAP data source tested. The Tomcat web app server included in the BOE installation was
used.
Test Driver
HP LoadRunner 9.52 suite of applications was used to load test A-OLAP. Specifically A-OLAP workflows are
recorded using the Virtual User Generator, the A-OLAP workflows are run under load using LoadRunner
Controller, and LoadRunner Analysis is used to analyze load test results. More information about HP
LoadRunner can be found on HP’s website for software products.
The recording of A-OLAP workflows using LoadRunner Controller is in the format of a sequence C-type function
calls that encapsulate the http requests to the web app server. Therefore, rendering performance of the browser
is not included in the load test results.
Workflow Definition
The results provided in this guide are based on load tests where each user is either running an analyst workflow
or information consumer workflow. The persona name created for the analyst user and information consumer is
"Anne" and "Conrad" respectively.
The workflows defined for “Anne” and “Conrad” is generic enough such that they are compatible with different
initial crosstab layouts and BW hierarchies available. Being generic allows the workflows to work for different BW
queries which are necessary when testing for different query sizes.
The sum of the 90th percentile response time of all workflow steps is used to assess the performance. However,
the steps that do not invoke the APS, such as opening the InfoView homepage, logging on to InfoView,
navigating in InfoView, and logging out of InfoView, are not considered.
Anne Workflow
The following is the list of steps (as defined in the LoadRunner script) performed by an analyst against BW data
source:
1. Open_InfoView_Homepage
2. Logon
3. New_Pioneer_Workspace
4. Select_Connection_Submit
5. Click_Calculations_Button
6. Click_Place_After_Button
7. Select_Last_Member_Submit
8. Select_Mathematical_Division_Function
9. Select_Operand1_Add_Member
10. Select_Second_Last_Member_Submit
11. Select_Operand2_Add_Member
12. Select_Last_Member_Submit
13. Submit_Calculation
14. Swap_Crosstab_Axes
15. Undo_Swap_Crosstab_Axes
16. Sort_Descending_Order_Quantity
17. Move_Row_Hierarchy_To_Background
18. Filter_By_Member_Background_Hierarchy

8
19. Select_First_Member_Only_Submit
20. Select_Country_Dimension_To_Rows
21. Hide_All_Nulls_And_Zeros
22. Select_Sales_Person_Dimension_To_Last_Row
23. Drill_World_Enterprise
24. Undo_Drill_World_Enterprise
25. Insert_Clustered_Column_Chart
26. Swap_Chart_Axes
27. Unlink_Chart
28. Select_Crosstab
29. Remove_Background_Hierarchy
30. Move_Sales_Hierarchy_03_To_Background
31. Maximize_Crosstab
32. Sort_Ascending_Order_Quantity
33. Remove_Sort_On_Order_Quantity
34. Filter_By_Measure_Country_Hierarchy_02
35. Select_Based_On_Order_Quantity
36. Add_Greater_Than_1000
37. Submit_Measure_Rule
38. Click_Condition_Formatting_Button
40. Add_Less_Than_10k_Red
41. Add_Between_10k_100k_Yellow
42. Add_Greater_Than_100k_Green
43. Submit_Conditional_Formatting
44. Edit_Filter_By_Measure_Country_Hierarchy_02
45. Remove_Filter_Rule
47. Add_Greater_Than_100000
48. Submit_Measure_Rule
49. Delete_Conditional_Formatting
50. Export_To_Excel_And_Save_File
51. Click_Save_Button
52. Enter_Name_And_Submit
53. Confirm_Overwrite
54. Close_Pioneer_Workspace
55. Logout
Conrad Workflow
The following is the list of steps (as defined in the LoadRunner script) performed by an information consumer
against BW data source:
1. Open_InfoView_Homepage
2. Logon
3. Click_Documents_List
4. Open_Saved_Workspace
5. Open_Print_Option
6. Print_Analysis
7. Close_Workspace

9
Scenario Definition
For a user load test, 30% of all users execute the "Anne" workflow and 70% execute the "Conrad" workflow. This
distribution of user workflow types is deemed the most common scenario for most customers by A-OLAP product
owners.
Query Size Definition
For the purpose of this guide, query size refers to the maximum number of cells in a crosstab that is retrieved
when a user creates a new workspace with default members on the row or column or opens an existing
workspace.
The performance results for a specific query size is based on running the 30% Anne and 70% Conrad scenario.
Below is the list of the extra small, small, medium and large queries used in our testing, as well as the
corresponding row and column member cardinality:
Size Query Name Rows (data size) Column Total Cells
Large
Simple Hierarchy
Query 09
OrderID (186959) 2 measures 362k
Medium
Simple Hierarchy
Query 08
Customer (17865) 5 measures 90k
Small
Simple Hierarchy
Query 06
Customer (17865) 2 measures 36k
Extra Small
Simple Hierarchy
Query 07
Region (176) 7 measures 1k

10
DEPLOYMENT CONFIGURATION
BOE supports different deployment configurations for the web app server, CMS, APS, and OLAP server. The
results provided in this guide, unless stated otherwise, are based on the default "out-of-the-box" deployment
when BOE is initially installed. Specifically, the Tomcat web app server is installed on the same machine as the
BOE. There is only 1 CMS, APS, and InputFileRepository instance, all running on the same machine. For the
OLAP server, there is 1 machine hosting 1 SAP BW instance and MS SQL Server which BW is reporting off.
The following is a diagram of the “out-of-the-box” deployment.
The reason for using the "out-of-the-box" deployment is to examine the performance characteristics for a simple
deployment and be able to extend the results for more complicated deployments. Furthermore, by using the “out-
of-the-box” deployment, performance and sizing bottlenecks can be more easily detected when testing higher
user loads.
The performance and sizing impact of different deployment configurations for the web app and BW server are
mentioned in the Deployment Bottlenecks section presented later in this guide.
Machine A
Tomcat
BOE
• CMS
• APS
• Input File Repository
Machine B
SAP BW
MS SQL Server

11
OPTIMAL USER LOAD
The optimal user load is defined as the maximum A-OLAP user load that the BOE system can handle before
performance begins to noticeably degrade with increasing load.
Using our test results, optimal user load is usually determined by just visually inspecting the performance data
points for each user load. Formally, user load n is considered the optimal user load if the total 90th percentile
response time of all workflow steps of the next tested user load is more than 15% higher than at n user load.
The graph below shows the growth in response time with increasing user load. The results are based on the
"out-of-the-box" BOE deployment. The workflows use the extra small query size. The maximum amount of heap
memory was allocated for the web app and APS to ensure minimal JVM garbage collection overhead.
Visually it appears the optimal user load is 50 users.
The following table shows the results of calculating the percentage difference in the response time compared to
the previous tested user load.
User Load Total Response Time (sec)
Difference From Previous Load
(%)
10 9.573
20 9.706 1.38
30 9.808 1.05
40 10.055 2.52
50 11.564 15.0
0
5
10
15
20
25
10 20 30 40 50 60
Total 90th Percentile Response Time Per User
Load
90th Percentile Response Time

12
60 20.939 81.1
50 users is the optimal user load because at 60 users the total response time is more than 15% higher than at
50 users.
It is important to note that the determination of the optimal user load is based on the performance behaviour, not
the absolute performance. The workflow response times at the optimal user load for a system may not meet
criteria for what is expected or considered acceptable for the end user. To improve performance at the optimal
user load, please refer to the Tuning Recommendations section.
The following table summarizes the results of determining the optimal user load for different query sizes for the
“out-of-the-box” BOE deployment.
Query Size Optimal User Load
Extra Small 50
Small 20
Medium 10
Large < 10
Note: The optimal user load for large sized queries is considered less than 10. The performance at 10 users is
poor where some workflow steps take more than 30 seconds to complete, and the total workflow response time
is 324 seconds. However, we cannot accurately test user loads less than 10 while keeping the exact ratio of 30%
Anne users and 70% Conrad users.

13
OPTIMAL MEMORY USAGE
The optimal memory usage is the minimum required memory allocated for the web app server or APS instance
that would allow the best workflow performance at the optimal user load.
Maximum Memory Allocation
The maximum possible memory is allocated to the web app server and APS instance in determination of the
optimal user load. The BOE "out-of-the-box" deployment is used where both the one Tomcat web app server
and one APS instance are running on the same machine. The maximum possible memory allocated for the web
app server is arbitrarily chosen to be 1/4 of the total physical memory available on the machine, while the
maximum for the APS instance is 1/2 of the total memory.
The procedure used to determine the optimal memory usage is simply to iteratively reduce the maximum
memory allocated as long as the performance is no worse than 10% when the maximum possible memory was
allocated. In our test runs, the optimal memory usage load of the web app server was determined first then the
APS instance.
The following sections provide test results for the optimal memory usage determined for the web app server and
APS instance when running at the optimal load of n users for different query sizes. The results can be
extrapolated to determine the optimal memory usage at different loads. For example, if the optimal memory
usage is 4 GB at optimal load of 50 users, at 25 users the optimal memory usage should be no more than 2 GB
assuming the same query size is consumed. Vice versa, if the optimal user load is increased to 100 users then
the optimal memory usage should be at least 8 GB.
Web Application Server Memory
The default Tomcat server from the "out-of-the-box" deployment was tested. The server process is a java
process, hence changing the maximum Java heap size setting (-Xmx) was tested at the optimal load of n users.
Query Size Optimal Memory Usage (GB)
Extra Small 4
Small TODO
Medium TODO
Large TODO
APS Memory
APS is a java server. The maximum Java heap size setting (-Xmx) was determined at the optimal load of n
users.
Query Size Optimal Memory Usage (GB)
Extra Small 2
Small TODO
Medium TODO
Large TODO
Memory Usage per Member and Cell
To help predict memory usage of the PJS for different query sizes, measurement of the memory usage for each
row/column member and crosstab cell is provided here.
<TODO: show memory per member and cell>

14
PERFORMANCE AND SIZING FACTORS
The following sections discuss various factors that influence the performance and sizing capabilities of A-OLAP.
The focus is primary on BOE and its components and is based on the setup described in Test Configuration
section. There may be other factors related to the web app server and BW server which are not covered in detail
in this guide.
Number of CPU Cores
As mentioned in the Architecture Overview section, MDAS is run as a service of the APS. The APS has a shared
service thread pool where its maximum size is determined by the number of logical processors that are available
to the running Java Virtual Machine. Therefore, the number of CORBA requests that can be handled
concurrently by the APS is largely dependent on the number of CPU cores. Outstanding CORBA requests will be
queued up for the next available thread.
The maximum size of the thread pool is calculated based on the following heuristic:
max_pool_size = floor( core_pool_size * ((1 - 0.9^nCpus) / (1 - 0.9)) )
Where the core_pool_size is 10 and nCpus = Runtime.getRuntime().availableProcessors().
The following is a graph showing the number of threads with increasing number of cores.
The following is a table showing the mapping of the number of processors and the calculated thread pool size.
Number of CPU Cores Thread Pool Size
2 19
4 34
6 46
8 56
10 65
12 71
14 77
16 81
0
10
20
30
40
50
60
70
80
90
100
2 4 6 8 10 12 14 16 18 20 22 24
Number of Threads vs Number of CPU Cores
Number of Threads

15
18 84
20 87
22 90
24 92
The graph shows that with increasing number of cores, there is a diminishing increase in the maximum pool size.
Based on the heuristic, the maximum possible thread pool size is 99.
Since there is a maximum thread pool size limit, sizing of the MDAS is not CPU bound. In other words,
continuously adding more CPU cores to a machine will not proportionally increase the number of requests that
can be handled by the APS.
The following are test results when varying the number of CPU cores made available to the APS. For each
number of CPU cores tested, the optimal user load is determined. The workflow tested is against BW extra small
sized queries. The maximum amount of memory is allocated to the web app server and MDAS heap to ensure
that they are not a resource bottleneck.
Number of CPU Cores Optimal User Load
2 20
4 40
8 40
16 50
24 50
Increasing from 2 cores to 4 cores allowed the optimal user load to increase by 20. However, increasing from 4
cores to 24 cores only allowed the optimal user load to increase by 10. The result from having 4 cores is
expected as there are 34 threads handling CORBA requests. At 16 and more cores there should be enough
threads to handle 50 concurrent requests from 50 different users. The reason the optimal user load does not
change from 16 to 24 cores is attributed to the BW server. In the Deployment Bottlenecks section there is
mention of how the BW server impacts sizing.
Assuming there are no external bottlenecks, increasing the number of CPU cores will help increase the optimal
user load which MDAS can handle. However, since there is diminishing increase of the APS thread pool with
more CPU cores, a more effective way to increase the user load is to add more cores to the BOE system via
another physical machine and having a distributed deployment of MDAS. For example, increasing from 8 to 16
cores will increase the thread pool size from 56 to 81, compared to 2 x 8 core machines with 1 APS running on
each and there are 2 x 56 = 112 total APS threads. Please refer to the Horizontal Scalability section for details
on how to deploy an MDAS instance on a separate machine from the CMS.
MDAS Session Limit
One MDAS instance can handle a maximum of 100 active A-OLAP sessions. When there are already 100
sessions, a new user cannot create or open an A-OLAP workspace. Currently, the following error message
indicating that the MDAS is unavailable is presented to the user attempting to create a new A-OLAP session
when the maximum number of sessions has been reached.

16
To support more than 100 active users of A-OLAP, a new APS instance running MDAS needs to be created.
Although an administrator can create a new APS instance on the same machine as the existing APS, it is
recommended to create the new APS instance on a separate machine to avoid excessive CPU usage on the
existing BOE machine.
Query Size
Based on the data presented in the Optimal User Load section, below are 2 charts showing the relationship
between optimal user load and different query sizes. Note that the optimal user load for large size queries could
not be accurately determined and as such is excluded from the charts below.

17
The above test results are based on varying the query size when running on a machine with a fixed number of
CPU cores available. For each query size, the optimal user load is determined. The maximum amount of
memory is allocated to the web app server and MDAS heap to ensure that they are not a resource bottleneck.
The results above show that varying query sizes does have direct impact on the optimal user load. Optimal user
load appears to drop significantly from extra small to small queries, and less so from small to larger queries.
The following 2 graph compares the performance of different query sizes at the optimal user load of 10.
50
20
10
0
10
20
30
40
50
60
xs s m
Optimal User Load Per Query Size
Optimal User Load
50
20
10
0
10
20
30
40
50
60
1097
5115
9133
13150
17168
21186
25204
29221
33239
37257
41275
45292
49310
53328
57346
61363
65381
69399
73416
77433
81451
85469
Optimal User Load vs Query Size
Optimal User Load

18
The response time appears to grow significantly from extra small to small queries, and less so from small to
larger queries. Hence, increasing query size does degrade overall performance.
9.573
52.327
63.253
0
10
20
30
40
50
60
70
xs s m
90th Percentile Response Time Per Query Size @ 10
users
9.573
52.327
63.253
0
10
20
30
40
50
60
70
1097
5845
10594
15342
20090
24838
29587
34335
39083
43831
48580
53328
58076
62824
67573
72321
77068
81816
86565
90th Percentile Response Time vs Query Size @ 10
users

19
SCALABILITY
Vertical Scalability
Vertical scalability is determined by analyzing the performance difference between running at the optimal user
load and running at double the optimal user load when machine resources are doubled. The BOE system can
vertically scale if the performance at optimal user load n is the same at optimal user load 2n when the BOE
machine resources are doubled. Specifically, the machine resources that are doubled include number of CPU
cores on the BOE and OLAP server machine, and amount of heap memory allocated for the web app server and
the APS. Performance is considered the same if the total workflow time at double the optimal user load is no
worse than 15% higher than the total time at the optimal user load.
To simulate the results of varying number of cores, CPU affinities were assigned to the BOE and OLAP server
processes. The BOE processes that had CPU affinities assigned include the CMS, InputFileRepository, and
APS. Since the test results are based on the "out-of-the-box" deployment where Tomcat is running on the same
BOE machine, the Tomcat process was also assigned CPU affinities.
The following charts compare the performance of running at the optimal user load versus double optimal user
load when resources are doubled. At the optimal user load, the optimal amount of heap memory is allocated for
the web app server and APS. Please refer to Optimal Memory Usage section for information on how the optimal
heap memory is determined. Also, the results are based on workflows using the extra small query size for BW.
<TODO insert charts comparing 4 cores vs 8 cores >
The above results show that we can scale a BOE system vertically from 4 cores on BOE and OLAP server
machine using x Tomcat heap and x APS heap, to 8 cores using x Tomcat heap and x APS heap.
Horizontal Scalability
Similar to vertical scalability, the performance difference between running at the optimal user load and at double
the optimal user load is analyzed. However, at double the optimal user load, resources are doubled by doubling
the actual number of physical machines. The BOE system can horizontally scale if the total workflow time at
double the optimal user load is no worse than 10% higher than the total time at the optimal user load.
Doubling the number of machines includes the machine running the BOE system as well as the machine running
the OLAP server. If the web app server is running on a separate machine from the BOE system, then that
machine is also duplicated.
To make use of the additional machines when scaling horizontally, new instances of the web app server, APS,
and OLAP server must be running on those machines. The main CMS of the BOE system would reside on one
machine and would communicate with the APS instances installed both locally and remotely. Please refer to the
Distributing APS Instances section for more information.
The diagram below shows the resulting deployment of doubling all physical machines of the "out-of-the-box"
deployment.

20
The following chart compares the performance of running at the optimal user load versus double optimal user
load when there is double the number of physical machines. In both scenarios, the optimal amount of heap
memory is allocated for the web app server and APS. Also, the results are based on workflows using the extra
small query size for BW.
<TODO insert chart>
The above results show that we can scale a BOE system serving A-OLAP users horizontally from a deployment
of 1 Tomcat/BOE machine and 1 BW machine to 2 Tomcat/BOE machines and 2 BW machines.
Distributing APS Instances
<TODO Instructions on how to do it on Windows and UNIX>
Machine A
Tomcat
BOE
•CMS
•APS
•InputFile
Repository
Machine B
Tomcat
BOE
•APS
Machine C
SAP BW
MS SQL Server
Machine D
SAP BW
MS SQL Server

21
LOAD BALANCING
Load balancing takes place when multiple APS instances exist for one BOE system. The distribution of user
sessions to multiple APS instances is random. The determination of whether a user session is managed by an
APS instance is based on the current number of active sessions and the maximum session count of the APS
instance. If the number of active sessions of an APS is already at the maximum, then the user session will be
assigned to the next random APS instance that has not reached its maximum session count.
To ensure load is equally distributed between all APS instances, it is recommended that the maximum session
count for each APS instance be the same and that the minimum required value is set to satisfy the requirement
for maximum number of concurrent sessions. Otherwise there may be a risk that one APS instance is managing
more user sessions than all other instances, therefore overloading the CPU and heap memory requirements of
one APS and possibly causing a performance overhead. As an example, if we expect at most 100 concurrent A-
OLAP users and there are 2 APS instances, then the maximum session count should be set to 50 on each APS.

22
DEPLOYMENT BOTTLENECKS
BW
The test results in this guide show that for an "out-of-the-box" deployment where BOE and Tomcat are running
on a 24-core machine and BW server is running on a separate 16-core machine that the optimal A-OLAP user
load is 50 for queries of about 1000 cells.
The bottleneck that is preventing a higher optimal user load is actually the BW server. When BW is running on
the same machine as the SQL server it is reporting off, the SQL server process performs a significant amount of
disk writing. The SQL server process continuously writes to the database transaction log under higher user
loads. This behaviour exists despite having changed the SQL database recovery mode from ‘Full’ to ‘Simple’.
The chart below shows the average system disk writes per minute of the BW machine for a 60 user load test
where the query size is 1000 cells. The average is about 40MB per minute.
There is no strict requirement that BW and SQL servers must reside on the same physical machine. When BW
and SQL servers are running on separate machines, the SQL server process no longer performs excessive disk
writes. The exact reasoning why there is a difference in behaviour of the SQL server process is still under
investigation.
When the performance bottleneck of excessive disk writes is removed by having BW server and SQL server on
separate machines, the BOE system can handle 100 users with no significant performance degradation
compared to at the optimal user load of 50 users for extra small size queries. Note that since the maximum
number of concurrent sessions supported by MDAS is 100, it cannot be validated whether the true optimal user
load is actually higher.
The following diagram shows the deployment configuration after separating BW and SQL servers.

23
The approach taken to reduce the bottlenecks of the BW was to add another machine to the deployment such
that there is a dedicated machine for BW and a dedicated machine for SQL server. However, it is recommended
to first attempt to tune the BW and web app server to support higher user loads. The topic of tuning BW and web
app server is beyond the scope of this guide. Please consult the performance and sizing guidelines for BW and
the specific web app server deployed for more information.
APS
As a result of MDAS supporting a maximum of 100 concurrent sessions, support for more sessions require the
addition of more APS instances running MDAS. There are 2 options of adding more MDAS. One is to add a new
APS instance to the existing BOE system on the same machine as initial APS instance. The other option is to
add a new APS instance on a separate machine while being managed by the BOE system residing on another
machine - in other words a distributed cluster of APS instances.
The following diagram depicts a sample deployment of 2 APS instances running on a BOE system.
The following diagram depicts a sample deployment of 2 APS instances running on separate machines.
Machine A
Tomcat
BOE
• CMS
• APS
Machine B
SAP BW
Machine C
MS SQL Server
BOE Machine
Tomcat
BOE
•CMS
•APS 1
•APS 2
•Input FileRepository

24
The following chart compares the performance of the 2 deployments described above at a user load of 200. The
result is based on having 2 APS instances and having BW and SQL server on separate machines to ensure the
SQL server process is not a bottleneck. The result is for the extra small query size.
<TODO Insert chart comparing 2 deployments at 200 users>
<TODO Comment on the results>
BOE Machine A
Tomcat
BOE
• CMS
• APS 1
BOE Machine B
BOE
• APS 2

25
TUNING RECOMMENDATIONS
Performance Recommendations
The following table shows for each optimal user load and query size what the optimal memory usage is for the
web app server and APS. The results are based on using the “out-of-the-box” deployment.
Query Size # Cells Optimal User Load
Optimal Web App
Heap (GB)
Optimal APS Heap
(GB)
xs 1232 50 4 2
s 35730 20 TODO TODO
m 89325 10 TODO TODO
For query sizes and user loads not listed above, the optimal memory usage for those cases can be extrapolated
from the existing data.
The information above should be used to determine the minimal Java heap memory that should be allocated for
the web app server and APS. Smaller heap memory may be allocated with the result of poorer workflow
performance. The impact to performance may be attributed to the additional overhead of more frequent garbage
collection by the JVM. Therefore, the recommendation would be to at least allocate the optimal amount of heap
and more as long as there is enough system memory for the other running processes on the machine.
Sizing Recommendations
 To help increase the optimal user load, more CPU cores may be added to the machine where BOE is
running. However, the data provided in the Number of CPU Cores section show that the effects of
increasing the optimal user load diminishes with increasing number of cores. The recommendation when
using the “out-of-the-box” deployment is that it is only beneficial to increase the number of CPU cores if
the existing number is 8 or less.
 The web app and OLAP server may be the source of bottlenecks preventing higher optimal number of
concurrent A-OLAP sessions. It is advised to refer to the performance and sizing guidelines of the web
app and OLAP server in your BOE deployment to ensure the optimal configuration is used. The following
are some configuration procedures that were discovered specifically for Tomcat and BW which helped
improve sizing:
o The default number of Tomcat connector worker threads is 200. For user loads higher than 200,
the thread pool size should be increased to at least match the user load. Please refer to
http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
o As noted in the Deployment Bottlenecks section, having BW and SQL servers deployed on
separate machines prevents excessive disk writes by the SQL server process.
o The number of BW/ABAP worker processes is configurable via the rdisp/wp_no_dia parameter.
It is recommended to set the value to the number of available processors on the BW machine.
o The number of terminal connections to BW is configurable via the rdisp/tm_max_no parameter.
The value should be set to at least match the user load. Please refer to
https://service.sap.com/sap/support/notes/384971
o If multiple BW server instances are deployed, the default load balancing algorithm may not work
effectively under heavy user load. It is advised to use the round robin algorithm to ensure load is
equally distributed between the BW instances. Please refer to
http://help.sap.com/saphelp_nw70/helpdata/en/28/1c623c44696069e10000000a11405a/content
.htm

26
Otherwise, since the BOE system for A-OLAP can scale horizontally, all the machines may be
duplicated to support double the user load.
 There must be a minimum of 1 APS instance running MDAS for every 100 concurrent number of A-OLAP
sessions. Multiple APS instances may be running on the same machine. However, it is preferred to
distribute the APS instances across multiple machines to avoid sharing CPU and memory resources
between APS instances and minimizing performance.
 When multiple APS instances exist in a BOE deployment, set the maximum session count to be the same
for each APS instance and the minimum amount required to satisfy the total number of concurrent
sessions to be supported. For example, if the expectation is to support 100 concurrent sessions and
there are 2 APS instances, set the maximum session count for each APS to 50 (100 / 2). Following this
recommendation will ensure load balancing between APS instances will work most effectively.
The following is a screenshot of the MDAS section of the properties page of an APS where the
maximum session count can be set. This page is accessible from the Servers page of the CMC.
BOE Configuration
The following section describes some BOE configuration options that may help improve the overall performance
of A-OLAP. Note that the following options may not be performed depending on the BOE features that are
required for the customer.
Servers
If your BOE system is strictly used for A-OLAP, then many of the servers’ processes that were enabled by
default may be disabled and/or removed from the CMC. The only required servers to support A-OLAP are the
Adaptive Processing Server running MDAS, the Central Management Server, and the Input File Repository. In
Aurora 4.0, the Dashboard Server and Dashboard Analytics Server are also required such that the Home tab in
InfoView is displayed properly.

27
By removing the unnecessary server processes, more memory is made available to O/S which would allow more
heap memory to be assigned to the web app server and PJS.
Services Run By APS
To use A-OLAP, only the MDAS service has to be running on at least 1 APS instance. All other services that
APS can run are not required for A-OLAP. It is recommended to review the list of services running on the APS
instances and remove any services that are not required.
To remove services running on the APS, the APS must first be stopped. Right-click the APS and choose Select
Services and the following page will appear.
Auditing and Monitoring Settings
If auditing of events is not needed, then it is recommended to turn if off from CMC. Doing so will eliminate the
overhead of logging events to the auditing database.

28
To disable auditing from CMC, go to the Auditing page under the 'Manage' section. Adjust the event level slider
under 'Set Events' section to 'Off'.
If monitoring of java processes is not required, then monitoring should be turned off to remove the overhead of
polling the JVM for resource metrics.
To disable monitoring from CMC, go to the 'Applications' page under the 'Manage' section. Right-click
'Monitoring Application' and select 'Properties'. Uncheck the option 'Enable Monitoring Application'.

29

©2011 SAP AG. All rights reserved.
SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign,
SAP BusinessObjects Explorer, StreamWork, 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
other countries.
Business Objects and the Business Objects logo, BusinessObjects,
Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and
other Business Objects products and services mentioned herein as
well as their respective logos are trademarks or registered trademarks
of Business Objects Software Ltd. Business Objects is an SAP
company.
Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL
Anywhere, and other Sybase products and services mentioned herein
as well as their respective logos are trademarks or registered
trademarks of Sybase, Inc. Sybase is an SAP company.
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.
www.sap.com

Performance and Sizing Guide - Analysis, edition for OLAP v0.2

More Related Content

What's hot

Similar to Performance and Sizing Guide - Analysis, edition for OLAP v0.2

Performance and Sizing Guide - Analysis, edition for OLAP v0.2