Oracle Analytics and AI

Optimize workbook loading performance

Organization Name (Required - If you are an Oracle Partner, please provide the organization you are logging the idea on behalf of):

FAO

Description (Required):

We observed that some DV workbooks take a long time to load on the first loading. Afterwards, it is ok so apparently there is some caching taking place. It applies to both when workbook is opened in DV or when embedded in Classic. For Classic it is even worse as for embedded work book only blank page appears with no sign of life while it is loading sometimes 10, 20 seconds.

We tried to understand why, and best conclusions] we got so far is that it depends on number of tables in the dataset having multi-table join.

At least, can the loading text be displayed also in cases when DV workbook is embedded in Classic as long standing blank page is confusing to our users.

Use Case and Business Need (Required):

User experience

Enhancement Request / Service Request:

Find more posts tagged with

Planned

Analysis and Data Visualization

Status: Planned

Comments

Michal Zima

@zericdamir We are having exactly the same issue, which is becoming very critical - since it is occurring on newly build DV workbooks, which are part of "analytical application" , having very "VIP consumers" in our company and they will be really not willing to wait until DV workbooks will be loaded (it takes 2 minutes for some of those DV workbooks).

What is our observation of this very very limiting behavior (I am going to create SR on this topic, but it would be good is someone from Product Development/Mgmt could have a look at this issue here: @Gabby Rubin-Oracle, @Mike Durran-Oracle, @Bret Grinslade - Oracle Analytics-Oracle ):

Those DV workbooks, where we are "hitting" this long loading time are having first canvas (which displays first) without any vizualization connected with data - it serves as a kind of "landing page", containing just links (with some textual descriptions) to other canvases of same workbook , thus containing just text box visualizations.
During loading of DV workbook, no logical SQL to BI Server are issued (from reason, mentioned in first bullet), so long time of loading is really not caused by firing/executing logical SQL (and physical SQL) to get data for visualizations
I tracked in browser session (via Developer Tools in browser), what is happening behind scene, there are plenty of requests/URL going to OAS box, but there is one call (internal API call) fired during DV workbook loading, whose execution basically consumes most time of DV workbook loading time
This API call is following: https://<hostname:port>/dv/ui/api/v1/modelmetadata/reportdatasetsmetadatajson and his response (JSON format) returns following data/metadata:
List of data sets used in particular DV workbook along with all tables, join definitions between tables for data sets and also list of all columns of all data sets
This response can be pretty big (depending on no of data sets, no of tables, comprising those data sets and no of columns within those data sets) - for example for DV workbook, where loading takes for 2 minutes, size of this JSON response is 1,18 MB.
So I will definitely (within this SR I am going to create) ask for justification of such API call , when DV workbook is open for consumer (we are not talking about switching to edit mode) - are all those information (returned from this API call) really necessary in "client" logic (browser) to perform just display of DV workbook for consumers (not editing it) ?
How can performance of this API call (dv/ui/api/v1/modelmetadata/reportdatasetsmetadatajson) be improved via some settings (we need to definitely improve loading time, otherwise this will not be acceptable for our VIP end users for this "analytical application" in DV . And I don't really want to hear "advice from an ivory tower" like : Reduce number of data sets used in DV workbook (or reduce number of tables/columns in data sets) or split DV workbook into several ones, since every DV workbook has its own logic with all data in on place.

Gabby Rubin-Oracle

This is a good summary of the concerns we are tackling regarding workbook load time. Some of it is planned for January 2025 (and OAS 2025), but when it comes to performance, we cannot make generic claims without analyzing the specific use cases. Additional improvements are currently being worked on, which will come in during 2025.

@Michal Zima if you want to share a specific DVA or HAR file with us, we can inject it into our testing process.

Michal Zima

@Gabby Rubin-Oracle Hi Gabby, I have just created following SR "3-38865211321 : DV Workbooks initial loading takes long time - optimization needed" on MOS, where I have provided all information along with DVA and HAR file. So the best option would be to get in touch with support organization and ask for those artefacts . @Naveen Babu-Oracle can help you to get them. Thanks very much. Michal

Gabby Rubin-Oracle

Thanks @Michal Zima, we will review the files.

Jan Holub

Thanks to @ZericDamir and @Michal Zima for sharing this idea and submitting the SR. After an enormous campaign to involve our colleagues in the development of visualizations in Oracle DV, we are getting very negative feedback from key business departments and unfortunately we are facing very negative criticism that we have to continuously dampen. I believe this is some glitch that has escaped testing and the remedy from Oracle will be immediate (thanks @Gabby Rubin-Oracle for getting involved). Oh yeah, that's still something...