After a blog on Performance Improvements for Design Studio 1.5 here is one more blog with Design Studio Performance best practices in general. Although these topics may have been presented in earlier blogs, here you’ll find them revised and updated to the current Design Studio release.
By default, all data sources are loaded in Design Studio at application startup. For Design Studio applications with few data sources the application starts in sufficiently short time in the browser. However, the more data sources a Design Studio application has, the longer it may take until the application appears in the browser, as the application has to wait until all data sources have been loaded. This waiting time may be perceived by users negatively. One possible remedy is to reduce the number of data sources that are loaded at application startup.
Experience shows that no more than 4 data sources (information islands) are needed right from the beginning because humans typically cannot process a higher load of information. Using 10 or more data sources right from the start of the application clearly exceeds this limit by a wide margin.
To disable the loading of a data source at application startup, set the data source property “Load in Script” to “true”.
Later, when the data of the data source is actually needed (for example, when the user clicks a button), load the data of the data source in a Design Studio script with the Design Studio script method loadDataSource, for example:
DS_1.loadDataSource();
Incidentally, calling loadDataSource several times on a data source has no performance penalty, as all calls of loadDataSource following the first call are ignored.
Larger Design Studio applications may have components that are not visible right at application startup -- think of TabStrips with several tabs, Pagebooks with several pages, or any component that is initially invisible and shown, for example, upon a button click. You can improve the startup performance of your application by only loading the data sources of the visible components and not loading the data sources of the invisible components yet.
For example, you have a Pagebook of several pages with each page displaying the data of a different data source. One way to implement this efficiently is to load a data source only when the specific page of the Pagebook is selected. Add the following Design Studio script to the “On Select” event of the Pagebook:
if ((PAGEBOOK_1.getSelectedPageIndex() == 0)) {
DS_1.loadDataSource();
// ...
} else if ((PAGEBOOK_1.getSelectedPageIndex() == 1)) {
DS_2.loadDataSource();
// ...
} else if ((PAGEBOOK_1.getSelectedPageIndex() == 2)) {
DS_3.loadDataSource();
// ...
}
Recall from the previous section that you need to set the property “Load in Script” to “true” for all the involved data sources.
Note that calling loadDataSource several times on an already loaded data source is ignored and has no performance impact.
Incidentally, an even better version would exploit the fact that the page of the Pagebook which is visible at application startup (in this example this is the page with index 0 - but this is can be changed): Load the first data source DS_1 already at application startup (with its property "Load in Script" set to false) and use the following Design Studio script in the “On Select” event of the Pagebook:
The sections above implicitly suggest to avoid loading data sources at application startup when their components are not visible. If such an application design with few initially visible components is not possible, the following shows you how to improve the perceived performance of loading these data sources.
The idea is that the most important data sources are loaded first, while the less important data sources are loaded afterwards. While users focus their attention on components with data sources that are loaded initially, the Design Studio application loads the remaining data sources, which is not perceived as waiting time by the user. Loading the remaining data sources separately is done using a concept called “background processing”. Background processing consists of executing a Design Studio script in the “On Background Processing” event handler, which is executed asynchronously.
The basic steps are as follows:
For example, you have a Design Studio application with four data sources, the first two of them should be shown immediately. Then proceed as follows:
If loading both DS_3 and DS_4 during the initial background processing take too long, you can split up their loading as described in step 4. While most of the steps above remain the same, the only step that you need to change is the last one:
It is easy to see that you can extend this example with more iterations.
Incidentally, you can apply this concept not only in the “On Startup” event handler, but also in any other event handler, for example to trigger loading data sources when changing tabs in a Tabstrip component.
Note that background processing comes at a cost (for more details, see section "Background Processing Is Not For Free" in on Performance Improvements for Design Studio 1.5), so it’s best to use background processing only when needed.
When you have several charts, try to use a single data source with those charts and select the relevant data for the specific chart with the Chart property “Data Selection”:
This may involve redesigning the single data source as a superset of all the previously used data sources.
For example, you have one chart displaying data of a specific country, say Italy, and one chart displaying data of another specific country, say Spain. Then, instead of choosing two data sources – one for Italy and one for Spain – use a single data source containing country-specific data, including country-specific data for Italy and Spain. For the first chart use the Chart property “Data Selection” to select the data specific to Italy, for the second chart use the Chart property “Data Selection” to select the data specific to Spain.
Reducing the number of data sources in this way improves the performance significantly.
Before Design Studio 1.5 the assignment of data sources was static and could not be changed at runtime. To “simulate” changing the data source of – for example – a crosstab, the application designer had to insert two (or even more – depending on the number of exchanged data sources) components at the same place, with the same settings. Later for one of these components the property “visible” was set to “true”, for the others “visible” would be “false”. If another data source should be shown these “visible” flags were changed accordingly.
This approach has the disadvantage of wasting resources because the number of components was higher than actually needed.
With Design Studio 1.5 this “simulation” by using the “visible” property is no longer necessary. With the “setDataSource” function the data source can changed as needed for every analytic component:
Exchanging the data source can be done with a call to “setDataSource”:
CROSSTAB_TOP_N.setDataSource(DS_2);
Performance is a critical topic for all areas of an application. However the most critical area of an application is the startup time. The perceived startup time is the time between launching the application up to the appearance of the first useful information in the application.
The design of the “start screen” can influence startup performance more than any other technical topic. Ideally the start screen consists of components referring to one single data source showing the most important data for the user. With that information the user should be enabled to choose which information he wants to see next.
It is important to emphasize that having only one data source at startup does not mean the screen consists only of one component. One data source can be used to feed for example both a crosstab and a chart. With the “data selection” feature one data source can also be used to feed multiple charts (see chapter “Use a Single Data Source for Multiple Charts”). In addition this data source can be used to feed entries of list-boxes or dropdown boxes to allow the users choosing other views of the data or switching to other screens showing more detailed data.
The following screenshot shows a screen that is populated with information from a single data source:
The property “Page Caching” of the Pagebook component controls which pages are rendered directly to the browser.
The default value of “None” renders only the currently visible page to the browser. Other pages are rendered when they become visible. The value of ‘”None” is the most efficient one in terms of performance.
The setting “Adjacent” is a good solution when the “Transition Effect” property is different from “None” and paging is done only to go to the “next” or “previous” page. During the transition effect both of the pages are at least partially visible. To make this work, these two pages must have been rendered to the browser before the transition is visualized.
The most advanced scenario (and also the most costly in terms of performance) is the use of transition effects in conjunction with the possibility to navigate directly to any page (that is, also to non-adjacent pages). This is possible by using the Pagebook’s API functions “setSelectedPageIndex” or “setSelectedPageByName”. Another possibility to navigate directly to non-adjacent pages is the Pagebook’s “Page Indicator”:
It shows one grey circle for each page and marks the selected page with a filled grey circle. By clicking on any of the grey circles the corresponding page is made visible. For smooth transition effects from a page to any other page all pages must be rendered to the browser. This is where setting the property “Page Caching” to the value “All” would make sense. However this comes at a significant cost in performance because all pages of the Pagebook must be rendered.
From a performance point of view the value “None” is the best choice for the property “Page Caching”. So choose wisely when using other values than “None” and hereby trading performance for fancy transition effects.
This is a living document and will be updated with new information. Be sure to come back or subscribe to this page if you are interested and want to stay up to date on Design Studio performance topics. Also have a look at SAP note 1931691 covering Design Studio performance topics.
You might be also interested in the following blogs:
Design Studio 1.5 - The Performance Release
Design Studio: Performance Implications of Variables
Design Studio Tips and Tricks: Measuring Performance
Design Studio 1.5: View on Parallel Data Source Execution
Design Studio: Parallel Processing and Scripting
Design Studio: Why is HANA Studio Faster?
Minimize the Number of Data Sources Loaded at Application Startup
By default, all data sources are loaded in Design Studio at application startup. For Design Studio applications with few data sources the application starts in sufficiently short time in the browser. However, the more data sources a Design Studio application has, the longer it may take until the application appears in the browser, as the application has to wait until all data sources have been loaded. This waiting time may be perceived by users negatively. One possible remedy is to reduce the number of data sources that are loaded at application startup.
Experience shows that no more than 4 data sources (information islands) are needed right from the beginning because humans typically cannot process a higher load of information. Using 10 or more data sources right from the start of the application clearly exceeds this limit by a wide margin.
To disable the loading of a data source at application startup, set the data source property “Load in Script” to “true”.
Later, when the data of the data source is actually needed (for example, when the user clicks a button), load the data of the data source in a Design Studio script with the Design Studio script method loadDataSource, for example:
DS_1.loadDataSource();
Incidentally, calling loadDataSource several times on a data source has no performance penalty, as all calls of loadDataSource following the first call are ignored.
Load Data Sources Only When Components Get Visible
Larger Design Studio applications may have components that are not visible right at application startup -- think of TabStrips with several tabs, Pagebooks with several pages, or any component that is initially invisible and shown, for example, upon a button click. You can improve the startup performance of your application by only loading the data sources of the visible components and not loading the data sources of the invisible components yet.
For example, you have a Pagebook of several pages with each page displaying the data of a different data source. One way to implement this efficiently is to load a data source only when the specific page of the Pagebook is selected. Add the following Design Studio script to the “On Select” event of the Pagebook:
if ((PAGEBOOK_1.getSelectedPageIndex() == 0)) {
DS_1.loadDataSource();
// ...
} else if ((PAGEBOOK_1.getSelectedPageIndex() == 1)) {
DS_2.loadDataSource();
// ...
} else if ((PAGEBOOK_1.getSelectedPageIndex() == 2)) {
DS_3.loadDataSource();
// ...
}
Recall from the previous section that you need to set the property “Load in Script” to “true” for all the involved data sources.
Note that calling loadDataSource several times on an already loaded data source is ignored and has no performance impact.
Incidentally, an even better version would exploit the fact that the page of the Pagebook which is visible at application startup (in this example this is the page with index 0 - but this is can be changed): Load the first data source DS_1 already at application startup (with its property "Load in Script" set to false) and use the following Design Studio script in the “On Select” event of the Pagebook:
if ((PAGEBOOK_1.getSelectedPageIndex() == 1)) {
DS_2.loadDataSource();
// ...
} else if ((PAGEBOOK_1.getSelectedPageIndex() == 2)) {
DS_3.loadDataSource();
// ...
}
When to Load Data Sources with Background Processing
The sections above implicitly suggest to avoid loading data sources at application startup when their components are not visible. If such an application design with few initially visible components is not possible, the following shows you how to improve the perceived performance of loading these data sources.
The idea is that the most important data sources are loaded first, while the less important data sources are loaded afterwards. While users focus their attention on components with data sources that are loaded initially, the Design Studio application loads the remaining data sources, which is not perceived as waiting time by the user. Loading the remaining data sources separately is done using a concept called “background processing”. Background processing consists of executing a Design Studio script in the “On Background Processing” event handler, which is executed asynchronously.
The basic steps are as follows:
- Configure the most important data sources such that they are loaded immediately by setting their “Load in Script” property to “false”.
- Trigger the background processing in the “On Startup” event handler with APPLICATION.doBackgroundProcessing().
- In the “On Background Processing” event handler load the remaining data sources with loadDataSource().
- (Optional) If loading the remaining data sources still takes a very long time (longer than the user would look at the components with the most important data source) and some of them are more important than the others you can load the remaining data sources in an iterative fashion.
For example, you have a Design Studio application with four data sources, the first two of them should be shown immediately. Then proceed as follows:
- Set the property “Load in Script” to “false” for data source DS_1 and DS_2.
- Set the property “Load in Script” to “true” for data source DS_3 and DS_4.
- In the “On Startup” event handler call APPLICATION.doBackgorundProcessing() (this is often the last line after all the other initialization script code).
- In the “On Background Processing” event handler load the data sources DS_3 and DS_4 with
DS_3.loadDataSource();
DS_4.loadDataSource();
If loading both DS_3 and DS_4 during the initial background processing take too long, you can split up their loading as described in step 4. While most of the steps above remain the same, the only step that you need to change is the last one:
- Create a global script variable, for example backgroundAction of type String, which is used to indicate which data source needs to be loaded.
- In the “On Startup” event initialize the value of backgroundAction before triggering background processing:
backgroundAction = "LOAD_DS_3";
APPLICATION.doBackgroundProcessing(); - In the “On background Processing” event add the following Design Studio script:
if (backgroundAction == "LOAD_DS_3") {
DS_3.loadDataSource();
backgroundAction = "LOAD_DS_4";
APPLICATION.doBackgroundProcessing();
}
if (backgroundAction == "LOAD_DS_4") {
DS_4.loadDataSource();
backgroundAction = ""; // not necessary, but good programming style
}
It is easy to see that you can extend this example with more iterations.
Incidentally, you can apply this concept not only in the “On Startup” event handler, but also in any other event handler, for example to trigger loading data sources when changing tabs in a Tabstrip component.
Note that background processing comes at a cost (for more details, see section "Background Processing Is Not For Free" in on Performance Improvements for Design Studio 1.5), so it’s best to use background processing only when needed.
Use a Single Data Source for Multiple Charts
When you have several charts, try to use a single data source with those charts and select the relevant data for the specific chart with the Chart property “Data Selection”:
This may involve redesigning the single data source as a superset of all the previously used data sources.
For example, you have one chart displaying data of a specific country, say Italy, and one chart displaying data of another specific country, say Spain. Then, instead of choosing two data sources – one for Italy and one for Spain – use a single data source containing country-specific data, including country-specific data for Italy and Spain. For the first chart use the Chart property “Data Selection” to select the data specific to Italy, for the second chart use the Chart property “Data Selection” to select the data specific to Spain.
Reducing the number of data sources in this way improves the performance significantly.
Selecting Data of Data Sources
There are several ways to select (or filter) data from a data source. They are discussed in the following list sorted by increasing performance:
setVariableValue
Lowest performance (if “Merge Prompts” is “true”), involves round trips to multiple data sources and potentially executes custom code on BW provided via “exits”.
Using variables involves the concept of a variable container. A variable container permits sharing of variables among multiple data sources. Therefore setting even a single variable with setVariableValue may affect multiple data sources, resulting in a larger performance penalty.
The sharing of variables is a very useful feature, therefore by default it’s turned on. However for functional or performance reasons the variable container can be turned off by setting the value of “Merge Prompts” to “false”). However setting a variable value even in “unmerged” mode has a higher overhead in BW that the other options mentioned below.
See Design Studio: Performance Implications of Variables for more details.
setFilter
Medium performance, involves round trips to a single data source
Contrary to setVariable, calling the function setFilter always affects a single data source only. Thus, if possible, prefer setFilter over setVariable. This may require restructuring the data source, for example by using the Query Designer for BW queries or HANA Studio for analytical views or calculation views.
setDataSelection
Highest performance, involves no round trip
While setVariable and setFilter operate on data sources, setDataSelection operates on components, selecting a subset of the data in the data source assigned to the component (at the time of writing only Chart and data-bound SDK components support setDataSelection). This involves no round trip to the data source and is therefore the fastest of the listed options. A common pattern is to configure the data source to contain a superset of the data of interest and then to select the actual data of interest to the component with setDataSelection.
Use "setDataSource" to Avoid Duplication of Components
Before Design Studio 1.5 the assignment of data sources was static and could not be changed at runtime. To “simulate” changing the data source of – for example – a crosstab, the application designer had to insert two (or even more – depending on the number of exchanged data sources) components at the same place, with the same settings. Later for one of these components the property “visible” was set to “true”, for the others “visible” would be “false”. If another data source should be shown these “visible” flags were changed accordingly.
This approach has the disadvantage of wasting resources because the number of components was higher than actually needed.
With Design Studio 1.5 this “simulation” by using the “visible” property is no longer necessary. With the “setDataSource” function the data source can changed as needed for every analytic component:
Exchanging the data source can be done with a call to “setDataSource”:
CROSSTAB_TOP_N.setDataSource(DS_2);
Minimize the "Start Screen" of Your Application
Performance is a critical topic for all areas of an application. However the most critical area of an application is the startup time. The perceived startup time is the time between launching the application up to the appearance of the first useful information in the application.
The design of the “start screen” can influence startup performance more than any other technical topic. Ideally the start screen consists of components referring to one single data source showing the most important data for the user. With that information the user should be enabled to choose which information he wants to see next.
It is important to emphasize that having only one data source at startup does not mean the screen consists only of one component. One data source can be used to feed for example both a crosstab and a chart. With the “data selection” feature one data source can also be used to feed multiple charts (see chapter “Use a Single Data Source for Multiple Charts”). In addition this data source can be used to feed entries of list-boxes or dropdown boxes to allow the users choosing other views of the data or switching to other screens showing more detailed data.
The following screenshot shows a screen that is populated with information from a single data source:
Use "Page Caching" of the Pagebook Wisely
The property “Page Caching” of the Pagebook component controls which pages are rendered directly to the browser.
The default value of “None” renders only the currently visible page to the browser. Other pages are rendered when they become visible. The value of ‘”None” is the most efficient one in terms of performance.
The setting “Adjacent” is a good solution when the “Transition Effect” property is different from “None” and paging is done only to go to the “next” or “previous” page. During the transition effect both of the pages are at least partially visible. To make this work, these two pages must have been rendered to the browser before the transition is visualized.
The most advanced scenario (and also the most costly in terms of performance) is the use of transition effects in conjunction with the possibility to navigate directly to any page (that is, also to non-adjacent pages). This is possible by using the Pagebook’s API functions “setSelectedPageIndex” or “setSelectedPageByName”. Another possibility to navigate directly to non-adjacent pages is the Pagebook’s “Page Indicator”:
It shows one grey circle for each page and marks the selected page with a filled grey circle. By clicking on any of the grey circles the corresponding page is made visible. For smooth transition effects from a page to any other page all pages must be rendered to the browser. This is where setting the property “Page Caching” to the value “All” would make sense. However this comes at a significant cost in performance because all pages of the Pagebook must be rendered.
From a performance point of view the value “None” is the best choice for the property “Page Caching”. So choose wisely when using other values than “None” and hereby trading performance for fancy transition effects.
Some Final Words...
This is a living document and will be updated with new information. Be sure to come back or subscribe to this page if you are interested and want to stay up to date on Design Studio performance topics. Also have a look at SAP note 1931691 covering Design Studio performance topics.
You might be also interested in the following blogs:
Design Studio 1.5 - The Performance Release
Design Studio: Performance Implications of Variables
Design Studio Tips and Tricks: Measuring Performance
Design Studio 1.5: View on Parallel Data Source Execution
Design Studio: Parallel Processing and Scripting
Design Studio: Why is HANA Studio Faster?
- SAP Managed Tags:
18 Comments
