Hi I noticed the help system shows a lot of very basic information, and I need more than that.
So I thought I would post this.
Can anyone explain:

- The difference between NoCache, Privat, Public, Server, ServerAndNoCache and ServerAndPrivate
- The difference between Deflate compression and GZip Compression
- The difference between the compressions levels
- Page state persistance to Page or to Memory, I know what it basically means, but what really happens in the background? If I switch this to page, a lot of stuff goes wrong in DNN, pages can't be found (path too long), I can't save host settings, etc.
- Module Caching method to Memory or to Disk, Again, I have a basic understanding, but what does really happen, where is everything cached, etc. What are the implications for the server load...

Most of  these terms are not really DNN specific, and can be found quite easily on Internet:

• MSDN info on different caching methods
• Wikipedia info on Deflate and GZIP
• nformation on what Viewstate (normal term for page state) is: http://www.dotnetjohn.com/articles.aspx?articleid=71 . In essence, by default, asp.net stores the viewstate in the page (just look at the page source of any dnn site, and you will find a (sometimes very large) viewstate field, at the bottom of the page. The largeness of the field is the problem (sometimes 15KB or more per page): it can cause extra bandwith, and slower loading pages. A trick is to persist the viewstate of rendered pages on the server in some way. Common methods are persisting to RAM (cache), Disk (XML) or Database. Right now, in version 4.4.0, you can choose between page (which does nothing special and is the asp.net default), and cache. There is a catch. Since view state is unique for each rendered page (so for each session and each page in that session), a larger site can start using a lot of cache. A simple calculation: suppose your view state is averaging 5KB for each page rendered. Suppose you have on average 10 users active on your site at the same time. Suppose each users visits 10 pages during his session. Suppose the cache is persisted for 30 minutes (I don't know the actual lenght of the cache persistance for view state though). This would mean 10 * 10 * 5KB = 500KB of memory used for those sessions. If you have different 10 users each 5 minutes, this would add up to 3 MB over the course of 30 minutes. You can easily see that the cache can grow pretty large for busy sites with lots of pages....
• Module caching is only done for anonymous users. The complete HTML output of the module is cached, so no code of the module is executed if content comes from cache, and no db hits. So this is good for performance. On a large site with many cached modules, the module cache can become rather huge. In order to save expensive RAM, you can choose to save the cache to disk. The advantage of persisting to disk is that the cache will survive an application restart, so after the app. pool recycles, you site will remain faster. A small performance hit of course, because disk is slower than RAM, but the extra overhead is very small. For instance, the module cache of dotnetnuke.com is persisted to disk, which freed up a considerable amount of ram, which caused the application pool to recycle less often (there is a ram limit on the application pool, which recycles the pool if the app uses a certain amount of ram). The module disk cache is saved in the portal root of every portal, in the cache folder.

 

 

---

Erik van Ballegoij, Former DNN Corp. Employee and DNN Expert

DNN Blog | Twitter: @erikvb | LinkedIn: