Re: ReviewBoard example instance

2010-07-19 Thread Stephen Gallagher
On 07/19/2010 03:12 PM, Christian Hammond wrote: > 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

Re: ReviewBoard example instance

2010-07-19 Thread Christian Hammond
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 -- Christian Hammond - chip...@

Re: ReviewBoard example instance

2010-07-19 Thread Christian Hammond
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 fairl

Re: ReviewBoard example instance

2010-07-19 Thread Stephen Gallagher
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 pri

Re: ReviewBoard example instance

2010-07-19 Thread Christian Hammond
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: ReviewBoard example instance

2010-07-19 Thread Stephen Gallagher
On 07/08/2010 07:17 AM, Stephen Gallagher wrote: > On 07/07/2010 06:04 PM, Christian Hammond wrote: > >> Do you happen to have the raw profiling log file too? I want to see >> the SQL queries as well. >> >> There were some heavy optimizations made in Djblets for the datagrid >> rendering, but I'

Re: ReviewBoard example instance

2010-07-07 Thread Christian Hammond
Do you happen to have the raw profiling log file too? I want to see the SQL queries as well. There were some heavy optimizations made in Djblets for the datagrid rendering, but I'm not sure if all that made it into beta 2 or not. Christian -- Christian Hammond - chip...@chipx86.com Review Board

Re: ReviewBoard example instance

2010-07-07 Thread Stephen Gallagher
On 06/12/2010 03:39 AM, Christian Hammond wrote: > Hmm, it might be due to not having cProfile installed? Does the > reviewboard.log show anything? > > Christian > > -- > Christian Hammond - chip...@chipx86.com > Review Board - http://www.reviewboard.org > VMware, Inc.

Re: ReviewBoard example instance

2010-06-12 Thread Christian Hammond
Hmm, it might be due to not having cProfile installed? Does the reviewboard.log show anything? Christian -- Christian Hammond - chip...@chipx86.com Review Board - http://www.reviewboard.org VMware, Inc. - http://www.vmware.com On Fri, Jun 11, 2010 at 1:30 PM, Stephen Gallagher < step...@gallag

Re: ReviewBoard example instance

2010-06-11 Thread Stephen Gallagher
On 06/10/2010 03:24 PM, Christian Hammond wrote: Hi Stephen, We're running on MySQL. I don't know why you'd be seeing such a huge delay with PostgreSQL though. Can you tell me which pages are showing delays? (Is it all of them?) if it's the dashboard, there are some known slowdowns when reac

Re: ReviewBoard example instance

2010-06-10 Thread David Trowbridge
The reviews.reviewboard.org server is running under mysql. We've done a little tuning but not much. I haven't tried with pgsql at all, personally. -David On Jun 10, 2010, at 11:56 AM, Stephen Gallagher > wrote: Well, right now 4-8s for a page refresh is just barely within the tolerable l

Re: ReviewBoard example instance

2010-06-10 Thread Jan Koprowski
You can check Your efficient of memcached caching. This could be critical. Read about getting statistic from memcached: http://code.sixapart.com/svn/memcached/trunk/server/doc/protocol.txt this is the fastest element of ReviewBoard. If You still belive this is database engine bottle neck here is go

Re: ReviewBoard example instance

2010-06-10 Thread Stephen Gallagher
On 06/10/2010 03:24 PM, Christian Hammond wrote: Hi Stephen, We're running on MySQL. I don't know why you'd be seeing such a huge delay with PostgreSQL though. Can you tell me which pages are showing delays? (Is it all of them?) Yeah, it's every page but the login page. That includes the adm

Re: ReviewBoard example instance

2010-06-10 Thread Christian Hammond
Hi Stephen, We're running on MySQL. I don't know why you'd be seeing such a huge delay with PostgreSQL though. Can you tell me which pages are showing delays? (Is it all of them?) if it's the dashboard, there are some known slowdowns when reaching large numbers of review requests. If the diff vie

Re: ReviewBoard example instance

2010-06-10 Thread Stephen Gallagher
Well, right now 4-8s for a page refresh is just barely within the tolerable limits of my users. I'm trying to determine whether it makes more sense to migrate to MySQL (if it would be better performance) I was also curious whether ReviewBoard's reference implementation was running on postgresq

Re: ReviewBoard example instance

2010-06-10 Thread Jan Koprowski
It is probably between SQLite and PostgreSQL. But this is delay is proportional to scalable. SQLite is not scalable at all, PostgreSQL is most scalable free SQL database. On Jun 9, 9:39 pm, Stephen Gallagher wrote: > I'm curious, what database is thehttp://reviews.reviewboard.orgserver > using? W

ReviewBoard example instance

2010-06-10 Thread Stephen Gallagher
I'm curious, what database is the http://reviews.reviewboard.org server using? We deployed on PostgreSQL recently, and I've noticed a distinct performance issue with it. I can only directly compare it to SQLite, but of course that's local access. But we went from < 1s responses on webpages to