HTTP Compression Setup on IIS & testing results (ASPX, HTML, PHP, AXD, JS, CSS, XML)

It takes about 10 minutes and 1 restart of IIS6 (Vista IIS7 has built in compression) to setup HTTP compression, the  instructions on dotnetjunkes makes it easy.

However I don't agree with the idea at the bottom of removing the witespace as IIS just adds it back in again while re-starting taking longer to process...

Within reason the path is simple
1. Turn on service at Web Site
2. Create new Web Service Extension for HTTP compression and link to gzip.dll
3. Allow editing on Metabase.xml while the server is active
4. Edit metabase.xml <IIsCompressionSchema /> section and add the file types that are in your system.  For mine it was js php aspx html xml css txt axd. 
5. Set the compression level to be "10"
6. Restart IIS

RESULT
The AXD files are usually the biggest on my site, so any way of reducing them is a bonus.

Panel-bar and Rad-Splitter AXD files reduced 83K > 20K, 56K > 12K
The CSS files were reduced 8K > 1K, 2k > 695 bytes, 905 bytes > 403 bytes
The html/aspx was reduced 16K > 4K

The RAD-DatePicker AXD files reduced 86k > 21k, 38K > 10K, 46K > 10K
The CSS for the date picker did not reduce in size.
html/aspx was reduced from 29k to 7k

As this is done at a server level it applies to all files... I'm getting excellent  response to all types of files my server has....

I'd be really interested in anyone else has done any testing with the http compression on IIS.  If they met any browser issues???

I've taken things a stage further by adding a RamDisk that the static deflated files (CSS, Javascript, HTML) are kept in.

Works really well for additional speed but the MS ramdisk.sys is not production worthy.  It crashes and does not always come back successfully after a reboot.

Does anybody know of a GOOD ramdrive product that works well with 2003?

We've been using this locally (costs money) for the very same reasons you mention.

http://www.superspeed.com/ramdisk.php

The IIS compression module speed optimization is indeed impressive, I'm really curious if it works well on all browser. I'm sure IIS and IE6/7 handshake well, maybe FireFox as well, but how about Safari and Opera? Also, I'm very curious to know how compressed scripts work in AJAX scenarios, i.e. if there are problems if a compressed script is loaded on demand upon AJAX update.

Great findings- hopefully soon I will have time to experiment with this on our web-farm as well.

I'll check out the ramdisk software. Thanks

Here is a (deleted link) to a MSAJAXPHP enabled site with both .NET AJAX & MSAJAPHP running a simple ASPX page.  Every 10 seconds or so it calls for a php (notes.php) file that updates Recent Notes.   So I am getting no problems with AJAX that is being compressed. It's just a simple test app on my server so don't judge it too harshly!

As for browsers that can handle it.  Apparently it was about 1999 when it was decided that all new browsers will support http compression.  This page talks about the different types of browser and the support they offer.  Basically all major browsers have support, and if they don't support it then the server will not serve it.

As a rule of thumb you can assume that if the browser support AJAX then it will support HTTP Compression.

I've not tried mobile devices yet with this...

I have been running compression on my websites for some time now, and I use rad ajax controls. I haven't experienced any problem with any browser, but I cant say that I've tested every combination of browser and rad ajaxified control.

However, I did choose to use Port80's  zip-enable product, which is basically a nice little GUI tool to manage IIS6 compression.
http://www.port80software.com/products/zipenable/

The main reason I used it was that I wanted the solution NOW and didn't have the time to spend working out the details... but it also claims to detect browser compatibility and enable/disable compression on a request-by-request basis, depending on the browser. This might help explain why I've encountered no problems... I don't know.

Will check out the software. 

Do you use HTTP compression on any HTTPS sites? 

does it compress the html etc before adding the SSL layer?

I don't use Secure HTTP on any of my sites, although I have upcomming work requiring this.

The ZipEnable product uses the underlaying IIS6 compression engine.

Port80 have a more advanced product that implements it's own compression engine, but I don't use this, as I didn't need the added features, and hence couldn't justify the added expense.

I just enabled compression on my web servers. I was hoping for better loading of our contact page that uses a RAD Editor, I can't tell for sure. But it seems to be a little faster.

