Extremely long request time when RedirectsPanel is disabled

[maltebeckmann]

I returned to django-debug-toolbar after many years now that I am using cookiecutter-django. Awesome that it's still around!

I had extremely long loading times of ~25-30 sec/page load. When deactivating the toolbar, I got down to 1 sec. So the I tried disabling panels but to my surprise, when I activated all panels in DEBUG_TOOLBAR_PANELS list, it was all fine!

Then I realized there was a setting in DEBUG_TOOLBAR_CONFIG that appears to turn off RedirectsPanel by default:

DEBUG_TOOLBAR_CONFIG = {
"DISABLE_PANELS": ["debug_toolbar.panels.redirects.RedirectsPanel"],
"SHOW_TEMPLATE_CONTEXT": True,
}

Not sure this is a default or a default set by the cookiecutter-django team. Either way, when I comment out the DISABLE_PANELS line, i.e. bring the RedirectsPanel line back, the page loads in 2-3 sec, rather than 25-30 sec.

Any idea how that can be?

[matthiask]

That's very surprising. The redirects panel doesn't do that much: https://github.com/jazzband/django-debug-toolbar/blob/master/debug_toolbar/panels/redirects.py

I'm really not sure why this panel should slow down your page that much especially when no redirects happen at all.

[maltebeckmann]

Yes, it's very odd indeed. When I enable redirects, I get ~25 sec in the first run, all subsequent reloads come in at 7 sec. All significantly higher than the 0.9 sec when the redirects panel is enabled.

It's all in the request part ~ +7000ms.

[maltebeckmann]

Anything I can provide to allow for debugging? I can see why the redirect panel is off by default. I essentially run Django 3.0.5 with Django-CMS 3.7.2 in the cookiecutter-django wrapper.

[maltebeckmann]

After some more testing: If I

1. comment out 'debug_toolbar.panels.redirects.RedirectsPanel' in DEBUG_TOOLBAR_PANELS
2. leave all other panels in with DEBUG_TOOLBAR_PANELS
3. comment out "DISABLE_PANELS": ["debug_toolbar.panels.redirects.RedirectsPanel"],

Then all seems to be fine.

[snmishra]

1. comment out 'debug_toolbar.panels.redirects.RedirectsPanel' in DEBUG_TOOLBAR_PANELS
2. leave all other panels in with DEBUG_TOOLBAR_PANELS
3. comment out "DISABLE_PANELS": ["debug_toolbar.panels.redirects.RedirectsPanel"],

This improved request time for me, but DJDT still causes causes a latency of about 4s. Fortunately disabling SQL panel from the toolbar itself cuts the time down to <1s.

[mgibeau]

I encountered this issue as well, I noticed that even using an empty DISABLE_PANELS: [] in the DEBUG_TOOLBAR_CONFIG makes the requests 20x slower.

[tim-schilling]

V3 of the toolbar will still run parts of the analysis regardless if panels are enabled. That's something that can be changed, but in the mean time, designing applications so that you can enabled/disable the toolbar as needed is probably best.

[pembo13]

I've just submitted #1394. Same symptom, seemingly different cause, but may be related.

[ahmedaljawahiry]

Just stumbled on this - removing DEBUG_TOOLBAR_CONFIG results in huge speedup time for me. For weeks I just assumed that the slow load times were due to a completely unrelated Docker for Mac issue 🤦

[webjunkie]

Whoa for me as well, removing config did the trick 🤪

[briang1]

Removing config also resolved issue for me.

[xjlin0]

For me when I turn debug=True, remove config does not work, but add a callback function works and make Django fast again

DEBUG_TOOLBAR_CONFIG = {
    'SHOW_TOOLBAR_CALLBACK': lambda r: False,  # disables it
    # '...
}

[tim-schilling]

@xjlin0 You should avoid installing the debug toolbar app & middleware at all rather than disabling it via the callback. The toolbar is not meant for production usage and that pattern implies you're still using the toolbar's middleware in a production environment.

@ahmedaljawahiry @webjunkie @briang1 I'm a bit late on this, but what were your previous configs before removing them entirely?

[briang1]

@tim-schilling I had the following:

DEBUG_TOOLBAR_CONFIG = {
    'INTERCEPT_REDIRECTS': False
}

[tim-schilling]

Anyone who has commented on this saying removing the redirect panel fixed this for them, can you let me know (if you remember) what view(s) and flows this slowdown occurred for? I can't reproduce this in the example app.