Concurrent Users:
Concurrent Users: The term concurrent users, addresses the number of users simultaneously working with the BPC application at any given point in time.
Influence: The relationship is indirectly proportional to system performance; this is to say that the higher the number of concurrent users, the greater the resources required facilitating system requests. It is important to distinguish between users performing simple tasks, such as opening basic reports as opposed to users performing more resource intensive tasks- such as inputting data or instantiating data manager package runs. The latter will generate a heavier load on the system.
Recommendation: Refer to the BPC sizing guide. In summation, you can have approximately 100 concurrent BPC Users per Application Server instance; a higher number of concurrent users, at the very minimum would necessitate additional server dialogue instances. Factor the number of .NET servers too, and whether or not you will be sharing any of these resources with other installations and server components (like the database itself). These are several initial considerations to discuss when analysing user load and should be properly discussed and planned for accordingly with the appropriate sizing resource before attempting productive use.
Data Volume
Data Volume: The volume of data can have a significant impact on performance, both transaction and master data. Data being operated on must be adequately filtered and selected.
Influence: Large volumes of Master Data (Dimension Members) have an impact on performance for several aspects of BPC functionality, Logon, Member Processing, Report formatting etc...
Large volumes of Transactional Data have a direct impact on data retrieval times for reports and script logic. When building reports that need to read large data volumes make sure that you keep your BPC cubes optimized.
Recommendation: Only keep the necessary data in your cubes. Data no longer in use should be archived. If it is not possible to achieve this, you might want to consider making use of some of BW's partitioning functionality with NLS
Complexity of any script logic used for calculations
Script Logic: The amount of logic that you are using for running custom calculations, currency translations, default logic during write back, etc. can vary from project to project. Especially in planning scenarios customers tend to create large calculations for their specific business needs.
Influence: Script Logic can create a significant load on the BW application server if heavy calculations need to be performed. This load can also impact the Database if large amounts of data are being read and written. The execution of default logic is executed each time that a user inputs data. Depending on the complexity of the code this can significantly extend the write operation for any single user sending data into BPC.
Recommendation: Keep the default logic simple and properly scoped to only the records needed for the calculation. Remember to always use efficient coding to reduce the volume of reads, writes, and processing steps in your logic. This will help to reduce the resource load on the database and the application server. Act reservedly with the need for logic – high numbers of complex calculations can impact the CPU load on the application server. When possible, you should use simple tuple logic in the place of heavy when/rec/endwhen statements.
Complexity of any Consolidation Logic
Consolidation Logic: Consolidation logic configuration pivots on business rules, script logic and validations.
Influence: Consolidation Logic potentially impacts performance if the configuration is not optimal. When the script logic runs it can duplicate records based on the group structure and number of group currencies.
Recommendation: Case by case basis.
Complexity of any member access rules
Member access rules: The security model adopted will affect performance of the following BPC features: data retrieval and data writing, script logic execution, BPF usage, Client login time lapse, consolidation execution, etc.
Influence: The number of member access profiles and dimensions that are defined as secure will have a direct impact on the performance of the system (as mentioned above). To be kept to a minimum.
Recommendation: Security is critical in each project; our recommendation is only to keep it as simple as needed since it does have an impact on performance. Making frequent changes to your member access profiles will adversely affect the logon time lapse for each of the BPC Excel Client instances, as this will require a resynchronization of the local dimension member files each time that a change to the users’ access has been made.
Report Design
Report Design: When reading the data from SAP NetWeaver InfoCubes, SAP BPC uses two different SAP NetWeaver technologies:
- Online Analytical Processing (OLAP) BAPIs, which allow SAP BPC to access the data in SAP NetWeaver InfoCubes via the Multidimensional Expressions (MDX) language.
- Internal APIs, which enable SAP BPC to use private APIs (unsupported for third-party or customer use) to read data from SAP NetWeaver BI InfoCubes. Note: The Shared Query Engine (SQE), a module of SAP BPC, determines the optimal technology to use: internal APIs or OLAP BAPIs.
The Shared Query Engine or SQE is the central module for reading all of the data from an SAP BPC application. (Ex: SAP BPC Excel client, the Web, and the data manager). Technically, the SQE in SAP BPC 7.x NW consists of the following four sub-modules:
- RSDRI query, is the function group in SAP NetWeaver BI that deals with access to InfoProviders. In the SQE, an RSDRI query means calling the internal SAP NetWeaver BI functions to read data from an InfoProvider (Fastest).
- MDX query. SAP NetWeaver BI exposes OLAP BAPIs to access data from an InfoProvider through MDX. The MDX query method in SAP BPC generates the MDX statements required to retrieve data with the SAP BPC application logic applied. It is always used when there are dimension member formulas, measure formulas, or hierarchy parent values to be retrieved.
- Axis query. To request a contiguous region of data (e.g., an array of data to be displayed in a grid in SAP BPC Excel), the system uses the Axis query, which contains internal logic that determines (among other things) whether an RSDRI query or an MDX query will do the actual retrieval of data. Then, the Axis query calls the appropriate method. In some cases, the Axis query even breaks one request into multiple queries, each of which might call an RSDRI query or an MDX query, and then merges the results.
- Cell query. In direct contrast to an Axis query, this method specifically deals with requests for sparse data. A Cell query is required because SAP BPC supports users building highly formatted reports by retrieving several different individual cells from an SAP BPC application.
Influence: It is Important that the user accessing the BPC system with the client has a stable network connection. Good bandwidth and limited latency.
Recommendations: When planning the architecture of the BPC landscape and the Client rollout it is important to consider the location of the users (in case of a global user base) and the kind of access that they will have to the site hosting the BPC servers.
The access speed to the BPC local client cache directory is also very important. The Excel Client relates to the local cache. This is generally not an issue if the local cache is on the local hard drive of the workstation where the BPC Client is installed. However, we see a lot of customers where the ’My Documents’ directory hosting the BPC local client cache is stored on a network share. This network share is then accessed by the local PC installation as well as if a Terminal Server (Citrix) client rollout is used. Depending of the location of this network drive compared to the actual workstation/terminal server on which BPC is running, the access time lapse to this share could be quite slow. If the access to the network share is not optimal for the BPC Excel Client we recommend having the BPC local cache directory moved to a directory stored on the local hard drive of the particular machine hosting the BPC client.
Dimension Architecture
Dimension Architecture: The architecture used from a solution perspective with regard to the business requirement.
Influence: Dimensions have different functional purposes within a BPC solution. There are reserved, prerequisite properties. Master data is maintained via dimensions.
Recommendation: Hierarchies and properties are indirectly proportional to performance. This is to say that the greater number of both will result in a decrease in system performance. This is to be kept at a minimum considering the business requirement.