Flash is all the rage in the microstrategy community these days.  It’s a far better way to visualize multiple datasets compared to the old static pdf/html report services documents.  MicroStrategy flash dashboards have allowed users to pivot, filter,and drill on many metrics simultaneously in the same view.  Coupled with this enhanced level of interactivity are really clean and pretty visualizations.  All of this is quite compelling and validated by the general adoption of flash/flex in BI.  Unfortunately, there is a trend out there that’s pushing the dashboard beyond its original definition and intended capabilities.  Instead of simply viewing high level aggregated results, users are demanding detailed tabular data in the same space.

Currently microstrategy does not stream data to the flash dashboard, instead the whole xml data source is downloaded to the client.  Additionally, this xml source can get large as many of the interactive views are precalculated server side.  Because of these reasons, kitchen sink dashboards in flash view will be slower than the public’s general experience with flash content.  I have seen dashboards that are so big that it takes 10mins or more to render (post execution).  Although interactive mode is a better performing alternative, clients generally prefer flash because of its slicker interface.

Our current client had at one point built dashboards that were 50mb+ when exported from narrowcast as mht files.  We ended up using narrowcast to write to local file servers since web-based rendering was critically slow especially for our Europe and Asia users.  Here are 10 strategies you can use to improve your flash dashboard performance:

1. Break the dashboard into multiple dashboards and link them together in a logical way.  If the dashboards are prompted you can of course pass the prompt answers in the url.
2. Reduced the row count of detailed grids.  Try using rank on one of the metrics and display only the top 10 rows via view filter qualification.  Then provide a link to the detailed report which is a regular micostrategy grid report.  This way the report results are already cached, users get a preview of the grid data, and if they want more info they can easily access it.
3. During development monitor dashboard xml size.  You do this by installing a FireFox plugin called firebug.  In the Console > Net window you will see all the components downloaded when rendering a page.  Look for something called GET taskProc?taskID=docXMLResult…  There are two and the second one usually corresponds to the actual data.  You should see the size next to it, if not you can download the file directly and save it to your desktop.
4. Try to keep the xml size (file mentioned above) under 6-7mb.  During our testing this seemed to be the optimal size beyond which dashboard rendering and selector performance degrades.  We have implemented dashboards up to 12mb, but user expectation was set appropriately.
5. Narrowcast dashboards over 7mb as mht files.
6. Avoid large metric selectors when possible.  Each metric in this type of selector corresponds to a chunk of xml that defines a precalculated grid view.
7. Use attribute selector over group by for paging.
8. Don’t go crazy with interactivity.  The more selectors and widgets you add the worse your dashboard performance will be.
9. When narrowcasting very large dashboards using personalized page execution with segmentation objects to reduce the dashboard instance size.  Services with dashboard instances over 200mb move very slowly in the slicing phase.  Sizes above 200mb can cause narrowcast to crash.
10. All else failing, push hard for Interactive Mode.  If designed properly it can look quite nice.

All of the above suggestions are valid as of 8.1.2.  I will update this post if these assumptions are to be changed in future releases.

ajo Dashboards 8.1.2, flash, NarrowCast, xml