Skip to main content

Client Rendering Optimizations for Dashboard Performance Optimizations

 
The amount of data retrieved and objects being used in a Report Services Dashboard have a direct impact in the size of the final Dashboard. The bigger the Dashboard size the longer it will take to be prepared, be sent to the client, and render.

 

Client Rendering
Once the data reaches the end user's browser window the data has to be formatted according to the definition of the Dashboard as specified in the formatting set by the architect. To do so the browser will have to either build the HTML page in DHTML mode or initialize the flash container and parse the XML.

 

Client rendering greatly varies depending on the hardware used. More powerful machines will render dashboard faster for a list of recommended client hardware specifications please refer to the Readme File for the specific version of MicroStrategy.

 

Optimization Techniques common to DHTML and Flash
  • Client rendering time greatly relies in the amount of XML that needs to be parsed. In order to ensure that the XML generated is optimized please review the XML generation optimization techniques KB31469: Data generation for Dashboard Performance Optimizations in MicroStrategy Web 9.0.x

     

  • Pre-selecting an attribute element in a selector might improve rendering times by constraining the amount of data that will have to be rendered the first time the dashboard is initialized, as shown below.

     

     

    User-added image

    "All" Selection Vs attribute element preselected

  • Having HTML container on the dashboard will also increase the client rendering time as well, since more HTML content needs to be loaded.

  • Having lots of text fields will also slow down the client rendering time.

  • Loading images that are NOT stored on Web Server machine will increase the client rendering time. It is recommanded to place the images on Web Server machine.

Optimization Techniques for DHTML
  • After having built a DHTML dashboard following the XML generation techniques, if the usage of a large grid cannot be avoided, disabling the automatic resize option for MicroStrategy Web may improve the rendering performance significantly.

     

     

  • Also it is recommended to limit the size of a grid to 500 cells to be displayed on the page in DHTML mode. A larger grid will consume significant amounts of time in rendering on the client browser. DHTML Dashboards rely heavily in the use of JavaScript to align and position elements on the screen. Having more than 500 cells in a grid could potentially have performance issues, this being subjective to client hardware.
  • Having incremental fetch applied to the document will improve the rendering time for DHTML mode. However, in Flash mode, all data will be displayed.

     

Optimization Techniques for Flash
  • When using nested panels in a Dashboard in flash mode, all data is loaded in the browser memory; however, only the visible panels are initialized when the user first opens the dashboard (using MicroStrategy Web 8.1.1 GA or higher). When switching to one of the other non visible panels, the panel is initialized and put into memory so consequent retrieval of that panel is immediate. When using multiple grids or graphs in a Dashboard these can be spread across multiple panels if rendering is an issue, this will speed up the process of rendering the panels as they are needed for the first time the dashboard is opened
  • Having widgets on dashboard is very costly at rendering time, since more information needs to be loaded.
  • Having layouts on the dashboard will slow down the rendering time as well, because loading multiple layouts is almost like loading multiple dashboards.

Comments

Popular posts from this blog

Types of filters in Microstrategy

Types of filters in Microstrategy Below are the types of filters: 1. Attribute qualification filter These types of qualifications restrict data related to attributes on the report. a) Attribute form qualification Filters data related to a business attribute’s form(s), such as ID or description. •  For example, the attribute Customer has the forms ID, First Name, Last Name, Address, and Birth Date. An attribute form qualification might filter on the form Last Name, the operator Begins With, and the letter H. The results show a list of customers whose last names start with the letter H. b) Attribute element list qualification Filters data related to a business attribute’s elements, such as New York, Washington, and San Francisco, which are elements of the attribute City. • For example, the attribute Customer has the elements John Smith, Jane Doe, William Hill, and so on. An attribute element list qualification can filter data to display only those customer...

Microstrategy Dossiers explained

Microstrategy  Dossiers With the release of MicroStrategy 10.9, we’ve taken a leap forward in our dashboarding capabilities by simplifying the user experience, adding storytelling, and collaboration.MSTR has  evolved dashboards to the point that they are more than dashboards - they are  interactive, collaborative analytic stories . Ultimately, it was time to go beyond dashboards, both in concept and in name, and so  the've  renamed VI dashboards to  ‘ dossiers ’.  Dossiers can be created by using the new Desktop product or Workstation or simply from the Web interface which replaces Visual Insights. All the existing visual Insights dashboards will be converted to Dossiers   With MicroStrategy 10.9, there was an active focus on making it easier to build dashboards for the widest audience of end users. To achieve this, some key new capabilities were added that make it easier to author, read, interact and collaborate on dashboards ...

Level metrics in Microstartegy/MSTR

Level Metrics Level metrics allows the users to choose the right combination of level target, filtering, and grouping (referred to as elements) to achieve your desired results.  The elements of a metric level are described below: • Target : The target is the attribute level at which the metric calculation groups. For a more detailed description, see  Target: The context of a calculation . • Grouping : Grouping determines how the metric aggregates. For a more detailed description, see  Grouping: How aggregation is performed . • Filtering : Filtering governs how the report filter interacts with the metric calculation. For a more detailed description, see  Filtering: Interaction with report filters . The level is indicated between the curly braces ({ }) in the metric definition shown below: Sum(Revenue) {~, Product} The tilde (~) represents the report level with standard filtering, denoted by the plus sign (+). If you add item as a level, th...

Apply or Pass-through functions in Microstrategy

