Re: Struggling with slow startup / SQL in new app (using raw SQL)

Yes, local app, local DB (which is an exact copy of the production DB). Interestingly, I just tried pointing the local app at the remote database and total query time (for 10 queries) went from 115ms to 3477ms! Really odd. On Tuesday, January 22, 2013 7:54:53 PM UTC, Nikolas Stevenson-Molnar

Re: Struggling with slow startup / SQL in new app (using raw SQL)

When running locally, are you also using a local database instance? IIRC the time that phpMyAdmin reports is the time taken for the database to execute the query, whereas the time reported by the debug toolbar (I /think/) is complete round-trip (send query, execute, return results). So if there is

Re: Struggling with slow startup / SQL in new app (using raw SQL)

Hi Nik, I see the discrepancy both locally and when deployed, too -- that's what's so puzzling. If it helps, I'm using MySQL and running it on Windows locally and under Passenger on my remote Linux server (also on MySQL). Only other thing I can think of is that this "overhead" might literally

Re: Struggling with slow startup / SQL in new app (using raw SQL)

Hi Matt, It's unlikely the problem lies with dictfetchall. The "small performance hit" mentioned by the docs probably refers to the fact that the function has a time complexity of (number of colulmns) * (number of rows). Since you're only getting 10 rows back, I can't see that having an

Re: Struggling with slow startup / SQL in new app (using raw SQL)

That looks really useful - for future reference, great! Sadly my webhost is still bundling Django 1.2.3 :( In general, though, these issues still come down to the fact that a SQL query as executed by Django takes several times longer than going directly to the DB. Is this down to my use of

Re: Struggling with slow startup / SQL in new app (using raw SQL)

Hi, I see that you had quite a bunch of m2m keys. Have you tried recent version of Django (1.4+) with prefetch_related() [1] ? [1] 22.1.2013 13:57, Matt Andrews kirjoitti: Hi Jani, I made a StackOverflow post

Re: Struggling with slow startup / SQL in new app (using raw SQL)

Hi Jani, I made a StackOverflow post last year with an example of the ORM stuff I tried and the poor queries it produced: http://stackoverflow.com/questions/5843457/django-objects-all-making-360-queries-how-can-i-optimise-this-manytomany There's also this discussion about how using the same

Re: Struggling with slow startup / SQL in new app (using raw SQL)

Hi, From your raw SQL I saw you're doing few joins. So I suppose you do quite a few foreign key fetches. You didn't mention anything how you originally tried to solve case with ORM. Could you please publish what you had when things were slow? 22.1.2013 12:26, Matt Andrews kirjoitti: Hi

Re: Struggling with slow startup / SQL in new app (using raw SQL)

Hi Nik, Thanks - I do feel like by circumventing the ORM I've just "given up" and perhaps I'll reconsider -- none of my queries are particularly "specialist" (as the sample above indicates) - I just found Django generating odd things. To answer your questions: 1. Yes, reloading the page sees

Re: Struggling with slow startup / SQL in new app (using raw SQL)

Hi Matt, Firstly, I encourage you to have another crack a the ORM. It can certainly seem a bit aggravating at times if you're coming from a SQL mindset, but really pays off down the road in terms of maintainability and readability. Typically you should only need raw queries in Django in cases

Struggling with slow startup / SQL in new app (using raw SQL)

Hi all, Fairly new to Django. I ended up pulling out all of the ORM-generated queries and writing my own SQL directly (I got fed up trying to work out how to achieve the kind of things I needed without Django adding in extra joins or unintended WHERE clauses etc). All my app's SQL uses