Performance tuning in domo

Is it possible to enhance the performance of reports or dashboards created in domo with the help of any settings?

Or is there any way to improve it on frontend rather than improving performance at the database level.

for ex. I have millions of rows to be fetched into a domo report and its running very slow , so anything that we can do at domo platform level?

Find more posts tagged with

Comments

BlueRooster

If you're trying to have millions or rows processed at the card/dashboard level, I would suggest attempting to summarize the data via an ETL or SQL transform and then build your cards on that instead.

Example: Instead of using beast modes to sum values in your card, do the sums via the ETL, grouping the categories they way you need for the final product and then use this summary in display.

It can be a bit tedious, especially if you often make changes, but that's the best way we've found to handle large data processes bogging down the final dashboard.

Hope that helps,
Valiant

**Please mark "Accept as Solution" if this post solves your problem
**Say "Thanks" by clicking the "heart" in the post that helped you.

user06038

So can we say that we can not come under any performance issues due to heavy usage of card components like filters/metrics/formatting etc but we can face performance issues in fetching rows and that need to be solved at database level only.

BlueRooster

So I can only speak for what I've experienced in our environment and maybe this is more of what you're looking for:

Pages: The only times we've seen performance issues with pages is once we have a large number of cards (ie, 30-40) and many of those cards are expanded to be larger on the page. There can be some delay in responsiveness. However this appears to be due to browser/machine capability in rendering so much at once.
- Remedy: On pages that need to have that many cards we've ended up utilizing collections to break them up. Minimize the unused collections and try to keep the size of the cards reasonably small if possible. That helped with the delays we saw.
Cards: 2 things have created slow cards in our environment. The first being cards with a very large dataset and the other being cards with a large amount of 'chart junk'. Chart junk being something like using a bar chart, but having 1000 bars trying to be displayed at once.
- Remedy: For the cards with a large dataset (one that comes to mind that gave us problems was over 20million rows) I would recommend what I did earlier, in summarizing the reported output.
- For the chart junk, that's just down to design choice. We still have some cards with that many bars, but it's because the users who see those cards have segmented views of the card because of Personalized Data Permissions
As for filters, I haven't run into any real performance delays. There might be a slight delay when returning a selection list of 10+ thousand options, but nothing I would call abnormal.

Let me know if you have any other questions,

Valiant