Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 
kmstephenson
Creator
Creator

Interpretation of Document Analyzer Results

Hi All,

To improve speed and performance, what should I focus on in the Document Analyzer? I'm using V2.8 on a large application - I'm pulling in QVDs and most of the calculations are done outside of QV. My dashboard is 60 sheets (!!) and appears to be the heaviest in the UI, not as much in the data model. I'm not sure what I should focus on in the Document Analyzer, and what I should be comparing RAM footprint, calc time, etc. to.... what is acceptable? What times do you all shoot for when the dashboard is opened or a selection is made? If the end users don't want to split up the application into multiple dashboards and document chain, what would you recommend as a work around to improve performance?

Thanks!!

Kristina

25 Replies
marcus_sommer

I think you need to determine what are the most critical points within these application - reload times, load times in access point, response times in gui ... and are enough RAM available. Also the network performance and if the environment is a virtual one could be have a big effects.

The document analyzer will give you fields which aren't used and could be therefore removed respectively to comment out. Another important point is The Importance Of Being Distinct.

On the gui side are 60 sheets not a big performance problem it's more an issue of usability. Further helpful are restrictions and conditions on the calculation of objects and dimensions/expressions, avoiding of calculated dimensions, the use of set analysis instead of if-conditions and so on.

- Marcus

kmstephenson
Creator
Creator
Author

Thanks, Marcus! We are hoping to improve load time and response times in the UI on Access Point. I will work on removing unused fields first. What else can the Document Analyzer tell me about my application? I use set analysis where appropriate and have pushed back much of the logic into SAS before pulling into QlikView. My concern is that the number of objects and sheets is what's slowing down the application... I have started trying to use conditional logic to hide and show resource intensive objects only when the sheet containing the object is selected. Is this helpful? Any other recommendations to improve performance using information provided in the document analyzer (or other methods)?

Thank you!

Kristina

rwunderlich
Partner Ambassador/MVP
Partner Ambassador/MVP

Take a look at the response times on the Objects sheet. Focus on those with high(er) response times.

Objects on a sheet that is not show should not be calculated, so their should be no need to hide them.

-Rob

http://masterssummit.com

http://qlikviewcookbook.com

marcus_sommer

In addition to the answer from Rob will be the use of mem-files very helpful: Obtaining Memory Statistics for a QlikView Document.

Further you might be have some potential with an optimized document-structure. This meant to split the document in dashboard-, report- and detail-sheets and further to reduce the number of sheets and objects by using from dimension- and expression-groups, containers and user-defined charts:

Using multiple charts and objects together

User Controlled Charts In QlikView

Another important point is to unify your expressions, for example: sum(Sales), SUM(Sales) and = sum(Sales) are different expressions from a caching point of view - which meant they will need more RAM and calculation times as if you would have only one notation.

- Marcus

kmstephenson
Creator
Creator
Author

Thanks, Rob!

Is there a calc time that all my objects should stay under? Or should the focus be more on looking at the outliers? The maximum calc time listed on the Objects tab is ~173,000, which is significantly higher than all other objects' calc times. This is for a straight table using nested IF conditionals with COUNT(AGGR())... not sure how to get around this though. I've also noticed that the calc time looks different on the Document Analyzer sheet than it does when I look at the calc time in the Sheet Properties in the dashboard - does this have to do with cache memory?

Can you clarify what you mean by objects on a sheet that is not shown should not be calculated? Doesn't QlikView do some behind the scenes calculations of expressions on all sheets when the dashboard is loaded? My thought was that for the sheets with heavy/slow response time objects, if I conditionally hide them until the user goes to that sheet, that those calculations won't be done until a user makes it to that sheet (and since my dashboard is so large, some users may never use those heavy sheets and then overall performance would be better). Let me know your thoughts.

Thanks!

kmstephenson
Creator
Creator
Author

Hi Marcus,

I have reviewed the Memory Statistics, but again noticed that the results changed depending on what sheet I was on in the dashboard, which objects I had clicked on prior to running the stats, etc.... is there a way to get better consistency in the results?

I have organized the document in a structure so that the 60 sheets appears less overwhelming to the end user - it looks like there are only 8 sheets in the dashboard (a template header takes you to these sheets), and then some sheets have subsheets and additional views of the data that can be navigated to by clicking a text object with an activate sheet action. Aren't container boxes resource intensive? I had created my own container boxes with text objects and using conditionals on the layout tabs of the charts... not sure if this is causing any performance issue but it doesn't appear to be dragging down those sheets.

And thanks for the recommendation about unifying expressions! I didn't know that those expressions would be considered different from a caching point of view. I will definitely go through the application and make sure I'm consistent!

Thanks!

marcus_sommer

The use of the memory statistics isn't very easy and practically and give only valid hints by the first opening of a sheet respectively objects then those calculations will be cached. But nevertheless this is for a first impression quite useful. If you really need to work more intensively with this method you need to disable the caching - actually I don't know exactly the name and where this option is - anywhere within the easter egg.

But before you are going deeper here I think you should optimize your expressions. Then your used nested if-loops within aggr-functions are beside calculated dimension the performance-killer number one and could be very probably optimized, for example with set analysis, pick(match()) conditions and outer if-loops instead of inner if-loops. For this see:

Pick Match vs Nested If Performance

Re: Multiple nested if statements

Re: Sum(if(...)) vs If(Sum(...), Sum(...))

Further options could be to transfer some calculations/matchings into the script, for example with using flags instead of conditions within the expressions or at least to simplify them.

- Marcus

rwunderlich
Partner Ambassador/MVP
Partner Ambassador/MVP

"Doesn't QlikView do some behind the scenes calculations of expressions on all sheets when the dashboard is loaded?"

No, only visible objects get calculated. (There was a bug prior to SR3 where some hidden objects got calculated).

-Rob

Q-On Training Center

http://masterssummit.com

http://qlikviewcookbook.com

rwunderlich
Partner Ambassador/MVP
Partner Ambassador/MVP

A course in using Document Analyzer and document tuning in general is available at the link on the Document Analyzer "Introduction" sheet.

-Rob