Slow/noticeable callback execution when updating multiple graphs

#1

Hi there,

I seem to be experiencing oddly slow callbacks. Happens when there are multiple graphs being updated simultaneously (see attached for example); when a change is triggered (i.e. selecting a different state), you can literally see the callbacks being fired off one by one. I would expect this to happen near instantaneously, or fast enough the eye wouldn’t be able to detect it.

Doesn’t “break” the app, but does significantly hurt the overall experience. Wondering if this a common experience or how to make callbacks fire faster. I could understand if there were thousands of data points being simultaneously updated, but five <10 data point bar graphs doesn’t seem like it should be slowing the system down.

Thoughts/suggestions much appreciated!

#2

In production, you’ll want to run this app with multiple workers. With gunicorn, that is:

$ gunicorn app:server --workers 4

where app refers to a file named app.py and server refers to a variable inside app.py that’s defined as server = app.server.

When multiple workers run, multiple requests can be processed in parallel, enabling all of the graphs to update “at once”.

1 Like
#3

I am experiencing an oddly slow callback time now too. Switched from python 2.7, dash 0.34 to python 3.7, dash 0.39. In earlier version, updates 20 callback in less than a half second but now it takes 10-12 seconds. app.run_server set with threaded=True in both cases. I had to change a little code to get it working in 3.7 with dash 0.39 so not sure where the slow up occurred.

#4

updated to dash 0.42 : tested:
app.run_server set with threaded=True 12 secs
app.run_server set with threaded=False 6 secs
So setting threaded = True is no longer making it run faster like it use to; was there something changed that slows the local setup speed and threading?