Hi Arto, please be aware of this static file cache project we are planning to commit to Drupal 4.8.

http://drupal.org/node/45414

Please review the latest patches and respond on the issue.

You have missed a couple important design considerations. First most of the benefits of serving static pages come from avoiding Apache’s instatiation of a PHP thread which is around 20MB. Our file caching doesn’t handle this either.

The main benefit actually comes from avoiding loading Drupal to serve a page which your system doesn’t avoid. I’d argue the once you have loaded Drupal MySQL SQL cache if tuned is equivalent to a static file page being served from memory since the OS will cache file in memory.

In your performance tests with Siege you’ll find your results are likely skewed by the Drupal’s error pages which return a page that reports a DB connection failure in text rather than a legitimate HTTP error. That means siege, or other measuring tools, will treat failed pages as successful when doing heavy loads.

I strongly discourage testing on low powered hardware as Operating System performance and PHP/Apahce/MySQL resource consumption does not scale linearly. The result is that small limitations in hardware can be optimized but will be irrelavant in full-powered production servers where those resource constraints do not exist.

Colloboration on interface design and different levels of performance will be appreciated.

Thanks,
Kieran