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.
"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
Post a Comment