There is one query in the list that happens twice and takes 0.352s on
average each time. That's the query to get the auth info from the Fedora
auth backend. I don't know why it'd be so slow, but it might also point to
an issue in talking to the database.
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com
On Mon, Jul 19, 2010 at 12:12 PM, Christian Hammond <chip...@chipx86.com>wrote:
> 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
> 3) Fetches the list of IDs for the objects that will be shown in the
> 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
> 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 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
>> Happy user? Let us know at http://www.reviewboard.org/users/
>> To unsubscribe from this group, send email to
>> For more options, visit this group at
Want to help the Review Board project? Donate today at
Happy user? Let us know at http://www.reviewboard.org/users/
To unsubscribe from this group, send email to
For more options, visit this group at