_dash-update-component takes up to 8 seconds, to send a request for chained callbacks

Hi! I am having some strange performance issues with chained callbacks, and wondering if anyone has seen this before.

The issue:

I have quite a large multipage app, that runs smoothly on localhost, but when I deploy it to Heroku, it takes up to 8 seconds to send some requests, with as little as 181B of data. The actual response however only seems to take about 500ms (or so). This is only happening to some callbacks that are chained after each other, since updating a large number of components with one callback seems to work fine.

Here are some images of the network tab in chrome:


Sadly I can’t show the exact code, but the structure of the callbacks is generally something like this:

Thanks, in advance for any help.

Hello @sb_aogh,

My first thought is your ping to the server, and internet speed. Local host has to deal with neither of those.

That being said, is there any way that you can bring more of the callbacks together. It looks like there is one update that might be a data transfer? If so, have you considered serverside outputs?

Hi @jinnyzor,

Thanks for the suggestion.

I do think my ping plays some role in this, but I don’t think it’s the primary problem. As I have other callbacks that are sending much more data and are being completed within about 10ms (and my internet connection is generally pretty fast).

There is a data transfer, that takes about 5 seconds to download. I haven’t thought of serverside outputs, but that might be a good solution to that, but do you think the transfer might have something to do with the other callbacks taking such a long time to send?

I have thought of grouping the callbacks together, but they are about 700 lines of code, so I would prefer to only do that as a last resort.

Depends on the information in the request. If it is a heavy request, then the delay is two fold. One when you are sending the request, and the second when you are receiving the response. Each callback should fire independently of each other, as an individual request and response. You probably have an idea of which callback this is, but in case you dont, you can also click on the long response and look at the payload. This will tell you the outputs, state, and inputs inside of the callback.

Other factors that go into the transfer as well, server-side compression, browser-decompression. But, it is the biggest download at 17.2 mb.

It looks like you have two other callbacks that get triggered from the long one, if you can get the long one to be smaller and less time consuming, then you will speed these two as well.

Ahh, I didn’t think of the fact that the data will be used on the server with each subsequent request that uses it. Just restructuring a few documents in the database already makes a large difference.

Thanks again for your help.

1 Like