On 21 elo, 19:04, ydjango <[email protected]> wrote: > Thank you Paul. I will use those tools. > > I also plan to replace to some ORM queries by raw sql to avoid performance > impact of cloning and multi db enhancements.
If you can, please try to pinpoint the reason for regressions, and if it seems to be in Django's ORM, then post to django-developers or create a ticket in Django's trac. If there is some major regressions in the ORM it would be very valuable to know about them. Some possible explanations: - The DB configuration isn't exactly as it was before. - The ORM generates different query strings leading to slow query plans. - Using F() expressions and long filter chains can lead to slow queryset .clone() speed (see https://code.djangoproject.com/ticket/16759) You can try to pinpoint these by: - Checking if the generated SQL is the same between 1.1 and 1.3 by using qs.query.as_str() in 1.1 and str(qs.query) in 1.3. - Check if the generation of the queryset takes too much time. Easiest way is to generate a dummy script which does something like this: from datetime import datetime start = datetime.now() for i in range(0, 100): # Do not execute the query, just construct the queryset! qs = SomeModel.objects.filter(cond1).filter(cond2)... # Replace with problematic queryset from production. print datetime.now() - start And see if there are any meaningful differences. If the answer to the above is "no meaningful differences, the same SQL generated" then it is reasonable to suspect the DB configuration. - Anssi -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
