waldo at vqronline
Apr 21, 2008, 1:48 PM
Post #2 of 6
(292 views)
Permalink
|
Folks,
To spare anybody else the trouble, I think I've figured out my own
problem.
I've been going through and correcting all of the names that didn't
import quite right (accented characters, en dashes, etc.), which
requires listing out all 1,800 contributors. That means that, after
each POST of the changes, Bricolage needs to return the list of 1,800
contributors. Now, there's just no reason why it should take 60-90
seconds to pull 1,800 rows out of Postgres, but if I'm working on only
a subset (say, only those with the last name "Smith") there's only
perhaps a 5-10 second delay after submitting changes to a
contributor's record.
The solution is simply not to list all contributors in one fell swoop
and, if you do, expect it to be slow. There are worse things.
Best,
Waldo
On Apr 21, 2008, at 3:56 PM, Waldo Jaquith wrote:
> Folks,
>
> This afternoon I imported 1,800 authors into Bricolage. The formerly
> snappy Admin->Publishing->Contributors section immediately became
> sluggish in all interactions with it. Simply creating a new author
> record requires a 60-90 delay for the insertion. Checking out the
> server processes, I found that Postgres is eating up 97-99% of the
> CPU cycles during that period with its confusingly-named
> "postmaster" process.
>
> Postgres is installed solely for Bricolage -- it's not being
> accessed for any other purpose on this dedicated server -- and I'm
> the only here using Bricolage. I'm running PostgreSQL 7.4.17 and
> Bricolage 1.10.3. Some quality time reading through list archives
> doesn't yield anything that would seem to explain this.
>
> Being a MySQL guy, I have no idea of how to delve into things to
> make sure that everything is indexed properly, not crufty, etc., but
> my assumption is that Bricolage would take care of all of this on
> its own. Is this a known problem with Bricolage, a result of a large
> number of contributors, or maybe a known problem with PostgreSQL?
>
> Best,
> Waldo
|
