Dropdowns are slow to load in Lumira

[nutpos]

Hi Experts

I've been building a lot of dashboards in Lumira (from DS 1.6 to Lumira 2.2 now) and one thing that I just noticed using the PROFILING=X is that loading data into binded Dropdowns are sloooow.

I have a dashboard that takes about 25 seconds to load in pure startup and I figured it was because of a lot of data sources being shown on the front page. But using the PROFILING, I found that Lumira was actually spending 3 seconds to load data into 4 different dropdowns I had. Meaning a whole 12 seconds of the startup time was to load these dropdowns.

Furthermore I noticed that whenever I would filter anything on the query binded to these dropdowns, it would take 1 second per dropdown.

Any ideas?

The way I see it, it's due to the fact that most of my data sources are not using the characteristics that I'm using to filter in my dropdowns - so it has to load the query to show the key figures, and then it has to load the query again to get distinct values of the characteristics.

Only "solution" I've come up with was to use a new datasource, wherein I load the needed characteristics with just a dummy key figure - so all are pre-loaded. But this seems like a bad solution to me - adding extra data sources in a dashboard already containing 110+ data sources (yes, it's big ;))

[former_member519891]

I've had similar issues when creating dashboards. One of the workarounds I found was to set the dropdown items in "On Background Processing" (see code below) instead of binding, which happens on startup.

On Start code:

APPLICATION.doBackgroundProcessing(); 

On Background Processing code:

DRP_DOWN_NAME.setItems(DATA_SOURCE.getMemberList("DIMENSION",MemberPresentation.TEXT,MemberDisplay.TEXT,1));

Chances are, your user doesn't need to use the dropdown box immediately after loading the page, and this allows them to get to the page a bit faster.

Also, if you're not already doing this, it helps performance to use parallel processing when loading the pages, and only load the data sources that need to be used at startup. We've started calling this "lazy loading," where we call the data sources to load only when a component is clicked that opens the part of the dashboard that uses it. If you do this, be sure to set "load in script" to "true" on your data sources. This speeds things up significantly! 🙂

[nutpos]

Hi Emily and thank you for the reply.

The issue I have with backgroundprocessing is that the query used in the dropdown is also used to show key figures on the front page - so I can't do that. I could use the setitems indeed, but then I would lose the binding functionality, where one dropdown is "filtered" based on the current query - aka filtering one dropdown will limit the values of the other dropdowns. A function much requested by the business.

Regarding the Load in script functionality, the query itself is just "loaded" with data, when the data is actually being shown. In my experience it's only a connection that's created for the query to begin with which takes about 1 ms - and the data load from BW is only performed once the data is shown (shifting to another page in the dashboard). I've messed around with this quite a bit and the performance drop from not loading in script is minimal.

Is there any way to set up the binding of the dropdown in the backgroundprocessing so it's not loaded until after the dashboard is being shown?