The Hidden Cost of the History List

The History List is one of my favorite features in MicroStrategy.  It can be convenient to quickly jump back to a previously run report and handy to retrieve a long running report later instead of having to wait around for it.  Instinctively, I’ve always used the “Automatically send reports to the History List” setting, because why not?  Well, as I recently discovered, there’s actually a pretty good reason why not.

I have a rather complex dashboard that I’ve been working on recently, and for various reasons it needs a lot of grid objects (117 of them to be exact).  Despite being sourced by about 14mb of Intelligent Cubes, it still took 12 seconds to load in Interactive Mode on all browsers, despite using Document Cache and regardless of VPN or Ethernet.  While trying to improve the performance, I noticed that the document xml cache it was creating was 16mb in size.  This seemed pretty large, but maybe not crazy since my Intelligent Cubes were roughly that size.  As a test, I removed every object from the layout and to my surprise it loaded instantly and with a document cache of only 300k!  This implied that the full 12s load was due to the layout generation, and that markup was taking up 15.7mb!

Thinking that I had stumbled on to a terrible inefficiency, I contacted MicroStrategy support and began working with them to see if there was anything they could do.  While demonstrating the issue, I jumped into my History List to pull a copy out so that I didn’t have to wait the 12s, and the engineer suggested that I turn off “Automatically send reports to the History List”.  After turning off this feature, the Dashboard loaded in 6 seconds!  That’s a huge speed improvement by simply turning off a convenience feature.

Why does this happen?
I can only guess as to the cause of what makes this happen.  One guess is that it actually takes ~5s to generate that 15.7mb layout and by adding it to the History List, it has to generate it a second time as opposed to making a copy of it.  Another is that it only generates it once, but since I’m using Database-based History List storage, it takes ~6s to insert a 15.7mb XML string into the database.  I’m not sure if we’d see improvement by using File Based History List storage, because unfortunately it’s a one way street, and you can’t convert from Database based -> File based.

Stop using the History List?
The loading time savings I experienced were certainly due to the large nature of my dashboard and will probably be negligible for most reports/dashboards.  Unfortunately, this setting is at the project level (you can find it by going to Web as an Administrator user, going to Project Preferences -> Default Preferences -> History List) so it’s practically all or nothing.  I went ahead and switched it to Manual for all of my projects since the way we use MicroStrategy doesn’t really take advantage of the feature anyway.  In other cases, a user can still get the advantage of the History List as a queuing tool by simply clicking the “Send to History List” link that shows up on the wait page while a report is running.

You may also like...

8 Responses

  1. Ankush says:

    Thanks Bryan for this very useful information.

  2. Scorpio says:

    Very useful information, thanks for sharing!!!

  3. sn ng says:

    Hi Bryan,
    We are executing a document using the RWExecute task and we are passing the parameter (execFlags=64) to move the result to history list.

    We are facing the performance issues with the heavy documents do you think this is because we are moving the result of every single execution to history list?
    If that is the case should we stop moving the results to history list ?

    And then how to execute the reports using the task as we wont be having the result present in the history list and we won’t be able to use the message id with the mstrWeb url.

  4. Unknown says:

    Hi Bryan,

    We are facing a strange issue in our MSTR 8.11 (Intelligent server is installed on Unix) of History List getting removed on its own after the 30-40 mins of report is completely refreshed and present in History list. We have made Governing settings changes to retain History List for 31 days and maximum number of messages per user as 10000, request you prompt reply to this issue on what setting we might require to retain our history list.

  5. atul agrawal says:

    Hi Bryan ,

    When i run the visualization it is showing wait page.but i don’t want this page any solution for that.

    Thanks,
    AA

  6. Souvik says:

    The HL have its own restriction. We faced one requirement where whole year report execution should be backed to HL (DB based), and whenever a user is added the user should be able to access the old HL reports. Now HL being user depnedent cannot be assigned back to other user. Moreover storing the HL for every report execution (leaving the performance part) consumes twice the sapce (once in server cache and other in DB as HL lifetime set to 1 yr).
    MSTR support did not got a feasible solution other than editing one server file everyday which does not seems to be a safer one on production system.

  1. March 29, 2016

    […] – done reading, using server side SDK http://www.bryanbrandow.com/2012/12/the-hidden-cost-of-the-history-list.html – done reading, the hidden cost is performance. […]

Leave a Reply

Your email address will not be published. Required fields are marked *