The Django Debug Toolbar is a powerful and useful tool for identifying potential trouble spots in your Django application. Hopefully, this post will serve as a starting point for understanding the information presented by the toolbar. Also, we will cover a couple of plugins for the toolbar, cache panel, and template timings.
Installation will not be covered here as the installation instructions provided in the project’s documentation are straightforward, but links will be provided to the various installation instructions:
- Debug Toolbar: https://github.com/django-debug-toolbar/django-debug-toolbar
- Cache Panel: https://github.com/lincolnloop/django-cache-panel
- Template Timings: https://github.com/orf/django-debug-toolbar-template-timings
This section gives information about some of the packages installed. This can be useful for checking if something is up-to-date.
This gives some information about how long a request took to process. There is an excellent write-up of what these timing values mean in this Stack Overflow article. Basically, this area can provide some information about whether problems appear in code you’ve written or in something that your code has called.
This setting is just a listing of items in your settings file. It’s nice as a quick reference and does some things to hide some sensitive settings.
Here is HTTP Header information. This hasn’t been very useful for me, but might provide something useful if your project is concerned about this information.
This provides information about values inside cookies, GET/POST variables, session variables, and arguments and keyword arguments passed to the view function.
This section provides information on what templates were rendered and with what context. This is useful if something is rendering with an unexpected value. Also, this displays the exact values provided by all of the context processors registered in your project.
This is probably the most useful part of the debug toolbar. If you are experiencing performance issues, SQL is often the culprit. Here you get information about every SQL query performed, including the full SQL statement executed passed along to the database, where the database call occurred, a timeline of the order in which all the SQL queries were evaluated, and how long the SQL took to run. Having a large amount of SQL queries or some queries that take much longer to evaluate is a red flag for performance.
This is just a listing of various signals registered in the application and what is listening for those signals to fire.
Some log related messages if logging is configured to do this.
This panel appears because we installed cache_panel earlier. The cache panel adds similar information as the SQL section except about cache calls made in your request. Most of this information is straightforward. What is nice to see is the number of cache hits and misses. Cache misses can be bad because not only have you made a fruitless request, you also must now evaluate and set the value in the cache. Depending on what you are doing, this can increase the time of your request substantially.
This panel is available because we installed django_template_timings_panel. Template timings gives information on how long templates take to render, the number of times a template was rendered during this request, SQL queries made on a per template basis, and the same information broken down to a block level. If you are rendering several templates, either via template inheritance or includes, this can provide very important information. I’ve seen a couple of instances where some bad structuring of template inheritance and includes has increased the load time of a page by a large margin. What is also important to note is the number of queries performed inside of template rendering. You should aim to avoid making query requests inside of the template as much as possible.
Phew! Django Debug Toolbar provides a plethora of helpful and insightful metrics. While this isn’t the only tool you will ever need, it certainly is an excellent way to get started.