Loading table ahead of user scrolling

#1

Hey everyone, I’m trying to figure out if there’s a way to increase the number of rows of a metric set that load when a user views a dashboard.

Ideally, I’d set it at xx rows, so as the user scrolls it doesn’t pause so frequently. I have plenty of available ram on my server.

Alternatively, I think it could load as the user scrolls, supposing that they will continue scrolling and hence loading should commence.

I searched the forum and found one discussion on this, but it was from 2018 and I hoped that the feature request mentioned was actually filed, but couldn’t find anything… Auto scrolling table

Any ideas?

#2

I remember it well.

I’d definitely add my name to the feature request

1 Like
#3

Would definitely add my name to to the feature request. There had been times where the loading freezes while the user is scrolling through the table

1 Like
#4

@tejas.shah - can you help us check to see if this request exists, and if not, help us file it?

1 Like
#5

I’d also like to add my name to this one. Thanks. :slightly_smiling_face:

1 Like
#6

Hi,

That other thread you linked to had a specific goal of automatically scrolling the table up and down, for example for dashboards displayed on TVs or other displays without input devices so that people can still see additional rows scrolled out of view. There may have been some miscommunication earlier, but that goal is possible like David mentioned using the API methods scroll or setScroll in script, depending on how exactly you wanted to scroll. “scroll” is like clicking inside the table and using the up and down arrow keys on the keyboard to scroll up and down, while “setScroll” allows you to set a specific pixel position that can accomplish precise or smooth scrolling. As long as scrolling occasionally pauses, additional data will load the same as if a user had been doing the scrolling.

If you instead have the goal of avoiding pauses or long loading times while scrolling a table, there are a number of different factors and use cases that can play into this. What is normally expected to happen is that your requested data is retrieved and processed once, and after it initially loads in your browser and you start scrolling, the table visualization is only asking for the next set of existing rows from the server from memory. This should normally come back almost instantly (i.e. a fraction of a second) regardless of the data source, the amount of data, or any other work done earlier such as transformations or formula calculations. If that’s not your experience for some of your tables, there can be different reasons for that.

If it takes a while for rows to load and you are still able to move the mouse over column headers or menu & toolbar icons and see their backgrounds & highlighting change, you’re waiting for the server, which is normally unexpected when you’re just scrolling around data that was already supposed to be in the data result cache. In some cases the problem might be a slower network connection between your browser and the Dundas BI server, or there might be something we should investigate in Dundas BI about your specific case.

If you’re waiting a longer time and moving the mouse over column headers and menus is having no effect, the browser is taking that time to render the rows, possibly because of a large number of columns as listed in the table’s Properties window under Columns or because of a large number of visualizations for data bar, bullet graph, or state indicator columns. In that case, loading more rows upfront can make the render time much slower and the browser unresponsive during that time, which we want to avoid. We do have reports (or scorecards or small multiples) meant to address longer render times by performing that rendering in the background and exporting a potentially long and/or complex report to PDF that you can scroll around freely.

I’m hoping here to come up with a common response but I think that each of your tables and scenarios may be quite different, and it’s possible we could help you with or investigate some of it. I’d encourage you to consider reaching out to support about your specific case if you’re not happy with the load times while scrolling so that we can sort through the different kinds of issues that may be occurring including the above, or we’d at least like to know more details to help determine any potential improvements to the product.

Thanks

2 Likes
#7

Thanks for your response @jamie.cherwonka . I finally got a chance just now to assess which of these scenarios I’m dealing with in my case. For me, when I scroll down, I get to the bottom of what’s loaded and see a “breathing” blank area. While seeing that, I can hover over column headers and see tooltips, scroll back up and see other data, and buttons and such all continue to be interactive. So, that seems to relate to your paragraph 3 explanation - the server-browser connection. My ISP is blazing (500/500) and all of my other users seem to have the same issue, so it seems server-side rather than client-side connection here.

However, this dash also has a big backend to its table in that there are numerous hidden columns, a lot of filters, a wide array of states, and a lot of rows (even with filters active). So when I first read your paragraph 4 scenario, I guessed that that was going to be my experience, but it wasn’t!

Soo… happy to follow up with support if needed, but I wanted to reply here in case my description gives you any thoughts, and the possible benefit of others reading is important, too.

1 Like
#8

Hi Ken, thanks for checking on that. That is normally unexpected, because even with formulas, states, and hidden measures the entire data result for a given set of filter values should be in the cache on the server so that the browser can quickly ask for more rows as you scroll around without having to recalculate or otherwise re-process any of it.

The network connection itself between your browser and the server may not be the likely culprit, but sometimes it’s possible. It could help to test from a browser either on the same machine or local network as the server for comparison if users are normally more remote, or the browser’s developer tools has a Network tab where you can see if the browser is spending all of that time waiting or if it’s taking that much time to slowly download the result for example.

Otherwise this would be something to investigate on the server or in Dundas BI. Hopefully the data result cache is enabled in administration, not disabled in the data cube, and not bypassed in the metric set options (caching is enabled by default by all these settings). If caching wasn’t disabled but you don’t seem to be getting cached results, and the server’s CPU or memory is not being consumed by other tasks, I think we’d be interested to know more about your data cube so that we can see whether Dundas BI is not caching that data when it should be.

#9

OK, we may have a hit there - I have the cache bypassed in the metric set. I can’t be 100% sure why I did that, but this data is static data (only updated 1x day) joined with live data (realtime, coming in from a writeback on another dash).

Could that be enough to do it? If so, I can enable the metric set cache to try it out, see if it breaks anything else.

#10

Hi Ken,

Yes please try this. If re-enabling data caching did not seem to help, please let us know because there may be a scenario here that we need to look at.

1 Like
#11

OK so I re-enabled it and it definitely was an immediate improvement to loading speed while scrolling.

However, because this dash also deals with live data, my users immediately told me that they weren’t seeing the table update as it was before.

So, I went in to the data cube that feeds this metric set and set a 5-minute time limit on the cache. It seems to be working properly now, but I’d appreciate feedback on whether this is an appropriate way to balance the cache/refresh issue!

#12

Sorry for the delay. If re-enabling caching helps, customizing the cache lifetime in the data cube closer to what your users expect sounds like a good idea. We are also looking into a way to improve this to ensure that the table always gets its data from the cache regardless of settings if you’re just scrolling the table, and I will post an update on this here.

Thanks

1 Like
#13

Thanks for bringing your scenario to attention: we discussed this and feature request 90540 has been entered to to be implemented in the next major version. We intended for data to come from the cache as you scroll around the table, so this will now apply even in situations like when Bypass Data Cache is selected for the metric set, while still getting the latest data when refreshing or auto-refreshing the data or when changing filters or sorting. (Don’t use the Disable Data Caching option on a data cube for a large table, though, because that option truly disables caching as it states.)

1 Like