Http Compression - IIS or Http Module

I have been testing the module together with IIS native compression and I have a question about this. When I do not use IIS native compression I assume that the cached pages are stored in compressed format in the default cache folder. What happens if I disable compression in the module and enable IIS compression. Is the cached content still stored in compressed format or do I need to add the .webinfo extension in the metabases? Or will the module translate the cached content into HTML when asked for? I guess it will...so can I assume that even if the .webinfo files are not stored in compressed format the content is still returned to the client in compressed format because IIS native compression does not.

I hope you understand the question.

Hi Mariette,

If the PageBlaster has compression set to "none" then the pages will be stored without compression, both in memory and on disk.

Using compression in the module will actaully allow you to cach many more pages in the same memory & disk space.

Adding the webinfo extension will not make a difference, as the application does not communicate directly with IIS.

One thing you might notice if you are looking at the cached files without compression is that the page appears to be in a binary format. This is actually Base64 encoded bytes. When compression is on there will be much less of these bytes stored, but with it off, the page is still stored encoded so that it will not cause problems in the cached page which is an XML file and so that it can be delivered to the client through a byte stream.

OK, I conclude that using the compression in the module will create smaller webinfo files in memory and on disk. I did a small test:

1. I closed all access for 10 sec to my site
2. Deleted all cached content
3. IISreset
4. Opened www.smallbizserver.net and browsed around a bit
5. Cached content by the module is indeed larger
6. Returned content to the browser is still compressed according to Fiddler.

This seems to me the most optimal solution if you can set IIS native compression because it also compresses Java and stylesheets.

Another tip to prevent round trips to the server is to set Content Expiration in IIS. This works only for static content like Java, stylesheets and graphics. I have set this is IIS to 5 days. In Fiddler you can see that client side cached content is no longer asked for when once transferred and that cuts down traffic a lot. I am wondering why your site and dotnetnuke.com does not have set Content Expiration. Almost every other big site uses that.

BTW, I saw an error in Fiddler when pressing submit:

GET /https://www.snapsis.com/DesktopModules/NTForums/images/spacer.gif HTTP/1.1
Accept: */*
Referer: http://www.snapsis.com/SupportForums/tabid/601/forumid/9/tpage/1/view/topic/postid/4191/Default.aspx#4194
Accept-Language: en-us,fr;q=0.8,es;q=0.6,de;q=0.4,nl;q=0.2
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727)
Proxy-Connection: Keep-Alive
Host: www.snapsis.com
Pragma: no-cache

HTTP/1.1 404 Object Not Found
Server: Microsoft-IIS/5.0
Date: Tue, 01 Aug 2006 12:09:33 GMT
Connection: close
Content-Length: 4040
Content-Type: text/html