Hi Mark,
There are two different issues at play when referring to DNN response and performance:
1) ASP.NET work process activation and JIT
The typical lifecycle of any ASP.NET application typically lasts 20 minutes after last page has been served. Sites that don’t receive regular traffic are subject to having their work process shut down by the IIS. This behavior is default and in some ways desirable from the memory space management perspective on the server, however can cause grief to new DNN site owners that are not aware of this. Some people use keep-alive pingers that keep visiting their domains at regular interval and prevent work process from being unloaded. Others jack up the default timeout value on the IIS server to some really long interval in order to circumvent the inactive process timeouts. Both methods have legitimate use, however they can also lead to other problems such as memory leaks and unexpected process termination during active session.
2) Server subsystem (RAM, disk I/O, CPU, database)
Many people forget that DNN is not a website, it is dynamic and complex web application that is executed on the server with a web based interface. Being an application, the optimization of performance has be approached from different perspective. Traditionally web designers optimize their sites based on html document size and it’s media components, with DNN those are important points but there is another aspect, an application resource consumption on the server. This is especially important when you host your DNN site in the shared hosting environment where server resources may be constrained by the ambient load.
Basically the process of optimizing DNN should start during the portal design and should include following goals:
a) Reduce application active memory consumption by eliminating unnecessary module and using caching model that best suits the environment. This means disk caching generally better in a high density hosting environments where work process can experience high memory pressure.
b) Reduce application disk and database I/O demands by using caching mechanism and avoiding use of modules that cause high I/O on a high traffic page. For example there are modules that show most recent forum topics, placing it on the home page will result every page load to generate additional database queries and rob the site of precious I/O cycles.
c) Reduce or eliminate event and site logging if possible, the DNN EventLog tables are notorious to cause database bloat and cause many database queries per page load, thus delaying your page load.