Ap ply (Pass-Through) functions MSTR Apply functions provide access to functions or syntactic constructs that are not standard in MicroStrategy but are provided by various RDBMS systems.. Syntax common to Apply functions Apply Function Name   ("expression with placeholders", Arg1, Arg2, Arg3, …ArgN) where: Apply Function Name  – is a generic name used for the predefined pass-through functions described above expression with placeholders  – is the string describing the actual expression or syntax that the engine uses while generating the SQL and which is sent to the RDBMS. The placeholders are represented by #0, #1, and so on. "#" is a reserved character for MicroStrategy. Arg  – is an argument that replaces the parameter markers in the pattern. Arg1 replaces #0, Arg2 replaces #1, and so on. There are   five  pre-defined Apply functions to replace regular, predefined functions of the same type. For more details, cli...

Case functions Microstrategy

Ca se functions Microstrategy Case functions return specified data in a SQL query based on the evaluation of user-defined conditions. In general, a user specifies a list of conditions and corresponding return values. Case This function evaluates multiple expressions until a condition is determined to be true, then returns a corresponding value. If all conditions are false, a default value is returned.  Case  can be used for categorizing data based on multiple conditions. This is a single-value function. Syntax Case ( Condition1 ,  ReturnValue1 ,  Condition2 , ReturnValue2 ,...,  DefaultValue ) Example Case(([Total Revenue] < 300000), 0, ([Total Revenue] < 600000), 1, 2) sum(Case (Day@DESC in (“Sat”,”Sun”), Sales, 0) {~+} Sum(Case(Category@DESC In("Books","Electronics"),Revenue,0)){~+} CaseV (case vector) CaseV  evaluates a single metric and returns different values according to the results. It can be used to perfo...

Microstrategy Release Types and Scheduling

Microstrategy Release Types and Scheduling Organizations that use MicroStrategy have asked for a more frequent and predictable platform release schedule—and we listened! We want you to be able to adopt the latest innovations more regularly while having the ability to budget for your long-term upgrade roadmap. Recently announced by CTO Tim Lang in his newsletter, that’s why we’re adopting an annual cadence for future platform releases. This means that our upcoming platform release (v11.1) hits the streets in Q4 2018, followed by another platform release in Q4 2019. PLATFORM RELEASE Interval:  Annually every twelve (12) months in December Who:  Entire customer base What:  Focus on production level security, stability, and performance defect fixes for all customers. Expectation:  Customer has chosen platform path and wants product stability without new enhancements. Support:  Three (3) years, patches for approved P1 defects, an...

Microstrategy Report Execution Process

The Report Execution Process  Report execution process at a high level: The report execution process is a three-step process:  1. Query Stage : Retrieve data from the warehouse  2. Populate and Evaluate : Fill report data required for display  3. Cross-tab : Pivot and display sorting and page-by Each of the engines plays an important part in the report execution process.  As you can imagine, the SQL Engine performs its role during the Query stage while the Query Engine and Analytical Engine can be involved in all three stages.

Microstrategy Caches explained

Microstrategy Caches Improving Response Time: Caching A  cache is a result set that is stored on a system to improve response time in future requests.  With caching, users can retrieve results from Intelligence Server rather than re-executing queries against a database. To delete all object caches for a project 1 In Developer, log into a project. You must log in with a user account that has administrative privileges. 2 From the  Administration  menu, point to  Projects , and then select  Project Configuration . The Project Configuration Editor opens. 3 Expand  Caching , expand  Auxiliary Caches , then select  Objects . To delete all configuration object caches for a server 1 Log in to the project source. 2 From the  Administration  menu in Developer, point to  Server , and then select  Purge Server Object Caches . 4 Click  Purge Now . To purge web cache follow the steps in the link ...

Purge Web Caches in MicroStrategy Web

Purge Web Caches in MicroStrategy Web By executing the mstr server by embedding the blue text below with admin privileges purges web server cache. https:// mstrserver.com /MicroStrategy/asp/Admin.aspx//mstrWebAdmin/?pg=purgecaches MicroStrategy Web and Web Universal caches various properties that are related to the user, project, or the MicroStrategy Intelligence Server. This helps in reducing the response time for every request by delivering the properties from a closer location than the original MicroStrategy Intelligence Server. In majority of the cases, the default caching properties should be applicable to the business intelligence infrastructure. There are 3 types of caches used in MicroStrategy Web. These are described below: Session Cache - Specific to a user and exists only while the user is logged in. This cache is deleted when the user logs out or if there's no activity for a specified timeout interval. The default value for a timeout is 1200 seco...

Documents with derived attributes cannot be edited within MicroStrategy Developer 10.x

Documents with derived attributes cannot be edited within MicroStrategy Developer 10.x When trying to edit a document created in MicroStrategy Web using MicroStrategy Developer 10.x, the 'Edit' button is found greyed out and inaccessible as per the screenshot below. When navigating to the same document in MicroStrategy Web 10.x, it is possible to edit the document. STEPS TO REPRODUCE: Create a document in MicroStrategy Developer or Web 10.x with any number of attributes. See below: Notice in Developer, you can currently right click on this document and select the 'Edit' option. Open up the same document in MicroStrategy Web 10.x and add a derived attribute, right clicking an attribute and selecting Insert new attribute. Save the report in MicroStrategy Web 10.x with the same name. Open MicroStrategy Developer 10.x, and right click the document, you will notice that the Edit option is greyed out as seen below: Navigate to the same document wi...