Average execution time for any application shouldn’t exceed 10 seconds.
We divided key factors which may impact dashboard performance into four categories:
- Underlying datasets
- Data blending of underlying datasets
- Application design
- Incorrect setting configuration
In this publication, we will give you some tips what to do to optimize application design, talk a little bit about data blending and try to tweak some configuration settings.
Optimizing Application Design
Below we listed some hints that may help you to optimize the application design. Some of them refer to the documents ONLY.
Tips that can help you to improve all types of your applications (RSD and dossiers) will have an “(A)” symbol in front.
- Reduce objects on the dashboard by:
- (A) Using links to another dashboard.
Although links in documents help you reduce data and increase performance, they do have some limitations. For example, passing value prompt answers from one document to another in a link is a common practice, and one that can have a negative impact on performance. This is especially apparent in the following two cases:
⦁ When there are a large number of prompt answers
⦁ When a prompt answer contains an attribute with a large number of elements.
When at least one of the above conditions is true, the generated URLs are larger than normal, and can cause errors with some browsers. When possible, divide documents with multiple panels into distinct documents that are linked together. To ensure that this method improves document performance, avoid the prompt limitations noted above, which can hinder the performance of your links.
- Using drilling down.
- Using quick switch if the same data is displayed as a grid and graph.
- Convert Multiple Grids and Graphs into a Single Advanced Visualization.
- Constraining the amount of data to be rendered the first time the dashboard is initialized should improve rendering time:
- (A) Use prompts.
- Pre-selecting an attribute element in a selector.
- Change the selectors from slice to filters to reduce the initial loading time of the dashboard.
- Enable on-demand fetching of panels.
- Activate incremental fetch for large grids (more than 500 cells). By rendering data in smaller slices, the incremental fetch setting in MicroStrategy Web can help significantly reduce the user wait times, while still handling the display of large result sets.
- (A) Limit the number of layouts when designing the dashboard because the more layouts there are the more time it takes to generate the document instance (virtual datasets).
- (A) Images should be placed on Web Server machine. Loading images that are NOT stored on Web Server machine will increase the client rendering time.
- (A) If there are big grids, that require scrolling, if thresholds are used, avoid using images for thresholds and replace them for characters.
- (A) Try to use search box selector if it has more than 100 elements.
- (A) Avoid using too many thresholds. Thresholds need extra processing on the Intelligence Server. A small number of thresholds won’t make much impact but when taking into account the number of views and the number of thresholds in each view, the cost will eventually add up.
An alternative method to using thresholds is to use dynamic images that are based on metrics that calculate the image numbers (for example, arrow1.gif, arrow2.gif, and arrow3.gif). Although this method still incurs the additional cost of the metric calculations required to determine the image to display, the XML data structure size that it generates is comparatively smaller than that generated by traditional thresholds.
- (A) Move static and non-dependent content outside of selector scope.
- Avoid nesting panel stacks (that is, placing a panel stack on a panel). include data in both panel stacks, not just the nested panel stack.
- Configure the page settings to load only one panel from every panel stack (enable On-demand Interactivity).
- Replace small grids with text boxes.
- Text fields from the same dataset perform better than using an entire dataset as a grid. However, using grids from different datasets perform better than text fields from different datasets. This is true for small and medium size grids only. If too much of data needs to be displayed, grids perform better than fields in both scenarios.
- Having too much of text fields will also slow down the client rendering time.
- Disabling the Fit to Contents option for grids.
- Optimize Rendering Options for Multi-Layouts Documents.
- A selector that controls attributes displayed on a Grid/Graph performs faster than a selector that controls attributes that are not displayed on a Grid/Graph.
- Avoid using HTML containers.
- Try to disable Lock Row/Column Header for large size grid, if possible.
- Limiting the number of drill paths (if not needed disactivate them on the large grid). To optimize report results rendering performance results in Web, it is recommended to use the Maximum number of XML drill paths governor setting in Intelligence Server. This setting limits the number of drill paths available to Web users and is shown below:
Note: this setting needs to be adjusted by the Platform Administrator.
- Review if all selectors in the application are used and needed. A larger number of items translates into a larger dataset.
- Limit the use of subtotals, they require Intelligence Server to perform extra processing steps to resolve them.
- Having group by will also increase the size of the document instance (virtual datasets) because it will increase the number of views of the document.
- If initial loading time is fast, but application acts slow, use selector controls to slice the data as much as possible this will improve response times by making the dashboard more compact.
- Set document width to fixed.
- Full screen could help to decrease the amount of content downloaded at execution.
- When using small grids, select “Clip” instead of “Scroll” to avoid unnecessary Java Script files
- Intelligence Server and Data Preparation – KB31503: Data Preparation at the Intelligence Server level for Dashboard Performance Optimization.
- XML Generation – KB31469:: Data Generation for Dashboard Performance Optimization.
- Network – KB31501: Network for Dashboard Performance Optimization.
- Client rendering – KB31462: Client Rendering optimizations for Dashboard Performance Optimization .
When application has multiple datasets, you can either want to join them creating relationships between attributes or treat each of them as separate entity.
- To ensure good behavior with the join the maximum number of attributes possible should be shared between datasets and situations where each dataset has attributes related to the shared attribute but not present on the other should be avoided. Many of the common situations can be seen in KB324175: “How data blending handles related attributes when joining datasets in MicroStrategy 10.x”. For more example see, Joining multiple datasets: Examples.
- You can decide whether joins across datasets based on unrelated common attributes are made by setting this option:
- For documents, it is set on project level Project Configuration > Project Definition > Advanced > Configure (VLDB) > Metrics > Join Across Datasets.
- Dossiers have individual settings File > Dossier Properties.
- Execution performance can be slow or memory consumption be higher when running a document or dossier containing multiple datasets in MicroStrategy Secure Enterprise 10.x. Follow steps in KB303013 to ensure the minimum memory consumption between multiple datasets.
Try tweaking the following configuration to improve the performance:
- Make sure you have a default project drill map configured in your project. In case it is empty then, MicroStrategy considers/loads the huge chunk of your schema into the memory. You can see the same reflects in the size of your application cache.
Execute the application and check the size of your layout HTML cache. if you don’t have default project drill map then you will see a big cache size and the same will impact the performance as well.
- Try setting “Use Minimum relations to do the join with less memory”
- For documents, it is found on the project level Project Configuration > Advanced > Project Level VLDB > Metrics > MCE Join to get data Combination: Select “Use Minimum relations to do the join with less memory”.
- For dossiers, it can be set on the Dossier level in File > Dossier properties.
Note: after a change, double check the data returned by the application.
- Check VLDB settings
- VLDB settings affect how the SQL is written when a report sends a SQL query to your data source. VLDB properties are usually determined by an administrator, but some may also be defined by a project’s designer.
- Ask your project designer about any configuration settings made for the project as a whole, because most reports and report objects revert to the project’s settings when no object-specific or report-specific settings override them.
Hope these high level guidance will help you to enjoy your fast running application and boost your business!
In next article we will show some tricks for dossier formatting! As always: stay tuned!