0 Replies Latest reply: Jan 22, 2016 12:16 PM by Tyler Waterfall RSS

    Why is my first reload of the GovDB 2.0 taking longer than before?

    Tyler Waterfall

      A few of you have asked why the Governance Dashboard 2.0 initial reload takes longer (sometimes significantly longer) than the average reload time of 1.1.1.

       

      The answer comes in two parts:

      1) GovDB 2.0 has removed Expressor from the data load process

      The great news: 

      • No more installation!
      • no more Expressor black box and :LUA patterns
      • no more expressor-related support cases we can't figure out
      • we can now make the hidden script available (password is in the load editor) and you can actually use it!

      The bad news:

      • Expressor took advantage of multi-threading better than the straight QlikView script does - hence the potential slower initial reload of 2.0.

       

      2) GovDB 2.0 uses incremental reload logic

      The great news: 

      • Subsequent reloads of the Governance Dashboard will happen much faster - than both the initial reload as well as the 1.1.1 reload
      • This means that only files that have been added or updated since the prior reload start time will be processed

      The bad news:

      • Incremental load logic does take some extra processing. However, this is far outweighed by the reduction in processing time due to skipping files that were previously processed.

       

      Q&A:

      Q: What should I do if the initial reload is taking a long time?

      A: Wait for it. Go get lunch, or if you are loading lots of data, consider a nice short book to read. After the reload completes, save the app and try reloading again and see the difference.

       

      Q: How long is too long for an initial reload?

      A: That depends on how much data you are loading. How much history do you have? How many QVWs and QVDs. How 'big' are the Server Event logs (MBs? GBs?). Where are these files located relatively to where you are reloading the app?

      Internal testing found that comparing 2.0 initial reload to v 1.1.1 reloads, the v 2.0 reload were 60-86% longer. However, the subsequent reloads for 2.0 were 83 - 89% faster than v 1.1.1.

       

      Q: But what if the subsequent reload is still too long?

      A: Consider dialing down your "Months of History", your "Heatmap/Concurrency days of history" and turning the Concurrency interval to 5 or 10 minutes.

       

      Q: Is there anything else that is resulting in longer reloads?

      A: Yes. GovDB 2.0 now presents Task Reload HISTORY. This means that you can track reload performance over time in 2.0, instead of only seeing the last reload status as you do in 1.1.1.  Also, GovDB 2.0 includes Reload heatmap charts, which visualize the 'hot' times for reloads by day & hour or by weekday & hour. And, GovDB 2.0 loads and presents the expanded user Audit log activity delivered in QV 11.20 SR9. Finally, GovDB 2.0 handles both QV 11.20 and QV 12.0 logs and files, which v 1.1.1 cannot.

       

      One other note or favor - if you are going to compare the reload times of the two, make sure you reload them pointing to the same folders, running on the same machine, and at about the same time of day to rule out extraneous factors (like virus scanning!).

      Thanks!