How can I troubleshoot the speed of the loading screen in OAC DV?
In OAC DV, after you click on a workbook to open it, you get a series of Dad Jokes before the workbook officially loads. Sometimes the workbook can take upwards of a minute to then open the workbook and then start the usage tracking. How can I monitor the speed of first click to when the workbook officially loads? From what I can tell, this is not in usage tracking because it's not actually running a query yet. This is becoming an issue with our business because it's slow performing and I have no way to troubleshoot it and make it better. Nor do I know which workbooks are the worst and I can pinpoint where to focus my attention.
- How can I track the dad joke load screen time?
- What causes the dad joke load screen time to be long?
- How can I speed up slow load screen times?
Answers
-
Hi Branden,
Thanks for being a part of the community. I am sorry, your having some issues with the service.
For the "Dad Jokes", you can turn that off in OAC in the system console
As far as any other slow loading screen times, there could be a variety of factors, from network/vpn/loadbalancers, private/public endpoint, etc.
For slow loading workbooks, you can use the performance tool in the developer referenceto analyze query times, network latency, etc.
For general checking of pages, I usually generate and analyze an HTTP Archive (HAR) using the browser developer tools / inspectors.
The above is only some general starting points.
Of course, you are always welcome to interact with us via a service request if necessary, but I hope that may give you a good start.
Other community comments, welcomed.
0 -
Hi Branden,
Additionally, here are detailed steps on how to generate a HAR file. Chrome browser natively provides the Developer Tools to facilitate this:
- Open Developer Tools from the menu (Menu > More Tools > Developer tools), or by using Keyboard Shortcut (Ctrl + Shift + i on Linux, F12 on Windows).
- Navigate to the Network tab on the Development Tool.
- Check Disable Cache option to prevent caching of resources for this specific page. Refresh the page to start capturing the traffic between the browser to the server.
- Click on the round button at the top left of the Network tab to start recording (If it is already red, you are recording).
- Check the box next to 'Preserve log'.
- Complete the steps that trigger your issue.
- Save the session by clicking on Export HAR... button.
Regards,
Ezequiel.
1 -
@SteveF-Oracle @EzequielC-Oracle
Let me summarize a little bit you answers:
1) Advise to use Developer Options
For troubleshooting long initial loading of workbook when the are not yet any logical SQL running/executing (as correctly pointed by Branden) , there are just something getting loaded (possibly parsing definition of workbook stored in json format can take some time as well for huge workbooks) and when you even are not able to "switch on" Developer Tools it is like "chicken and egg problem". So this will not help much I guess.
2) Generating HAR file for tracking loading time of different "resources" during workbook opening could be useful, but without knowing, what those different resources, whose are loaded during workbook opening, are (and there are plenty of them) is a kind "tricky task". The only thing I can do with this generated HAR file is to pass it to someone from Oracle Analytics Development (not support guys, they will definitely not know, they will just pass it to Dev) to analyze it and find out what's wrong - so you will end up by creating SR at support and push for passing HAR file to someone knowledgeable from Development.
0 -
@Michal Zima - point taken, but there is limited information in public forum, so general high-level information was provided.
We got the point that it was the initial loading time of "opening the workbook".
The developer tool reference was really ancillary addition. Was it needed in this case, probably not. Does it hurt to add additional educational reference, no it does not.
But, I disagree with you about the HAR analysis, there are many(not all) support experts that can analyze a HAR file, but we see ourselves as one team, and there is deep integration to solve issues.
Many customers, and their internal teams are highly skilled at that analysis to narrow issues, especially if they spot where a network delay may be occurring (say on vpn vs. off vpn for example).
Responders to the post don't know the skill levels. Again, the advice given was a "start".
Feel free if you have some constructive advice/suggestions for the person posting, then please do provide it, even if it is open a service request.
As it stands, the advice is:
- Turn off the messages, and test.
- Collect a HAR for for analysis if anything stands out, either by the customer team, or by Oracle teams (via a service request).
- Log a service request with all the details of the service region, type, connection location, type, browsers, etc. etc. and Oracle will get it sorted out.
0 -
Thanks for all the responses so far! So, if I'm reading this correctly, we think the addition of the Load Messages causes the load time to be worse?
As far as the networking piece of it, I'm not sure how that would be a factor. We're already logged in and navigating around OAC loading lots of workbooks. We shouldn't be establishing any new connections or anything like that. It appears to have a correlation to the complexity of the workbook and the speed of load time.
This is all speculation but, for example, a simple table in a workbook likely loads faster than a full workbook filled with multiple tabs and visualizations on it. I would like to test that theory but there's currently no way to "track" it because it's not captured in Usage Tracking.
0 -
Thanks for the additional information.
You are correct, in that, a more complex workbook could take more time. Again, this also depends upon the datasources (file-based, database dataset, subject area, live/cached, etc.).
This is where the performance tools in the developer reference can help.
One other best practice is to disable brushing globally (in the system console), and only enable it for workbooks that you want. Brushing is enabled globally by default. You can test this.
Here is the link to our best practices blogs (this is not specifically for this issue, but general information for you):
This blog in the series, may apply to your situation:
https://blogs.oracle.com/analytics/post/oracle-analytics-dashboard-rendering-mode-options
0 -
Branden,
How "big" are some of these workbooks taking time?
There definitely isn't a universal scale to measure them, but as Michal pointed out, the workbook itself being a huge JSON and the DV page being "empty" and fully dynamically generated by javascript, there is clearly a possible correlation between size of the JSON, complexity of the understanding of the JSON, extracting the required query, rendering the page, and the loading speed, even before to fire a single query.
Can you just validate looking at some of your problematic workbooks that they have the "large" size in common? (I would even go as far as exporting the BAR, extracting the catalog and going in the folders and look at the real "physical" size of the files if you don't have other ways to asses the size of your workbooks.)
As you see it's all guesses because it's a black box and in OAC you just don't have any possible access to anything on the server to be able to push the analysis further. Therefore it's all about finding correlation between observable elements and defining your own rule of thumb of when a workbook reach a size that will be considered "slow".
I'm also quite sure, if size looks like the factor, the only solution is to make smaller workbooks, split the content into multiple separate workbooks (not really a solution but more a workaround that generate a different kind of annoyance, it's all about which one is worse: this one or waiting).
0 -
@SteveF-Oracle I agree with you that educating people is always helpful, so thanks for that, this is worthy activity. And the link for series "Oracle Analytics Best Practices Series: Optimal Performance and Usage" is really very good, I wish there were more such "deep dive" content posted.
1 -
Here are some more additional general recommendations to improve query performance:
1) Make sure that the cache is enabled (default) by looking at Enable or Disable Query Caching:
Strategies for Using the Cache:
2) Look at About Refreshing a Workbook's Data:
3) Set predefined filter values so the workbook would load faster:
4) If the workbook also exists in Analytics classic as a dashboard or an analysis, you can use that dashboard to seed the cache with an agent. The queries would need to be the same in both the workbook and the analysis/dashboard:
Regards,
Ezequiel.
0
