On Aug 6, 5:07 pm, koranthala <koranth...@gmail.com> wrote:
> Hi,
> I am designing a website with Django and Apache. This is my first
> foray to web designing, even though I have quite a bit of experience
> in another area.
> The logic for the site is somewhat involved - It is better to think
> of it as more of an application rather than a site.
> The problem is as follows:
> On an average, every GET query for the home page takes about 400 DB
> Queries. I am now running it in my personal machine, with the Apache
> and PostgreSQL DB all running in my machine itself. Here, it takes
> around 5 seconds to complete a GET query. Please note that have used
> the select_related etc quite liberally.
> I feel that the query count is too high. I earlier tried to solve
> it using memoization - wherein the query count came down to ~100, but
> since I have moved from development server to Apache, I removed it
> since I had written a thread-unsafe memoization.
> One of the reasons the query count is this high is because of the
> high modularization - I reuse many code again and again, so each code
> tries to get the data again. One way I can think of improving
> performance is by destroying the modularization. But that would be my
> last choice.
>
> Since this is my first application, could you please let me know
> whether this is too high?
> Should I try to improve the memoization code - say using a memoized
> data passed all over?
>
> What are the other ways to improve the performance?
>
> TIA
> K
How long is a piece of string? How many is too many depends on your
hardware, the rest of your stack (are you caching the page?), the
expectations of your users (if they're internal they might not mind a
slow page render), and all sorts of things.
400 queries *is* high, but we have a high-traffic website with a very
complex home page that has a similar query count. That said, I've been
spending a lot of time on it to reduce that, and have a version in
development which renders the same page in about 80 queries - quite an
improvement. I guess I've been using similar techniques to you -
memoization of complex queries within model instances.
In my experience there isn't any issue with thread safety. As long as
you're keeping it within a specific instance, there's no reason to
think it should be unsafe. For example:
class MyModel(models.Model):
....
def get_complexquery(self):
if not hasattr(self, '_complexquery'):
self._complexquery = do_complex_stuff()
return self._complexquery
Now the value of '_complexquery' is stored solely within the model
instance, which is created within the context of a specific request
and discarded at the end. No doubt someone will correct me, but I
can't see how that would be thread-unsafe.
There are various other optimisations that can be done - judicious use
of select_related can work wonders, for example - and of course you
can always fall back on raw SQL if there's really no way of expressing
a multiply-joined query within the ORM.
--
DR.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
