[geeklog-devtalk] Optimizing MySQL (was: SPAM Article)

Richard S. Westmoreland richardsw at suscom.net
Thu Mar 3 15:15:44 EST 2005


----- Original Message -----
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devtalk at lists.geeklog.net>
Sent: Thursday, March 03, 2005 2:53 PM
Subject: [geeklog-devtalk] Optimizing MySQL (was: SPAM Article)



> Tony Bibbs wrote:

>

> >Optimizing MySQL is the place to start.

>

> Did I mention that I got "High Performance MySQL" for Christmas? ;-)

>

> Great book. I spent some time with the book over Geeklog's MySQL requests

> and I think we're doing quite good actually - not much room for

> improvement there, from what I can see.

>

>

> >There are a number of things

> >you can do there, most important - IMHO - is to turn on query caching.

>

> We tend to have quite a few requests that are created on the fly

> specifically for the current user, though, so that there's probably not a

> lot to cache.

>

> bye, Dirk


Get rid of all the user-custom stuff. Problem solved. ;-)

I have been spending a lot of time working with the template files because
I'm redesigning my theme from scratch. I can see why things were done the
way they were, and it probably grew more complicated over time. But I have
a feeling that the way the template files are parsed and put back together
may have a big impact on performance.

For example, you could combine all of the header/footer stuff into a single
template file. header.thml & footer.thml become page.thml. storybodytext
and storytext become storyblock. blockheader-left and blockfooter-left
become leftblock. And so on.

The parse-tags... the variables... whatever you call them (example:
{story_title}) - I'm not sure if only certain blocks can parse certain place
markers. But if it isn't this way already, with a consolidated template
file you only need to run the routine to parse the marker once, and only
those markers available to that block (to cut out redundant marker checks).

Maybe this is way over my head at the moment...

Rick

Rick





More information about the geeklog-devtalk mailing list