views:

723

answers:

6

From an earlier post about trying to improve my sites performance I have been looking at HTTP compression. I have read about setting it up in IIS but it seems to be a global thing for all IIS application pools I may not be allowed to do this as there is another site running on it as well. I then saw some code to put in global.asax to achieve the same thing on a per website basis.

See Here http://www.stardeveloper.com/articles/display.html?article=2007110401&page=1][1]

Is this as good as the setup in IIS? How dramatic is the effect? Any known issues?

A: 

I think the Global.asax option will be a good if you are in a shared hosting environment for example, where you don't have access to IIS configuration.

IIS 6 provides basic compression support, but if you're already in IIS 7, it provides you great HTTP compression support, you can define which files get compressed based on their MIME type in your configuration files...

CMS
A: 

It achieves essentially the same thing as IIS compression - both end up sending the response with gzip compression. I've recently implemented this method, and it consistently reduces response size by 60% with no performance impact worth worrying about.

There are a few possible issues. Firstly, you need to be careful about output caching. You need to use a custom VaryBy to make sure that different versions are cached for requests with different Accept-Encoding headers. Otherwise, if the compressed version is cached then all users will receive it, whether or not their browser can accept it.

Secondly, GZipStream will sometimes truncate the last few characters from the response if you use Response.End or Response.Flush, because the stream isn't closed until too late. I'm not aware of any nice solution to this.

Finally, this will only compress your HTML. Any CSS or Javascript files will be served normally. You'd need to, for example, serve those files via a custom IHttpHandler to compress them.

stevemegson
+1  A: 

http://blowery.org/httpcompress/

We've used this compression utility at my job for a while. Pretty good.

Steven Rogers
+4  A: 

If you move forward with this, I'd suggest implementing a HttpModule versus global.asax. The HttpModule allows you to disable compression with a config change versus rebuilding and allows you to monkey with your compression Assembly separate from your web app.

Rich Crane has a pretty nice 2.0 module here: http://www.codeplex.com/httpcompression/ if you want to get up and running fast.

The blowery project Steven Rogers mentioned is a HttpModule as well.

Otherwise, writing your own is pretty straightforward. A HttpModule gives you the same events as global.asax - BeginRequest, EndRequest, and finer grained events like PostReleaseRequestState and PreSendRequestHeaders which you may need to iron out all the wrinkles.

As far as IIS compression verus HttpModule, IIS is definitely easier since you don't have to fuss with yet another Assembly. I've used both methods with business apps and both perform about equally under load testing. If IIS is available, I'd say use it.

Between 60 and 80% compression for HTML, JS, CSS, and XML files is common with gzip. Keep in mind a lot of your payload may be images and multimedia objects which are much harder to compress.

Corbin March
A: 

There are issues with JavaScript and VBScript. The JavaScript problem has been confirmed in a comment by xxldaniel on a codinghorror article, and I had issues with VBScript (for M$ Office automation) using a JSON-like "Scripting.Dictionary" with "Microsoft.XMLHTTP" request.

A: 

Hello, You may try mod_gzip modules. It uses managed ZLib version and allows highly adjustable configuration. Syntax is compatible with the same named Apache module and even extended. So for example you could set different compression level for different mime types and so on.

Slava