Skip to Content
Author's profile photo Praveen Kumar Sharma

Testing Dashboard Designer Performance limits

Sub: To explore limits/boudaries of Dashboard Designer with respect to file size, performance and content volumes

Dashboard designer as a tool is very efficient in delivering dashboard functionalities with a lower lead time as compared to similar solution on a Java application settings or a Design Studio.

However this comes with certain limitation in flexibility of the tool. This document deals with helping users to overcome rigidity in the tool and deliver world class dashboards.

Generally it is observed that when developers work on dashboard designer tool, there is more focus on visual appearance and in doing so, the process of gaining knowledge on tool performance and limitations takes a lower priority. However, problems do crop up when we cross these limits and to make it worse there is very less content available on knowledge sharing portals, regarding finer aspects of dashboard limitations.

To list out few of the known recommendations:

1) Filters should be limited to 1000 rows maximum.

2) Try to keep dashboard on higher levels, and for finer details provide links to reports.

3) Following maximum 2000 records limit will not give performance issues.

4) Too complex navigation can lead to increase in swf size and give performance issues. You can use some hard coding if situation permits to reduce runtime calculations load.

5) The xlf size should not exceed 3MB limit as a thumb rule.

Room where developer can play around the above design limits and simultaneously deliver high performance dashboards.

1) While the 3MB limit exists for dashboard .xlf file, however you can exceed the limits if the file does not generate a large swf. (You can increase hard coding to reduce runtime calculation loads in swf)

2) Design data flow in such a way that at a time only max 2000 rows of data is fetched in the system, for extra data make it query in runtime.

3) Use BIWS for better performance. Have data staged in BO instances.

4) Split use cases and divide dashboard into proportions to optimize data volume in runtime.

5) Design a dashboard GUI which has multiple swf running in background, but for user the GUI is camouflaged and he will experience the whole thing as one dashboard. (With my experience in this solution, i can say for sure that lot of thinking would be required to manage the navigation and its timings withing swfs, as you may land up in a spiral of opening one swf into another and further another into the previous.)

Assigned Tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Amit Anant Kulkarni
      Amit Anant Kulkarni

      Great document and just to add to it ,at a point when adding some new functionalities to existing dashboards there comes a point when we are no more able to save the dashboard to the repository and we start  getting cannot generate flash error or runtime errors so in this scenario its the time to revisit its design and may be divide the dashboard into multiple dashboard.