Dear SCN Member,
In order to fully benefit from what SCN has to offer, please register at:
Thank you,
The SCN team
We are improving! The SCN wiki will not be available for new content submission starting August 7th 6PM CET until August 10th 6PM CET.
Please plan your SCN wiki tasks accordingly.
Skip to end of metadata
Go to start of metadata

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.

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.


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.

  • No labels