By the way, the design of putting templates in the database is pretty bad for usability.

Well, it is Slash we're talking about here :) Their design isn't perhaps as bad as it seems. The templates live on the filesystem, but after editing you run a tool to compile them, as Perl, into the database. They do this for speed. I haven't benchmarked it, so can't say if it works.

What really sucks about this is that each Apache/mod_perl child process caches all the templates, so if you make a minor change to a template you have to bounce Apache, or at least kill all its children.

Reading a file on a local filesystem is faster than reading from a database. Maybe they did it that way so they could share code between machines, but that's better done with NFS or rsync in my opinion. The compile step sounds annoying, as does having to restart when changes happen.

When templates live on the filesystem, changes can be automatically picked up by the running system just by stat'ing the file. That could be turned into a database check in their custom Provider class, but I suspect they did this to keep shared memory high. In my experience though, compiling the templates before forking didn't really decrease the amount of unshared memory.

The ultimate point, I think, is the caching of the templates in memory. As for storage ... access from multiple servers certainly is an issue. I can think of reasons for or against it, but until I've benchmarked a few solutions in a serious environment (few million hits a day) I don't want to out-guess them.

Either way, you don't have to sell me on the inconveniences of the system. Nearly every design decision in Slash is sacrificing something, often ease of use or development, in the name of speed or security. Not the way I would do it at all. A couple extra web server machines are a lot cheaper than developer time in the long run.