Experiencing weird slowness when deployed

This may not be anything anyone can help me with but I thought I’d ask anyways because I’m at a loss as for why.

When I work from home, I use a VPN with my company to be able to access their SQL databases and other things. My newest Dash app queries from them. When I’m in the office everything is totally fine and running fast and smoothly. When I’m home, it’s dreadfully slow. Even things that shouldn’t be slow.

An example of something that shouldn’t be slow is that I have 2 radio buttons and 5 drop downs. I have the placeholders in the dropdowns change based on the radio selection. When I change radio selections, it takes at least 30 seconds for the placeholder to change.

I’ve made previous dash apps in this same situation and never had slowness. The only difference is that in this dash app I’m serving the layout as a function. Could that be the problem? I don’t see why it would be but I didn’t do that in my other apps and haven’t had this issue.

Any thoughts would be appreciated. Thanks!

Hello @bpolasek,

How are you hosting the site? Locally at your house and then you are querying the data over the VPN?

If so, you have to keep in mind the round trip of the network for the SQL queries to perform. If, you were to host the app there at work and then access it while on the VPN, you may see a boost in speed.

Hi @bpolasek,

Can you see anything special in the network tab of the developer tools of your browser. Or can you see anything specific in the timings of your callback graph?


Here is a snippet of my network between selecting the final dropdown which triggers the graph and the graph and save buttons loading.

As you can see, it’s taking about 14 seconds for the graph to load (pretty quick in comparison to other trials). And this isn’t even running a sql query. All the sql queries have been run on page load and are sitting in dcc.Store components as dataframes.

Yeah I’m not concerned with the SQL queries as I expect them to be slow on the VPN. But what’s weird to me is the changing of the callbacks that don’t involve SQL queries.

We cant assume that your callbacks arent using queries… The data exchange shouldnt be using too much to transfer the little data that is taking place.

What is your callback structure?

What happens if you disconnect your VPN once your data is in the dcc.Store?

Are you using localhost:port / for when you are accessing, or are you using your works IP address?

If you see in the network tab on a specific request, you can see the detail of where the time is spent. sometimes it can be just as stupid as a DNS request issue.

Also is the app/data hosted at your company or is it hosted in the cloud/or a third party

Okay actually I left out a part that’s actually pretty important.


It’s not the VPN. We are hosting it on a virtual machine - NVIDIA DGX Server. So it has to run through there. Because when I run it NOT ON that server, with VPN, I don’t have these issues. Only when it’s deployed through that server AND on VPN do I experience the slowness.

I am going to assume that you are using your dcc.Store in your callbacks as a State.

With that assumption in mind, it means that your data payload is always going to include that information, making it heavy. To avoid this, you can use ServerSide caching as provided by dash-extensions:

Or, you could pair down the info to be only what you need to drive your dropdown selections as well.

Or you could use clientside callbacks for pairing down the data of the selections, since I highly doubt that the round trip is necessary to filter down what selections you want to populate. XD

I agree, but like 14s for 5 dropdowns and like a few Kb of data. this seems extreme. also on the 204 the same thing. seems to me there is something else wrong.

Yeah the data pull itself is in total about 6k rows so I didn’t think it was that much. My other apps have handled more.

I’d ping your server on the VPN. See what your response time is without data.

Would you say clientside is better than server-side caching? I was looking at server-side caching article before you updated your reply. If I were to go the server-side route, would DiskCacheManager work here instead of FileSystemCache?

cc = CallbackCache(cache=FileSystemCache(cache_dir="cache"))

Also for clarification the difference between:

@cc.cached_callback(Output("store", "data"), [Trigger("btn", "n_clicks")])  # Trigger is like Input, but excluded from args
def query_data():
    time.sleep(1)  # sleep to emulate a database call / a long calculation
    return px.data.gapminder()

@cc.callback(Output("dd", "options"), [Input("store", "data")])
def update_dd(df):
    return [{"label": column, "value": column} for column in df["year"]]

The cc.cached_callback and cc.callback is dependent on if the store is being used as output vs. input?

Ping the sql server?

The server hosting your web app.

It should be the same as the IP address you are punching in to your url.

Average 42 ms

Client side you wouldnt have to deal with the round trip at all, for things that dont require the server to manipulate, then it is quicker for sure.

42 ms shouldnt be bogging you down, but you might also be experiencing issues with bandwidth.

If you were to use ServerSide caching however, you’d see a boost on your initial loading of the page too.

1 Like

Okay I’ll try client side first. Never worked with it so about to learn something new!

And I thought it could be my personal WiFi but I know others have had the same issues when they are at home. My boss just says it gives everyone a reason to come to the office :joy:

I have messed with VPNs and transferring files on a shared drive, it was a nightmare, even for people with fast networks.

I eventually had the files downloaded to a folder on their computer straight from the ip address where they were stored instead of the shared storage location.