[Django] #32174: Error page can sometimes be very slow
Django
------------------------------------------------+------------------------
Reporter: boxed | Owner: (none)
Type: Cleanup/optimization | Status: new
Component: Error reporting | Version: 3.1
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
------------------------------------------------+------------------------
I hit a case in development today where the error page took over 20
seconds to render. After a bit of digging it happened for a few reasons:
- fairly deep call chain (20)
- the same arguments being passed down many levels
- those arguments contained querysets
- the querysets had reprs that accessed a related object
These things in combination resulted in almost 5000 database accesses.
I have a patch for this that can avoid this. It's pretty simple as the
debug pretty printer goes through the entire stack in one for loop so it's
easy to cache the sub-results.
--
Ticket URL: <https://code.djangoproject.com/ticket/32174>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: boxed | Owner: (none)
Type: | Status: closed
Cleanup/optimization |
Component: Error reporting | Version: 3.1
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* status: new => closed
* resolution: => wontfix
Comment:
Hi Anders. Thanks for the report.
Slowness here is a symptom of chained ORM lookups, rather than the
exception reporter per se. It's not something that we'd want to mask in
general, because you **want** to notice it, so you can optimize your
application.
If you do want to apply it yourself, your suggestion is the perfect case
for the [https://docs.djangoproject.com/en/3.1/ref/settings/#default-
exception-reporter DEFAULT_EXCEPTION_REPORTER] setting introduced in
Django 3.1. Apply your cached pretty printer in a subclass and use it in
your project.
I hope that makes sense.
--
Ticket URL: <https://code.djangoproject.com/ticket/32174#comment:1>
Django
Reporter: boxed | Owner: (none)
Type: | Status: closed
Cleanup/optimization |
Component: Error reporting | Version: 3.1
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by boxed):
I disagree. Optimizing queries with prefetch or select related can be done
later. You are saying that we should always apply optimizations first just
in case a debug page is hit.
In any case, if you don't like the fix, would you be open to a change that
would break apart the big function my PR modifies so that this change can
be implemented locally without copy pasting that big function (risking
compatibility problems, missed bug fixes etc)?
--
Ticket URL: <https://code.djangoproject.com/ticket/32174#comment:2>