The default option for Page Parameter should be populated from the global config file which by default is page-param="tabid" In DNN you should always use at least tabid for the Page Parameter, but if you don't each and every Url will still be cached seperately, they'll just all be in one folder on the disk. The page parameter is used to create a folder where all the different instances of cached pages (based on the entire url) are kept for that page. When the cache is invalidated with a post-back or a manual hard refresh all the cache files for that folder will be deleted which will in turn remove those instances from memory. So, for pages that have modules that create multiple pages themselves it is a good idea to add extra page parameters like forumid, or threadid, or articleid. That will make PageBlaster narrow down what is considered a "page" so that a post-back on one forum thread doesn't clear the entire forum cache. The Page Parameters for a page with forums on it may look like this: tabid;forumid;threadid This will not make more cached pages, it will just organize them differently so that a "page" that gets cleared does not clear all instances on the tab. It would probably be a good idea to ad the ID param to the page that has the player profiles since the profiles are probably fairly static once updated and you could then avoid clearing out all the profiles everytime one is updated. The Additonal Cache Key is for parameters that are not on the Url that you would like to use so that the pages are even more uniquly identified. The one you are seeing is actually [ PB:Request.Browser.Browser ] and is added to make sure that different browsers are cached uniquely (mainly because the DNN Menu has different output for different browsers and will not work in FirFox if IE caches it first). Using the additional cache key will create more cached pages than normally would be created with just the Url. Cached pages are generally only about 10K to 20K each because they are also compressed before caching them. The cool part about this is not only less disk space, but also less space in memory, and the best thing is that now the page does not have to be compressed over and over again on every request. Build it once, do optimizations and replacements, then save it in cache to return directly on the next 1000's of requests. For disk caching, I would recommend even longer than 10 days if you have the space to cache more (I cache mine for 99 days) unless you have something that is getting updated in a way that does not invalidate the cache. |