metabase
Application takes a lot of time to render on a fresh request
Describe the bug
Let's say you don't use Metabase for internal analytics, but just for external: users won't have Metabase assets cached on their machines, so when they navigate to the iframe, they need to wait a full second from the time the assets get in their browser till the iframe renders, a lot of time for a snappy experience
To Reproduce
Just go to https://embedding-demo.metabase.com/ without any caching and see how much time it takes the parent app and then rendering the iframe, you'll see a very long time with a blank section
Check this out
Expected behavior
Snappier experience, almost instant rendering
Logs
NA
Information about your Metabase installation
It's been like this since the beginning, but the bigger the frontend, then the worse this gets
Severity
P2
Additional context
related issues
- Pretty sure a consequence of https://github.com/metabase/metabase/issues/4665
- https://github.com/metabase/metabase/issues/43330
Profiler shows a similar pattern
And the query endpoints are part of the dashboard api as well: https://stats.metabase.com/api/dashboard/2117/dashcard/12870/card/14356/query
If we can tackle both at the same time, better, but we should tackle the dashboard one first if possible
This has to do with https://github.com/metabase/metabase/issues/4665, not to https://github.com/metabase/metabase/issues/33499, this was my error
This was originally added to #33499, but I think we're focusing on the behavior on this issue.
The slow endpoint is https://stats.metabase.com/api/dashboard/:dashboard-id.
Here's what I've been able to do to attempt to reproduce this issue so far:
- @paoliniluis referenced https://stats.metabase.com/dashboard/2117 as a similarly slow dashboard to load
- To try to reproduce this locally, I created a large dashboard (36 cards) with a variety of queries (nested, custom columns, multiple sources, native, visual)
- Made as many filters as I could think of, many with enumerated values
- The json output of the referenced slow response on stats is 13770 lines at 388639 bytes
- My local response body is 15032 lines of formatted json at 443866 bytes
My expected response time would be higher locally as the dashboard is larger.
Results:
- That stats board (baseline) takes 4.39s to load
- My attempted reproduction loads in under a second (297ms)
- Assuming a similar level of complexity,
masteris an order of magnitude faster to load (the opposite of what is expected)
Here's a side by side view of the two scenarios. Note that the local dashboard (left side) loads much faster than the baseline. Also note that qualitatively, individual dashcard loading appears similar on both sides.
After adding opentelemetry spans to the metabase.api.dashboard/get-dashboard endpoint, we get the following trace on the local setup:
They hydrate function takes almost 80% of the invocation. The next step is to close the gap between the baseline and local by either getting a better complicated case locally or instrumenting the baseline issue to see what's happening differently there.
There is also this comment (over 2 years old) that there is a concern of an n+1 situation in the query. If this is the case, we need to optimize the query, but first we need to determine if this is the situation. It's still odd that two seemingly comparable dashboards have an order of magnitude difference in performance.
TL;DR let's keep it open until https://github.com/metabase/metabase/issues/43330 is not closed, context
@paoliniluis there are several reasons why the app can be considered as slow, in your example we have
- huge amount of js imported by iframe (so parsing and evaluating takes time)
- lots of
/query_metadataand/queryrequests, when a browser has a limit on a number of parallel requests, it was addressed (at least partially) in https://github.com/metabase/metabase/issues/43330
and even if I agree that the app is not rendered fast enough, parsing and evaluating of js takes ~300ms on my machine, we're waiting more for data
Regarding the goal to have
almost instant renderind
it's not doable in the current setup. Maybe SSR can provide such experience, but I doubt we have a way atm to render charts on BE.
IDK whether we want to keep such issue opened without a clear numbers we want to achieve, but the problem from the prev comment is partially fixed with a single query_metadata endpoint.
It should become better when https://github.com/metabase/metabase/issues/43378 is completed
@ranquild @alxnddr thoughts?
Well, actually for me it loaded only after 16 seconds, which is even slower than in the Luiggi's video :(
@mngr it depends on the reasons of slowness in your case. we can pair to identify the issue
Loads quite fast for me (1 sec), would be great to pair with someone who can reproduce 16 sec
The root cause seems to be that there is no separate bundle for static embedding; it loads the whole application. BE endpoints and MBQL lib usage should be already optimized.