My impression here is that the django-debug-toolbar wouldn't help here
though, because the issue wasn't with the request. It was during
initialization of the gunicorn processes.
You can have logging.debug at function enter/exit points, so that you
can switch to that log level if necessary (or, I suppose, a function
decorator that does that). It is always fairly easy to come up with the
proper logging to discover the problems that you've already experienced
though. Another potential solution would be a larger database during
testing, which probably would have created the same issue (so you would
have noticed it at that phase).
Perhaps your development database could be a copy of some realistic
state (at least size-wise) of your production database?
I would love to see an article/blog post/documentation about "logging
best practices and why" focused on django, but I haven't come across one
yet.
Hope this helps,
Casey
On 10/21/2011 03:15 PM, Javier Guerra Giraldez wrote:
On Fri, Oct 21, 2011 at 2:08 PM, Shawn Milochik<sh...@milochik.com> wrote:
What's the best way to start looking for a problem like this? I
Django-debug-toolbar is the first line of defense (well, second. the
first is to use good algorithms). in the vast majority of cases, any
performance issue is because too many queries, or a single one that
linearly scans huge tables.
what i do is to check the number of queries performed by any request,
as soon as i have it working. if i see a repeated one, it's usually
tiem to rethink it.
then, i also check the EXPLAIN plan for the heaviest ones, and if the
view includes significant Python code, also the timing reports.
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
