Static HTML is several orders of magnitude faster, in general. Some folks did some fairly simple benchmarks of a bunch of dynamic content generation systems. Now, I'd include all of the standard disclaimers about benchmarks and their validity, but it's clear that there's an order of magnitude difference between the mod_cgi results (9.2 hits / second with CGI.pm) and the static HTML (1148.1 hits / second!).

All in all, static pages are your friends if you can get away with them. Be wary, however, of the increased maintenance and tweaking cost as tilly points out.

 
perl -e 'print "I love $^X$\"$]!$/"#$&V"+@( NO CARRIER'

Static HTML is far better because you can unleash things like the kernel web server, which has been clocked at more then 2 times faster than Apache (the kernel server only serves static pages). Then there are the benefits of caching, etc.

____________________
Jeremy
I didn't believe in evil until I dated it.

Actually there are other concerns. A lot of them.

The first and simplest is that having a batch process update pages is less maintainable. Someone can accidentally remove or break the process, not knowing what it does, and 6 weeks later you find out that there is a problem with the page, but have no clue how it was supposed to work, and there is no obvious trail back to how it was supposed to be generated. As the mantra goes, premature optimization is usually wrong.

A closely related second issue is the ease of testing and storage. It is inherently a faster and more accurate development cycle to edit a script and see feedback than it is to edit a batch process, have to run it, and then get feedback. Much experience indicates that developing with rapid feedback leads to faster and better development than developing without it. (All else being equal of course.)

Third we have the issue of amount of storage. Often to replace a single dynamic page you have to create multiple static pages. This can quickly result in a combinatorial explosion of pages, eventually leading to problems with storage that make it much saner just to have a dynamic page in the first place.

And closely related to the ease of storage is the ease of adding further customizations. If you have a dynamic page and want to add another customization, it is easily done, just add it. If you have a batch process you have to consider whether or not to rewrite it to be a dynamic script to avoid the pain, or whether you will add more pages.

In short there are a lot of issues. But there are partial solutions out there. And several of the more advanced templating systems (eg Template::Toolkit and HTML::Mason) have put a fair amount of work into figuring out how to reasonably trade off static caching, dynamic caching, and on the fly pages.

Hmmm. I assumed that the questioner was worried that he could be caught by some technicality if he went static or dynamic, and answered to reassure him that the technology was good for both, but static was faster. I tend to focus on the technical issues in my answers and assume that the procedural problems have already been thought about - I guess I should start paying more attention to the other parts of implementation beyond "Can it be done".

Some of your points rely on assumptions you have made about the situation the petitioner is in - for instance the method used to create static pages. They are valid points, but you are raising issues for a problem that hasn't been defined yet. He hasn't told us what build process he is considering, or what devel cycles he wants to follow.

When we did our static pages site, we actually wrote the site dynamically, and used it for a bit. When we were happy with it, we ran wget over it to create the static site. To us, this seemed to be the best way to get more performance out of the hardware that we had, and it worked.

I know this particular strategy won't work in every case, but it was excellent for us because we got the best of both worlds - instant feedback and debugging, and the performance boost from static pages.

As to the storage issue - well, I assumed that the questioner could do the sums. If the static website is bigger than the disk (or than the memory buffers) then clearly dynamic is better.

Please excuse this 5am post, I just wanted to get it out before retiring for the morning.

____________________
Jeremy
I didn't believe in evil until I dated it.

If your data is dynamic, then I can see dynamically generating pages as they are requested. Give the most up-to-date data possible and reduce maintenance costs. If a change from static to dynamic data is possible, go with dynamic.

OTOH, if you data is static (manually updated at scheduled intervals), I don't see the need to dynamically generate the pages on request. Instead, as you suggest, it would probably be better to generate static pages as a batch job when you update the data files. When using static data you can be assured of queries from anxious users wanting to know why their data doesn't appear on the pages. You can try to head some of them off by documenting the update intervals up front.

I don't know if is true for you, but if you have to make manual adjustments to your files (as a stop gap measure between updates) the ease/difficulty/feasibility of that process should be considered as well.

I believe that your most significant gains here are probably not going to be in terms of performance. Especially if the pages (static or dynamic) are basically the same in size although content may vary slightly. Rather, they will come from ease of maintenance.

@a=split??,'just lose the ego and get involved!';
for(split??,'afqtw{|~'){print $a[ord($_)-97]}