OK.  So we need to add:

D. Sending static content to the browser.

and the test you've been running so far assumes that all users are new users.  To measure performance for existing users, you should probably add:

oHeaders.Add "If-Modified-Since", "Mon, 4 Sep 2006 00:00:00 GMT"

to each of the requests for static content.  I'm assuming that ACT doesn't do that automatically somehow.  Note that if you do that, you'll either need to update that data manually if you modify the static content, or generate it automatically in the correct format.  A simpler method would be to just not make the requests for static content at all.  For that to be truly realistic though mojoPortal would need to provide a way to offload the static requests to a different server, a la akamai.  I don't think that would be that hard to implement.  Basically wherever you generate URLs that contain "Data/Sites", you'd allow for a different hostname to be used.

Also, it's not clear whether ACT is actually creating a new connection for each request or whether it is pooling connections somehow.  If it's creating a new connection that could create a slightly higher load on the server and increase the time to first byte.  I'd ignore that for now though.

--Dean

Updated analysis (assuming your latest test was with no caching and the server was using 100% CPU):

A. Rendering modules.  This includes DB calls, business object instantiation, and rendering to HTML
B. Rendering a page from rendered modules.
C. Sending the rendered page to the browser.
D. Sending static content to the browser.

A+B+C+D = 251 ms/iter
B+C+D = 170 ms/iter
A+B+C = 167 ms/iter

Taking differences:

A = 81 ms/iter = 29%
B+C = 86 ms/iter = 34%
D = 84 ms/iter = 33%

To split out B and C, you'd need to do another test with "dumb output caching", though I suspect that C is pretty neglible.  If so, it looks like module caching will roughly double performance (neglecting static content).  To improve beyond that it looks like output caching would be needed.

--Dean

OK.  So, the correct analysis would be (note redefinition of A and B below):

A. Rendering modules other than blog and events.  This includes DB calls, business object instantiation, and rendering to HTML
B. Rendering blog and events and rendering a page from rendered modules.
C. Sending the rendered page to the browser.
D. Sending static content to the browser.

A+B+C+D = 251 ms/iter
B+C+D = 170 ms/iter
B+C = 167 ms/iter

Taking differences:

A = 81 ms/iter = 32%
B+C = 167 ms/iter = 67%
D = 3 ms/iter = 1%

I suspect most of the time spent in B+C is spent rendering the blog and events modules.  It might be worthwhile to do a test where you cache those even if the cached HTML is somewhat broken.  That would give you a feel for the max you can gain from module caching.

--Dean