Few questions

I installed it on my sandbox running DNN 4.3.3. and that seems to work though I did not test a lot, that is for later.

On my production server I use native IIS 6.0 compression and a lot of modules are cached up to one day. As for now I do not see any added value in installing PageBlaster on my production server.

If you could add the following functionality I will be interested in installing PageBlaster on the production server:

1. ViewState. Move it either to memory or store it in the SQL database. Make it a choice in your config file.
2. Whitespace removal
3. Removal of all crap that DNN causes when it build pages. There is just so much that does make DNN not comply with any standard.

Thanks
Mariette

Thanks for checking it out.

Your 3 enhancements are allready on the way and due out shortly in the Pro Version.

For the ViewState persistent storage I will have that go to disk to keep any DB specific code out so that it will always work on any site.

Compression in IIS is good, and if you have that it is good to set compression to "none".

I think you would see a big difference using this because Module Level caching does not come close to Page Level caching in DNN.  There are lots of calls that are still made to the DB even if all your modules are cached.

I did a SQL Trace while testing and this module reduce the DB hits to one per page (the portal lookup).

Thanks. I still don't understand how I can benifit from caching when a tab has for example a forum stored. If I look in the cache folder I only see cached data by tabid. How does a URL like http://www.smallbizserver.net/Default.aspx?tabid=53&view=topics&forumid=40 gets cached. BTW, Active Forums has its native caching mechanisme.

I have only 16 tabs on my site but a total of 48,000 pages.

Excellent question.

The module caches every unique Url.  Look inside your tabid folder for the forums in the cache and you will notice one file for each different Url that you hit.

Another advantage is at app restart.  DNN will not be taxed as hard to reload it's own cache on an app restart if the pages can be delivered from a static file.

The higher your traffic, the more benefit you will get from page level caching and you will also be able to reduce the interval very low and still get a huge benefit if you have high traffic.

Page level caching is much better than module or partial page caching because you can actually short circuit even most of the underlying ASP.Net pipeline.  It makes it like all your doing is delivering straight Html.

Here is an article if your interested to learn more:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspnet/html/asp03282002.asp

OK, now it seems to create more .info files. Sorry for bugging you but I have something I don't understand. You wrote "Yes, you can turn off other caching if you are using PageBlaster and it will give you more memory for caching pages." I understand that PageBlaster caches pages on disk and not in memory. Then why do you say that by disabling caching in the Host settings frees up memory so that I have more memory for caching pages...??

I have loads of memory available and it would be nice if PageBlaster would store cached pages in memory.

Right, you don't need the seperate Blowery compression module.

I tried to make them work together, but since both modules were working at that low level I had to incorporate the compression into the PageBlaster directly.  This gives more than one advantage. 

1. Less DLL's in the /bin folder.
2. Less to configure (you can remove the sections from web.config)
3. When PageBlaster saves to memory or disk, it actually saves a compressed copy, so the delivery of new pages does not have to be saved again.

The cached pages are saved in Memory and on Disk, when the memory interval expires after a page has not been accessed it will still be available on disk until that interval expires, then it will start all over again on the next page access.

You can look in the cache-folder that is configured , by default it's /portals/_default/Cache, to see the cached pages on Disk.

Yes, you still want to do the client-side HttpCacheability for even more performance improvement.

The Pro version of the PageBlaster due out soon, will allow you to set all of this at the page level if desired.

You're welcome Gilbert,

No, the PageBlaster Pro version will be a commercial product offered by Snapsis.

Thanks for your question.