All a database is is a bunch of flat files with a bunch of double hash tables on top of it for quicker searching, sorting, etc. So either way, you’re still reading the comment from disk and therefore hitting your main bottleneck — disk seek time and disk I/O. Except now your excluding yourself from nice things like query caching and stuff, which can minimize disk usage.

The only time that this would be applicable was if you were doing an insane amount of writes on myISAM (or similar) tables, which lock the entire table whenever it’s getting written to, meaning no one could read from the table easily. And in this case, I’d just say go to a better table style, like InnoDB. =)

Unless you’re storing your comments in CLOBs inside MySql. In my experience they’re f*&^ed up performance-wise and need some fixing. In this case, I’d say yeah, this would be a good workaround until those bugs in MySql are fixed.

I was thinking about a possible idea on that in terms of limiting the DB doing work, and putting the strain on Apache instead.

Store each comment as its own flat file. The database will hold the name of the file, but not the comment itself. When the application requests a page, it goes to the database to get the names of the files for the comments, and it will request it as a series of server-side includes.

I did this for my archived site here:
http://www.tangotiger.net/archives/stud0141.shtml

Each of those comments you see on that webpage is stored as its own file. If you were to see the actual source code for the page, it would be almost entirely a series of include statements.

mysql optimization is a waste of time. it isnt going to save you any more resources in your time than hardware resources

My counter-argument to that is that on Day 1, USSM was essentially unusable under extreme load and on Day 2, after I turned on query caching, making some reasonable guesses about settings, it was perfectly usable all day long under the same request load.

If I can do something like that and it saves us from having to buy another $2000 server, that’s worth doing.

Except that WP has to do exactly the same work to regenerate the page, and it’s doing it for every request. A far better design for a middleware layer (call it X — Wordpress, Movable Type, whatever):
1. Page is first requested
2. X queries the db and generates the page
3. The page is cached somewhere and Apache serves it
Now every subsequent user agent that requests the page gets the cached version from Apache, with no db hit or middleware work required

When a user submits a comment, the cached version is thrown out and a new page is regenerated to be sent down to the submitter. That page goes into the cache for all subsequent requests

I know nothing about MT or WP, but it sounds like MT does this the right way — the work is only done when there’s a write, not when there’s a read.

How is it for everyone else?