Yeah, I thought about this option initially, but the system I'm creating uses a pretty complex templatting scheme and conditional output of pages. I use cron-created HTML on another system I built and it's pretty sweet, I just regenerate the HTML when there is a change to a document.

This project is a little more intense. I'm making it so that I can have multiple non-profits with multiple domain names, with different HTML templates, all share the same database of docs. Each program also has the ability to exclude documents based on specific properties (document type, subject matter, etc.) and has multiple access levels. This could quickly get into an absurd amount of static HTML pages, and I only have a T1 (for now. . .) to host it on. As long as I keep my page generation (in bits per second) above the speed of the T1, I think I'll be OK.

If it turns out down the road that I'm processor bound (I don't think it will) I'll revisit this option again.

You know one thing I do use is HTML::Clean, this module, at a slight cost of speed, about 2% in my testing, and at it's lowest level, gives me a 20-30% savings in total size of my HTML. It's worth it! I may look into the gzip option too, I have a post-processing sub I could easily plug this into.

-Any sufficiently advanced technology is
indistinguishable from doubletalk.