I hate mysql, that simple. And I think it's a real waste of resources to run a full db for something of this nature. This isn't like normal bulliten board software. Content on the boards isn't dynamic at all, once it's posted it doesn't change.

The only time the pages need to update, is when a new post is made, or one is removed. And even when that happens, there's at the most, a change to a thread, and to some of the main page indexes.

There's only 6 different kinds of posts.

1) Post is to an existing thread on the first page, and isn't a sage post, only the thread and the first page need to be rebuilt
2) Post is to an existing thread not on the first page and isn't a sage post, only the thread and the pages from the front back to where that thread was originally located need rebuilt
3) Post is to an existing thread and is a sage post, only the thread and the page the thread is on needs updating
6) Making a new thread, new thread needs to be generated, and all page indexes rebuilt
5) Deleting a post, only the thread and the page the thread is on need adjusted
6) Deleting an entire thread, all page indexes from where the thread was on back need to be rebuilt

The majority of posts occur in the first 3, new threads are uncommon, case 5 is usually an admin action, and case 6 is 99% of the time only done by admins.

But even then, new content isn't that common. On traditional boards the most common state is static, and static content is very easy to push around. Through my friend's (hihi pc486 :V) profiling of kareha, the majority of cpu time is being used by i/o operations. And the main source of that i/o is writing the caches.

After going through the code, kareha actually wastes a lot of time rebuilding threads when it doesn't have to. Also not storing individual posts and the shortened thread displays, wastes processing time as it has to completely strip the html from the thread, and then rebuild them as well as make the shortened version again. I think with adding a few additional cached items, the shortened threads for main page display, and the individual posts, and to follow those 6 cases and only do what's necessary, I think a flatfile system can compete with a db-based board in most cases.

Only advantages a db would give is ease of programming, less disk space taken up since there's no need to cache as much data, and the flatfile system will become very i/o bound on heavy traffic boards. I'm aiming for ease of installation and matinence, and to enable the script to be run nearly anywhere perl and some diskspace is available. Along with being built from the ground up with image loadbalancing capabilities, it'll make it very easy to scale the boards as traffic grows.

If I were programming just for myself, I'd probably just go python or ruby and postgres and not worry about ease of installation or operation. But I'm aiming to expand on the initial concept and utility provided by kareha, and make a capable and more powerful successor, while keeping the ease of use and matinence with a flatfile system.