How to: approach and improve the Screen Performances

Document created by mik1893 Employee on Jul 13, 2017Last modified by ggallo on Jul 14, 2017
Version 2Show Document
  • View in full screen mode

Screen Design and Performance: an example

A well configured BOARD Screen always optimizes

  • Functionality
  • User Interface
  • Performance

It might happen that focusing on only one of the above, will negatively effect the others. More specifically, indulging on attractive look and feel, may sometime compromise the screen execution performance, especially when opening and rendering it for the first time.

The purpose of this article is to provide some useful guidelines and hints on how to prevent such cases.


In the example below, the four images are part of the same Screen is supposed to display Financial KPIs grouped by Geo Clusters. 

Opening the Screen in its initial design and configuration takes about 30 seconds.



Analyzing more in depth its configuration the root causes for such performance are 

> Excessive use of redundant objects (Dataviews and labels);

> Poor design choice of the calculation logic applied


Troubleshoot and Resolution: Redundant Objects

The more objects (linked to a layout) are displayed on a screen, the higher will be the impact on performance: every single layout takes some time to render and be displayed, therefore many objects/layouts will slow down the opening and refreshing of the screen.


Action: Optimize the number of Layouts and objects used to fulfill the functional purpose

In the image below, we’re focusing only on the situation for Western Europe (one of the four sections in the Screen):



The section is displaying the following KPIs, Actual, Budget and Last Year values:


In order to display the above, the Screen was configured with:

  • 1 (one) Dataview with multiple blocks to show VOLUMES
  • 3 (three) labels (one per Actual, one per Budget, one per Last Year) to show NET SALES (each one containing multiple blocks)
  • 2 (two) Dataviews and 2 (two) labels to show MARKETING RESOURCES and LOCAL OPERATING MANAGEMENT

This approach was based on numerous complex layouts where "Layout Selections" or "Refer To" functionalities were used to identify a single Period/Scenario/KPI combination.


The same (functional) result can be obtained by using only two Dataviews, 

  • 1 (one) Dataview with multiple blocks to show VOLUMES and NET SALES

with the following result:



The Layout with different Layout Selection is then the basis for all Dataviews and Labels.

Every dataview is now combining the multiple objects previously existing by simply combining multiple Layout Selections.

What you see below is the DATAVIEW SELECTION tab of the first dataview (the one with volumes and net sales): as opposed to the initial situation, we have kept the layout as it was initially (to display Actuals, Budget and Last Year), but we have also added the account Line "Net Sales" to the Selection (therefore resulting in 2 (two) elements selected from the PL Account entity - Volumes and Net Sales) 



The same logic (combination of multiple objects and layouts into a single dataview + increase nr of elements selected), has been applied also to the second dataview (Marketing Resources, Local Operating Margin) to optimize performances. In order to keep the same look and feel of the original situation, white (empty) labels have been applied to hide those Dataview parts that are useless.

(see below)




the Refer To Layout option, is a very popular feature that allows to override the Screen or Layout selection for a specific Layout block. This feature is very resource consuming. It is suggested to replace it (when possible) with a Block Selection or to evaluate alternative design configurations


Troubleshoot and Resolution: Calculation logic applied

Rules are a very powerful feature which calculate "on the fly" values for members belonging to the same BOARD entity, on the X-Axis or Y-Axis of a report. Rule formulas, are calculated after the data have been aggregated to the required report level

The whole screen analysed in this example, contains 56 layouts and many of them are using rules to display calculated amounts.



Rules are in general a good approach to apply algorithms and derive new values, but in this specific case, their high amount and its negative impact on screen performance, should have driven a different design choice.

Action: Replace Rule calculations with Layout algorithms and create batch calculation that consolidate the Rule result in proper info-cubes, where the algorithms are not enough



After such changes, opening and refreshing the Screen takes about 5 seconds 


Additional Suggestions

Investigate the possibility of Versioning infocubes and track performances improvement: versioning requires additional memory but might bring large benefit during the layout execution.The layout engine always privileges the closest version to the layout structure. Investigate the different structure of the infocubes involved in the report layout: privilege those infocubes that share the same sparsity structure and apply changes if needed to synchronize and align sparsities

Parallel Execution

The parallel execution is a Screen option that is disabled by default. When the parallel execution is enabled, the screen "queries" linked to the different layouts are sent to the server and executed in parallel on multi-core or multi-processor servers. By default layout "queries" from different users are always executed in parallel by the BOARD server regardless of this setting which only affects multiple requests from the same user.

The activation of this option may bring evident benefits, but it should be cautiously evaluated in scenarios with high concurrency, to avoid bottlenecks

9 people found this helpful