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

Performance and Sizing Guide

SAP BusinessObjects Version BI 4.xAnalysis, edition for OLAPDraft Version 0.2September, 2011

Author: Mickey Wong

LOREM IPSUM DOLOR SIT AMET, CONSECTETAUR ADIPISICING

TABLE OF CONTENTS

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

2

PERFORMANCE AND SIZING GUIDE – ANALYSIS, EDITION FOR OLAP

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

3


ARCHITECTURE OVERVIEWThe 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.

4

Client Tier Server Tier Data Tier

Web Application

ServerOLAPServerAdaptive

Processing Server


5


ACRONYM AND TERMSThe following is a list of definitions for acronyms and terms referred to throughout this document:

A-OLAP: Analysis, edition for OLAPThe official product name.

CMS: Central Management Server

MDAS: Multi-Dimensional Analysis ServicesRequired service for A-OLAP.

APS: Adaptive Processing ServerServer managed by BOE and used to run MDAS.

Web App Server: Web Application Server

BOE: BusinessObjects EnterpriseCommonly used alternative name of SAP BusinessObjects BI platform.

6


TEST CONFIGURATIONThe 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 DriverHP 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 DefinitionThe 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 WorkflowThe following is the list of steps (as defined in the LoadRunner script) performed by an analyst against BW data source:

1. Open_InfoView_Homepage2. Logon3. New_Pioneer_Workspace4. Select_Connection_Submit5. Click_Calculations_Button6. Click_Place_After_Button7. Select_Last_Member_Submit8. Select_Mathematical_Division_Function9. Select_Operand1_Add_Member10. Select_Second_Last_Member_Submit11. Select_Operand2_Add_Member12. Select_Last_Member_Submit13. Submit_Calculation14. Swap_Crosstab_Axes15. Undo_Swap_Crosstab_Axes16. Sort_Descending_Order_Quantity17. Move_Row_Hierarchy_To_Background18. Filter_By_Member_Background_Hierarchy

7


19. Select_First_Member_Only_Submit20. Select_Country_Dimension_To_Rows21. Hide_All_Nulls_And_Zeros22. Select_Sales_Person_Dimension_To_Last_Row23. Drill_World_Enterprise24. Undo_Drill_World_Enterprise25. Insert_Clustered_Column_Chart26. Swap_Chart_Axes27. Unlink_Chart28. Select_Crosstab29. Remove_Background_Hierarchy30. Move_Sales_Hierarchy_03_To_Background31. Maximize_Crosstab32. Sort_Ascending_Order_Quantity33. Remove_Sort_On_Order_Quantity34. Filter_By_Measure_Country_Hierarchy_0235. Select_Based_On_Order_Quantity36. Add_Greater_Than_100037. Submit_Measure_Rule38. Click_Condition_Formatting_Button39. Select_Based_On_Order_Quantity40. Add_Less_Than_10k_Red41. Add_Between_10k_100k_Yellow42. Add_Greater_Than_100k_Green43. Submit_Conditional_Formatting44. Edit_Filter_By_Measure_Country_Hierarchy_0245. Remove_Filter_Rule46. Select_Based_On_Order_Quantity47. Add_Greater_Than_10000048. Submit_Measure_Rule49. Delete_Conditional_Formatting50. Export_To_Excel_And_Save_File51. Click_Save_Button52. Enter_Name_And_Submit53. Confirm_Overwrite54. Close_Pioneer_Workspace55. Logout

Conrad WorkflowThe following is the list of steps (as defined in the LoadRunner script) performed by an information consumer against BW data source:

1. Open_InfoView_Homepage2. Logon3. Click_Documents_List4. Open_Saved_Workspace5. Open_Print_Option6. Print_Analysis7. Close_Workspace

8


Scenario DefinitionFor 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 DefinitionFor 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

9


DEPLOYMENT CONFIGURATIONBOE 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.

10

Machine A

Tomcat

BOECMSAPSInput File Repository

Machine B

SAP BW

MS SQL Server


OPTIMAL USER LOADThe 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 90 th 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.

10 20 30 40 50 600

5

10

15

20

25

Total 90th Percentile Response Time Per User Load

90th Percentile Response Time

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.57320 9.706 1.3830 9.808 1.0540 10.055 2.5250 11.564 15.0

11


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 LoadExtra Small 50

Small 20Medium 10Large < 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.

12


OPTIMAL MEMORY USAGEThe 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 AllocationThe 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 MemoryThe 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 TODOMedium TODOLarge TODO

APS MemoryAPS 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 TODOMedium TODOLarge TODO

Memory Usage per Member and CellTo 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>

13


PERFORMANCE AND SIZING FACTORSThe 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 CoresAs 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.

2 4 6 8 10 12 14 16 18 20 22 240

102030405060708090

100

Number of Threads vs Number of CPU Cores

Number of Threads

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 194 346 468 5610 6512 7114 7716 81

14


18 8420 8722 9024 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 Load2 204 408 4016 5024 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 LimitOne 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.

15


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

16


xs s m0

10

20

30

40

50

60

50

20

10

Optimal User Load Per Query Size

Optimal User Load

1232 35730 893250

10

20

30

40

50

60

50

20

10

Optimal User Load vs Query Size

Optimal User Load

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.

17


xs s m0

10

20

30

40

50

60

70

9.573

52.327

63.253

90th Percentile Response Time Per Query Size @ 10 users


1232 35730 893250

10

20

30

40

50

60

70

9.573

52.327

63.253

90th Percentile Response Time vs Query Size @ 10 users


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.

18


SCALABILITY

Vertical ScalabilityVertical 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 ScalabilitySimilar 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.

19


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>

20

Machine A

Tomcat


Machine B

Tomcat

BOEAPS

Machine C

SAP BW

MS SQL Server

Machine D

SAP BW

MS SQL Server


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.

21


DEPLOYMENT BOTTLENECKS

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

22


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.

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

23

Machine A

Tomcat


Machine BSAP BW

Machine CMS SQL Server

BOE MachineTomcat

BOECMSAPS 1APS 2Input File Repository


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>

24

BOE Machine ATomcat

BOECMSAPS 1Input File Repository

BOE Machine BBOEAPS 2


TUNING RECOMMENDATIONS

Performance RecommendationsThe 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 2s 35730 20 TODO TODOm 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

25

http://help.sap.com/saphelp_nw70/helpdata/en/28/1c623c44696069e10000000a11405a/content.htm

http://help.sap.com/saphelp_nw70/helpdata/en/28/1c623c44696069e10000000a11405a/content.htm

https://service.sap.com/sap/support/notes/384971

http://tomcat.apache.org/tomcat-6.0-doc/config/http.html


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

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

26


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 APSTo 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 SettingsIf 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.

27


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

28


29

www.sap.com

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

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

Documents

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