ASP.NET – J O H N R A . M E / ...yet another musings of a techie Thu, 11 Apr 2024 23:32:34 +0000 en-US hourly 1 https://wordpress.org/?v=6.5.3 These are not the settings you’re looking for /2012/08/31/iiscompression/ Fri, 31 Aug 2012 22:16:56 +0000 http://blog.jstrgames.com/?p=104 One of the biggest benefits to building anything in .NET is that, in relatively short time, a fully functioning application can be built using Visual Studio. Had a similar application were to be built using Java, a lot of ramp-up time would be required for what I would call “core infrastructure”, something that’s handled very well by Visual Studio. As a developer, you can start coding right away. And yes, I’m aware of AppFuse. I’ve used it in the past and it does address a lot of these ramp-up efforts. But, I’ll leave that discussion for another time. One of the pitfalls of these ease of development is that you end up with developers that rely on what the tool reports. They assume what is displayed is correct and don’t think to challenge or question what is reported to them. However, it’s necessary to look under the hood and what you may find could be quite a different story.

Compression Issue
I was recently asked to investigate performance issues on a vendor application built on ASP.NET running on a pool of IIS 6.0. One of the first things I like to check is to ensure that the compression settings are enabled.

As expected, IIS Management Console did report that compression settings were properly enabled. Nevertheless, on closer inspection of HTTP transmissions, Fiddler clearly shows that all javascripts or css files were transmitted in raw text. In fact, all static ASCII files sent over the wire wasn’t compressed at all. How could that be?

Given that the browser clearly indicated that it can accept gzip and deflate encoding, the response body should have been compressed. Was it possible that IIS management console was displaying the wrong information? Or, is there a deeper issue that resulted in static files being transmitted in raw uncompressed stream. How can I look under the hood to confirm that IIS wasn’t displaying the correct information?

IIS Metabase Explorer
IIS Metabase Explore is one of many tools that comes with IIS Resource Kit. It is a graphical user interface for viewing and editing IIS Metabase stores. In essence, it lets you look under the hood of IIS.

Although IIS Management Console stated that compress was enabled, Metabase Explorer tells a difference story. It confirms why static files were sent uncompressed. This minor difference resulted in sending 2 MB of content to client browsers for a simple test scenario. Once compression was re-enabled, the same scenario resulted in reduction of content down to 200 KB. That’s a difference in factor of 10, a noticeable difference.

]]>