The SQL query time isn't that slow, but something definitely is. Especially
if it's happening on every page. The function that's really taking all that
time is precompute_objects. It does the following:

1) Builds a list of fields to sort in order, which will be used in the SQL
query (this is fairly simple and shouldn't be slow)

2) Builds a paginator, which is just a simple object used to increment the
offset in the query. Also simple, part of Django, and used in lots of
installs.

3) Fetches the list of IDs for the objects that will be shown in the
dashboard.

4) Takes those IDs and uses them to get the actual objects in one batch.

5) Renders them (the logs show this to not be taking a lot of time).

So basically, some simple logic to split a string and stuff it into a
dictionary (which will at most have 2 items, and usually 0 or 1), perform
the query (which the logs say are actually fairly quick, once the database
connection is established), and then render it (which the logs say are also
quick). So I can't imagine it being anything other than the PostgreSQL
configuration.

Can you verify that the settings_local.py in Review Board and the
settings.py in other Django sites are using the exact same database backend?

Are all the sites running on the same server?

The logs you provided show a lag of ~2 seconds rather than 8, though. If
you're seeing 8 from your end, but the logs are showing 2, then there's a
whole different issue happening, but I'm assuming it just varies on attempt
and page.

Christian

-- 
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com


On Mon, Jul 19, 2010 at 12:04 PM, Stephen Gallagher <
step...@gallagherhome.com> wrote:

> On 07/19/2010 03:00 PM, Christian Hammond wrote:
> > Hi Stephen,
> >
> > Sorry, I missed the e-mail where you attached the profile log. I'm
> > looking through it now.
> >
> > The render_to_response was misleading. The slowdown is actually within
> > precompute_objects, which does some database queries. That primarily
> > does database queries, but the SQL logs show that they're not taking
> > very long individually. Certainly not a total of 2 seconds. The
> > rendering doesn't appear to be the slow part either.
> >
> > I don't know much about PostgreSQL, but it almost sounds like there's
> > some issue in the configuration or something. If there's a delay in
> > talking to the database (locking? bad connection?) then I could see
> > that causing this. The low SQL query time is interesting. That makes
> > me wonder if it's just an issue in establishing the first connection.
>
> Well, the problem is that I'm seeing a lag of about 8 seconds for every
> page load. I can't imagine the SQL query time being that slow...
> Furthermore, there are other Django-based web applications talking to
> this same database server without any obvious performance issues.
> (Specifically, it's a Transifex instance, so it's low-traffic. That
> wouldn't be wasting DB time).
>
> --
> Want to help the Review Board project? Donate today at
> http://www.reviewboard.org/donate/
> Happy user? Let us know at http://www.reviewboard.org/users/
> -~----------~----~----~----~------~----~------~--~---
> To unsubscribe from this group, send email to
> reviewboard+unsubscr...@googlegroups.com<reviewboard%2bunsubscr...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/reviewboard?hl=en
>

-- 
Want to help the Review Board project? Donate today at 
http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~----------~----~----~----~------~----~------~--~---
To unsubscribe from this group, send email to 
reviewboard+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/reviewboard?hl=en

Reply via email to