On Sep 18, 2007, at 16:16, John Durkin wrote:
> 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.
I did a project that works very much like this. Can't
remember which
one, but it should work nicely.
> 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://jpipes.com/index.php?/archives/99-MySQL-Connect
ion-
> Management-in-PHP-How-Not-To-Do-Things.html=
There are all sorts of way to cache things. You could even
have your
publish expire the appropriate caches.
> 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.
Well, first off, try it using only MySQL's query caching. If
you then
experience issues, use memcached or something.
HTH,
David
|