Skip to content

SQL Query Profiling #88

hypoxia opened this Issue Jul 7, 2010 · 2 comments

2 participants

hypoxia commented Jul 7, 2010

I think that I am getting inaccurate results using the toolbar's SQL profiling. Here are my results:

queryset patch: appending '.select_related('account__host', 'server')' to a queryset

Test #1 - Without queryset patch:
135 objects
Time: 2199ms
SQL: 395 queries in 62ms

Test #2 - With queryset patch:
135 objects
Time: 312 ms
SQL: 6 queries in 31 ms

dcramer's fork of django-debug-toolbar
Test #1 - Without queryset patch:
135 objects
Time: ~6570 ms (external profiling tool -- IE8)
SQL: 393 queries in 3667ms

Test #2 - With queryset patch:
135 objects
Time: 770 ms (external profiling tool -- IE8)
SQL: 4 queries in 31 ms

As you can see, the queryset patch has a huge impact on the amount of time required to render the page. Since its main effect should be the number of database queries and the time required to execute them, it seems reasonable that the SQL query time should go up. For this reason I am fairly confident that there is a problem with the most recent version of django-debug-toolbar's sql profiling.

Django 1.2
Python 2.6.5
IE8, Firefox 3.6.6
Windows 7

django-debug-toolbar member

It's not clear to me what you are saying... Based on your tests you are adding select_related, which results in SQL JOINs, thereby reducing the number of SQL queries and lowering the overall SQL time. This seems perfectly valid to me.

hypoxia commented Jul 12, 2010

I am questioning whether the SQL profiling is accurate or functionally designed. If you look at the results for django debug toolbar, you can see that the SQL time does indeed drop. As you mentioned, that makes sense. However, it drops by 30ms whereas the total time drops by over 1700ms. That does not make sense, at least as I understand things; somehow a simple change in SQL is resulting in a huge change in performance, and the reason why does not seem clear. With DCramer's old fork, though, the drop in page loading time is proportionate to the drop in SQL time. That makes a lot more sense to me, and is more functionally useful because the performance is a result of the SQL.

It might be a simple difference in methodology -- counting pure SQL time (as reported by SQL) vs counting time spent on SQL by Django. If that is the case, both might be accurate but I think that the latter option is more useful for developers: I saw a huge SQL time, fixed it, and now the page loads quickly. (EDIT:) This is something that might be missed with the current methodology because the SQL time seems insignificant.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.