I have a fairly complex Dash application. It became very slow. In particular, initial loading takes a considerable amount of time. I’ve been learning how to profile a Dash application and found several resources online. Eventually, I ended up looking at the time consumed by the callbacks and noticed things like this
I’m not a professional web developer, but as far as I understand, most of the time is spent in establishing the connection, while the time taken by the Python code is minimal (35ms). Is that correct?
If it is true that most of the time is spent in the network (transferring stuff from the client to the server and back), or waiting to establish a connection, my question is: what explains this time consumption?
It’s hard for me to provide a minimum reproducible example, as I don’t see this issue in smaller apps, only in this huge Dash app that we’re developing for a project.
As a side note, I’ve been using what’s suggested here Performance Profiling Dash apps with Werkzeug - Dash Python - Plotly Community Forum and I find the timings reported different from the ones I get if I run the same function in plain Python. For example, the profiling tool reports that loading a parquet file takes 200ms, while it takes 3ms in plain Python. Have you ever seen this before?
I don’t know your application so it’s hard to tell and by no means am I an expert.
But somethings which I came across when my apps got slow are:
I imported database connections and established them directly. For example, import and initialise a class in a page file to use it later. This led to multiple connections being established on app start.
Dropdown fields or other things which were populated at the beginning consumed time, since we needed to query the data before the app fully loads.
Depending on whether you use dash mantine or not, if you have many components on one page, that might slow down initial load at some point.
Thee bigger the app the more callbacks. That might slow things down as well. You can try to reduce callbacks or use pattern matching. If you don’t do it, it might help.
I think #3 and #4 could apply in my case. I am using Dash Mantine Components and I have several components. I also have many (between 30-40) callbacks. Some of them are using pattern matching, because I needed that.
Do you know why using more dash mantine components can reduce performance? The same with callbacks. Is it related to the initial call at start time?
Nevertheless, according to what I’ve been looking in the browser Developer Tools, it seems the connection start takes a lot of time. I have no clue why that can happen.
I don’t think 30 - 40 callbacks should be an issue. I have apps with fare more than that.
As far as I get it together, for Mantine you have the MantineProvider, which is another Layer between the components. In the newer version they switched to CSS, which increased performance. But still, it will load the styles and apply them as the page loads.
IF it’s really the initial connection, then it seems more to be related to load of the layout, or some classes which initialisation takes loger.
Is the initial load speed the same for every page? So if you start the app at another page, does it vary?
Did you try to time the steps of the creation process? Maybe there is one step which takes so long.
Is your screenshot a profiling result of your app running locally or on a server ?
Do you have pattern-matching callbacks in your app?
Is this 300ms delay happening on other callbacks (could you provide the full timing for other callbacks?)
Web browsers are limited to a certain amount of concurrent requests at the same time (<10 if HTTP1) . So if you have 10 callbacks already triggered before (i.e. 10 requests running) the 11th will have to wait for a slot.
In this way, it’s not an issue from Dash. But the amount of Dash callbacks increase the amount of initial requests.
A way to mitigate this behavior is to prevent initial update (prevent_initial_update=True), thus reducing the amount of callbacks (=requests) made at start.
