Some thoughts:
Generally speaking, the problem of database connections is
solved with connection pooling -- Bricolage implements a
connection pooling scheme as do most decent web applications
that require database access. If you find yourself having
so much traffic that you're running out of connections or
overwhelming your database server... congratulations!!! sell
more advertising on the site and buy more servers 
In terms of caching, you could use a third party caching
solution like Akamai or Cachefly, or roll your own. I've
never used it, but maybe mod_cache for Apache would work? I
dunno.
You could perhaps integrate Bricolage publishing (via your
templates) with your caching solution so that when you
publish a page, you toggle a flag associated with a URL (or
pattern of URLs, or story id, or whatever) to trigger the
caching mechanism to pull and cache a refreshed page from
the origin server.
________________________________
From: John Durkin [mailto:john.durkin gmail.com]
Sent: Tue 9/18/2007 7:16 PM
To: userslists.bricolage.cc
Subject: Re: publish_another - how is the user / scheduler
determined?
This is all very interesting. We're seriously considering
making all the
articles have 2 oc's -> one which produces the static
article page (the
"permalink" page), and one which produces a
"post.inc" file in the same
directory. One of the templates for articles will access
our live mysql db
and enter a row in an "articles" table (contains
url, cover_date and
references to tags) and a row in a "tag" table
(for each tag that isn't yet
in there). Then, we'll make a single static page that takes
url parameters
to construct a query to a mysql db, fetching the urls of
stories that match
the tag page being accessed - or if it's just the home page
it will fetch
the most recent posts regardless of tags.
This will certainly speed up publishing... but my concern is
making a db
connection and query to mysql every single time a visitor
loads a page. I
know that wordpress implements a kind of caching output so
that this problem
is alleviated. I've been reading this article which is
helpful:
http://jpi
pes.com/index.php?/archives/99-MySQL-Connection-Management-i
n-PHP-How-Not-To-Do-Things.html=
Does anyone have any thoughts on this problem? The fact
that bric produces
"static" pages is often touted as one of its great
advantages (which I still
am convinced of... ) - but we have over 5000 tag pages now,
and - well - the
time it takes to publish a story is growing longer all the
time. Maybe a
caching solution would do the trick. I'm just not sure
about the best way
to implement the caching in order to relieve the constant
and often
unnecessary connections to the mysql db.
JD
On 9/18/07, David E. Wheeler <davidkineticode.com> wrote:
>
> On Sep 18, 2007, at 04:23, Beaudet, David P. wrote:
>
> > Are you using the "story.category"
parameter in any of your story-
> > >list() functions? If so, there's a
performance issue with that
> > particular parameter as it's not well-optimized by
postGRES --
> > you're much better off rewriting your list() to
fetch all the
> > categories from the story first, then passing the
categories via
> > the ANY parameter to list()...
>
> What performance issue?
>
> > Also, it might be worthwhile issuing a bunch of
perl warns in your
> > template to figure out how many times each
individual page is
> > getting published during the burn to make sure
you're not
> > needlessly republishing the same story over and
over again during a
> > single burn operation (since you're using
publish_another....)
>
> Looking forward to your reworking of my patch to fix
this, David. ;-P
>
> David
>
|