My Dashboard/Report is slow

Slow content can have a number of causes to try and identify the best path forward to resolving these, we'll break this down into the relevant sections and then some options for further investigation.

With all of the sections below, please start with answering the following questions:

  1. Was this always slow? If yes, jump ahead to the relevant section
  2. If no, what has changed recently that might affect your content? The sections below will outline what to look at, but always be looking for system changes since the performance issues appeared.

My Reports are slow

If it is only one report which is affected, has this report always been slow? If it has only recently become slow then it would be worth investigating the following items for both an increase in the amount of data coming in and any changes made to these items:

The Report - were additional fields, filters, conditional formatting, calculated fields, sub-queries, co-displays or charts added? Each of these items can affect performance. Were any changes made to the filters used? Grab the report SQL generated by Yellowfin and run the query directly against the Database using a tool such as DBVisualizer. Does this time differ from the report generation in Yellowfin? If not, this could be related to your underlying dataset or configuration.

Access Filters - have you recently implemented access filters? Depending on the complexity of the filters this could impact performance as well.

If this issue affects all Reports, are you able to navigate around Yellowfin without any performance issues? If so, this suggests changes to one of the following:

The View - do all these reports share the same view? If so, what changes have occurred with the view?

The Data Source - If you find the Data Source to be the commonality in report slowness it's worth reviewing the source logs for timeouts or errors such as no connection available.

Through the Admin Console you can access your Data Sources. The Connection Pool settings allow you to increase timeouts to a data source, increase the max connections, or enable a secondary connection pool for the data source.

  • Timeout Setting - Useful if your View or Report is returning a large query that takes an existential amount of time to return.
  • Max Connections - This dictates how many connections Yellowfin can open to this data source at any given moment. Generally 2 connections per expected concurrent user is sufficient.
  • Secondary Pool - This creates a secondary connection pool to this data source which is reserved solely for background processes such as broadcasts.

Are you consistently having issues with a data source over an unstable connection? Good examples of this are AWS, etc. You can enable volatile data sources to help mitigate these types of issues.

If you can identify a change in any of the above that, when removed or disabled resolves the performance issue then please reach out to our Support Team for any additional troubleshooting steps.


My Dashboards are slow

If only one Dashboard is affected, the best place to start with is the reports itself. Run each of these individually to see if any of them take a long time to load. If only one or two reports appear to be the cause, please see the above section "One of my Reports is slow."

If all your reports individually load quickly, then the issue is more likely related to Cached filter performance or System Resources.

If all of your Dashboards are slow, are you able to navigate to other areas of Yellowfin? If not, then it sounds like your general performance needs further investigation and is less likely to be related to the content itself.

If your navigation run fine, but both your Dashboards and Reports are slow then this suggests changes to one of the following items has occurred recently to create this issue:

The View - does all of your content share the same view? If so, what changes have occurred with the view?

The Data Source - If you find the Data Source to be the commonality in Dashboard slowness it's worth reviewing the source logs for timeouts or errors such as no connection available.

Through the Admin Console you can access your Data Sources. The Connection Pool settings allow you to increase timeouts to a data source, increase the max connections, or enable a secondary connection pool for the data source.

  • Timeout Setting - Useful if your View or Report is returning a large query that takes an existential amount of time to return.
  • Max Connections - This dictates how many connections Yellowfin can open to this data source at any given moment. Generally 2 connections per expected concurrent user is sufficient.
  • Secondary Pool - This creates a secondary connection pool to this data source which is reserved solely for background processes such as broadcasts.

Are you consistently having issues with a data source over an unstable connection? Good examples of this are AWS, etc. You can enable volatile data sources to help mitigate these types of issues.


My Broadcasts are slow

If only one Broadcast is affected, does the report by itself take a long time to run? Does this broadcast go to a lot of recipients? Are there other Broadcasts running at the same time?

Yellowfin Broadcasts are designed to work in a particular way, understanding this will help you diagnose your issue.

Check the Yellowfin logs for Task Queue errors, as well as the Data Source and JDBC logs for No connections available errors. Both of these issues can occur when the number of Broadcasts being run has increased beyond the current configuration and will need to be addressed via the linked guides of each area.

Depending on your setup, changing the way these broadcasts are sent may alleviate your issues. Please see our option for Broadcasting Inline and Broadcasting using CC Recipients to see if these will meet your needs.


I've tried all of these and I am still having issues

If you have looked at the relevant sections above and are still unable to resolve the issue, please run our Performance Snapshot Tool, note the date and time you ran these tests and reach out to our Support team to provide some further analysis of these items.

Is this article helpful?
0 0 0