This content is now out of date.

Visit Our Community

Why does caching a view slow down working within that view?

Good morning guys, I hope that subject line makes sense.

Basically I've started caching some of the bigger more temperamental views we have, which initially run just fine however whenever I want to access that view I find that there are big delays in navigating around that space of YF; for example it'll take 5-6 minutes to click from one window to another where it was a delay of seconds pre caching. If I remove the caching process of the view then these delays are gone.

My question is - Is caching meant to have this type of impact on a view? and if not, what might I be doing wrong?

I've read a number of other forum entries where you have advised that some of the virtual tables in the view contain code that conflicts with caching, one such expression was CAST which none of my tables contain however I do use CONVERT. Perhaps I'm experiencing a similar issue with the expressions I'm using?

Happy to provide whatever you need to assist in answering my question.


System Information
Application Version: 7.1
Build: 20150729
Java Version: 1.8.0_25
Operating System: Windows Server 2012 6.2 (amd64)
Hi Nathan,

Thanks for the question.

View caching is a tricky topic because it has to potential to either improve or hinder view/report performance depending on a variety of factors. I've gone ahead and attached some documentation that does a good job explaining how Yellowfin view caching works and whether or not it is a good decision to be using it:

In-Memory Analytics

How does the In-Memory DB work, and will it make my reports run faster?

Regarding cast and convert, the reason these functions conflict with view caching is because view caching supports specific data types (outlined in the In-Memory Analytics document). If your view cached successfully, then it's likely that these functions weren't hindering that process as you would have received an error instead of just experiencing poor performance.

I think your best bet here is to really consider if view caching is necessary since it doesn't sound like report/view performance is slow when caching is not in use.

Hopefully this information is helpful. Please let me know if you have any questions or concerns.

Kind Regards,

Hey, thanks Dustin.

So from what you've provided me I've learnt that perhaps incremental loads of this particular view to YF's IMDB is not the answer (assuming I want to work within that view every so often).

Perhaps a more efficient alternative is caching the actual reports themselves (Report Version History)? These reports can take some time to load meaning broadcasts of the reports aren't always successful, so some form of caching/archiving would be beneficial here I believe.

Do you have any thoughts around that approach before I get started? (ie: I could be faced with similar problems? I've completely missed the point of archiving reports? etc?)

Thanks again.