Sounds about right to me.  We should probably also provide a way for modules to indicate cache expiration time.  The expiration time for the page should be computed as the earliest expiration time of any module on the page.  As an example consider a blog module which displays a calendar.  Strictly speaking, a page containing that module should not be cached past midnight.

On a related note, you might want to look into techniques to reduce the overall size of pages.  The mojoportal.com homepage currently weighs in at about 100Kbytes (not counting external files like images, styles, etc).  Since your earlier benchmarks seem to imply that about 80% of time is spent just sending bytes to the browser, anything we could do to reduce page sizes could have a large impact on performance.  For comparison if I convert the HTML to plain text, the resulting size is only 18Kbytes.  So, roughly speaking,  we are sending 100Kbytes of HTML to display 18Kbytes of text.  Looking at the HTML source the 2 things that jumped out at me were 1) ViewState accounts for about 7700 bytes, and 2) the HTML for the calendar accounts for over 15KBytes.  The calendar size could be reduced alot by eliminating the inline styles.  Inline styles are taking up a lot of space elsewhere on the page too.  It wouldn't suprise me if you could get a 20% performance increase just by trimming some of these kinds of fat.

The "after an update we touch the file and that raises the callback" scheme is good but it won't address content that just goes stale at some point in time even if there is no update (e.g. the day that is highlighted on the blog calendar).  Also, touching a file would work fine in a single server environment but might not work in a web farm.  There are a couple ways to address that, but I thought it was worth mentioning...

Initial load is definitely a concern.  Couldn't you load the necessary information on demand instead of loading it all in response to the first request?  I think I'm basically just suggesting that you cache the business objects...

what other circumstances [that might change a module's output] are you thinking of?

I can think of several other types of modules whose output would change even without a DB update.  Consider an RSS aggregator, a stock ticker, a quote of the day, weather forecast, or more generally a front-end to some sort of web service.

How long do you think we should cache things?

Assuming we can limit total cache memory usage via the web.config, I think we should cache things until we know they will be invalid.  But force the browser to revalidate so that the user always sees the latest version.

SiteModuleControl is a web UserControl.
Unless you really mean Module.cs business class which will be managed inside SiteSettings,

I meant SiteModuleControl not Module.cs.  I originally thought that you could put all the output caching logic in the business objects, but then I realized that if you want developers to be able to add their own modules, you can't assume that such modules will generate the same HTML for a given set of business objects.  A very common case would be a module that generates different HTML depending on the User-Agent header.  You could also have a module that displays the user's IP address, or more likely, uses it to determine the user's physical location so that content can be better targeted at them.

The bottom line is that if you are caching the output of a SiteModuleControl, the SiteModuleControl needs to have some control over that caching.  Output caching is intrinsically a presentation layer activity, so the logic controlling it belongs in that layer.

this seems just as expensive as not caching,

I suspect not because I think the bulk of the CPU is spent rendering and sending the page to the browser, not instantiating and configuring the SiteModuleControl objects.  One easy way to test this hypothesis would be to measure the performance impact of duplicating the "foreach (Module module in siteSettings.ActivePage.Modules)" loop in Default.aspx.cs (removing the added controls after the first loop completes).

if we have to do that I think we should skip the page output cache and just stick with the module cache where we can currently specify different cache times per module.

For the record, I have no problem skipping output caching.  In fact, I think you should rerun your tests of the benefits of module caching with a more simultaneous browser connections.  You might find that even module caching doesn't buy as much as we thought.  I suspect that the 2 performance bottlenecks are DB I/O and the CPU cycles required to send a rendered page to the browser.  DB I/O might actually not be that big of an issue since the DB isn't that large and doesn't see many writes.  That would mean that the primary way to improve performance would be to reduce the number of bytes sent to the browser.  There are only 2 ways to do that.  The first is to trim the fat in the HTML.  The second is to cache on the browser (or someplace other than the server).

Repeatedly double num browser sessions up until server cpu pegs at 100% or "average time until first byte" roughly doubles.  That should indicate that the server has hit a bottleneck.  Make sense?