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 good
article witch talk about Postgres tuning also:
http://jacobian.org/writing/django-performance-tips/


On Jun 10, 8:56 pm, Stephen Gallagher <step...@gallagherhome.com>
wrote:
> 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 postgresql and whether there were any tuning tricks I should
> be aware of.
>
> On 06/10/2010 02:53 PM, Jan Koprowski wrote:
>
>
>
> > 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<step...@gallagherhome.com>
> > wrote:
>
> >> I'm curious, what database is thehttp://reviews.reviewboard.orgserver
> >> 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 4-8s per page
> >> when backed by Postgresql (on a private network with very little traffic).
>
> >> How is the performance when backed by MySQL?

-- 
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