dj-tracker VS django-debug-toolbar

I'd recommend dj-tracker. It can show you exactly which field your related queries come from and you'll easily be able to know when your N+1 problem is solved or not using the dashboard. See the Detect and resolve related queries page on the docs. (It comes with very little overhead compared to silk or debug-toolbar and it persists all the data in a database so you don't lose when you quit the server).

You could try dj-tracker. It'll help you detect N+1 or any related queries but also apply the deferring optimisation suggested by eysidi.

That was the little story for dj-tracker and here is what it can do in summary: - Keep track of all fields accessed (allowing to use only or defer when some fields aren't used - Keep track of all attributes accessed (it can then give you a hint to use .values or .values_list) - Show how effective a queryset's cache is (and provide hints on using the .iterator optimisation) - Show all related queries in the same section and where they come from (making it super easy to detect N+1 queries) - Detailed traceback, SQL and template information for each query - Everything is persisted in a database so you can see how your application performs over time

For these reasons and many others (we lose the data as soon as we quit the session, it only keeps track of queries inside a request/response cycle i.e not in a background job for example...), I started building an app (dj-tracker) that can give you various insights into your queries but also hints on how to optimize them.

Hmm, interesting. There is a Github action that builds wheels and uploads them to Pypi. That's why I didn't specify Cython in the project's dependencies. I guess I'll need to look at it more in-depth. I'll also update the documentation re urls.

The reason behind this splitting is that we can safely use packages and related settings only where we need. For example, this starter kit has the package django-debug-toolbar. This is only intended for your development environment and not for your production. This can be very risky if used in production because if your Django project encounters errors, all the debug info will be shown to the user which is a severe security risk. Similarly, for tracking errors in production, we're using Sentry which is not needed in our local environment since we already have django-debug-toolbar. For keeping these settings file separate so that they don't conflict with each other, the settings file is split for serving different environments.

django-debug-toolbar: https://github.com/jazzband/django-debug-toolbar

https://github.com/jazzband/django-debug-toolbar/issues?q=is%3Aopen+is%3Aissue+label%3ABug

https://github.com/jazzband/django-debug-toolbar Allows you to check which sql queries are being run on your app. See if they are optimized first.

Perhaps try the django-debug-toolbar. It might be able to tell you what is causing the slow load time.

I would start with https://github.com/jazzband/django-debug-toolbar and figure out what causes the slowness.

-> The debugging above from django-debug-toolbar

Documentation, including installation and configuration instructions, is available at https://django-debug-toolbar.readthedocs.io/.