A few questions I have for andyk or anyone else really. What file extensions did you put under the Static and Dynamic compression sections in the meta file? I put xml,xslt,js,and css under static and aspx and axd under dynamic, is that correct? are there any other files that could be compressed?

Other question is how are the dynamic pages cached after being compressed? With database connections and other content changing for almost each load for certain pages, how does it compress the files. Is there a lag?

Thanks for any info.

Brian,

For the file types I use I did it like this....

Static
php, aspx, asp, html, htm, css, js, axd, xml, txt

Dynamic
aspx, php, xml, axd

Can't remember off the top of my head how it handels dynamic files with db access. 

But it does seem to do the same process each time.  The first time a file is accessed by the client it is recieved un-compressed, but the 2nd time that file is requested it is sent compressed.  So it seems to off-line compress once it finds that the file is wanted. 

Norton Internet Security from Symantec stops HTTP Compression with at least FireFox (have not tested IE).  So when you do any testing make sure that you don't have it enabled...

Other firewall products such as Vista firewall & Zone Labs don't screw with this. 

I am guessing that norton removes the http header info that allows the server to assess what kind of client has connected to it and therefor what compression can be used. 

I would be interested if anybody has a ZipEnabled site that I can access to see if that can deal with nortons odditites?

I have a ZipEnabled public server you are welcome to play with.

It's currently running on a standby server, as the main server is down, so it's running pretty slow right now... but it is running compression and is using Telerik components (AJAX, Menu, Tabs, Multiview, Panelbar).

http://www.triathlon.org.au

It's written to support FireFox and IE7... with little/no concession to other browsers.

I'd be interested to see if you have any problems with the compression.

Cheers,

-- MB.

Hey MB,

I checked it out and nope my version of Norton does not make it possible to use HTTP Compression.  It only works for the Enterprize Version of Norton according to their support desk. 

It makes no difference if you are basic gzip.dll on IIS6 or using ZipEnable...  It's down to norton being the agent that stops it using compresson or not allowing the compression negotiation and therefore un-compressed files are served. 

Hi,

I assume that it's negotiating the compression state and still serving uncompressed files to you ??

The server is supposed to be able to handle the situation where the client will not co-operate with the compression feed.

So long as you still get fed the page(s) in one form or another, then I'm cool with Norton or whatever doing what it likes, as you can't make every client do what you want.

Actually it seems to be a little different than I reported when using ZipEnable & Norton....

HTML is compressed

CSS and Scripts are un-compressed.

So using ZibEnable saves approx 156k on your homepage, where generic gzip.dll usage would not.  therefore another reason to use ZipEnable....

I was contemplating a compression solution - and was curious what the opinion was at .NET-specific compression like ASPAccelerator.NET vs something more "broad" like ZipEnable?

haven't tried it myself, but a friend of mine is using Port80's httpZip - http://www.port80software.com/products/httpzip/.

ZipEnable is port80's "extender" of what IIS6+ has to offer in terms of HTTP compression. Arguably, it is more robust and more effective in CPU usage (since it uses what is built-in).

For non Windows 2003 Servers, port80 offers the httpzip solution
http://www.port80software.com/products/httpzip/

For Windows 2003 / IIS6 they rely on ZipEnable.

For ASPAccelerator.NET vs ZipEnable, you can check out the following blog post and comments (a  bit old, but stil...)
http://scottwater.com/blog/archive/HttpCompressionModule/

I would personally try to make it work using IIS6 only and the instructions andyk posted at the beginnig of this thread and if I fail I would try with ZipEnable.

> For non Windows 2003 Servers, port80 offers the httpzip solution
> http://www.port80software.com/products/httpzip/
>
> For Windows 2003 / IIS6 they rely on ZipEnable.
---------

Not quite right.

ZipEnable is available for Win2003/IIS6 only,  is quite reasonably priced, and makes setting up a compressed server that works, something that even a dummy like me can manage :)

Httpzip is available for all Win/IIS combinations, is a more powerful and fully featured product than zipenable, but it costs a fair bit more than zipenable.

Among it's featues is: