Posts Tagged ‘IIS’

April 9th, 2008

Getting IIS 7 to Compress JavaScript

One of the many recommendations that Yahoo makes on optimizing your web site for high amounts of traffic, and to make the response time speedier to your user is GZip encoding all your static content. I usually do this as a standard for setting up any of my Web Servers, in addition to setting expiration headers on my static content, to ensure that I am serving as little content as possible.

IIS 7 has improved and simplified the compression and serving of static files by making it easier to setup and configure than previously in IIS 6.0. The IIS 7.0 compression works perfectly for CSS, HTML, and Text files, however JavaScript is another story. The JavaScript files on my IIS 7.0 server were not being compressed and served with GZip encoding, which is a major problem for any Web 2.0 site where 75% of your content severed per request is JavaScript. (I just made that number up, but it sounds right!)

I found Rick Strahl’s post on this very subject that he wrote up about a 9 months ago. It was helpful in diagnosing my problem, however it didn’t solve it. The HTTP compression is configured in IIS 7.0’s ApplicationHost.config file (c:\windows\system32\inetsrv\config\applicationhost.config), see below for the default settings:

<httpCompression directory="%SystemDrive%\websites\_compressed" minFileSizeForComp="0">
    <scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll" />
    <staticTypes>
        <add mimeType="text/*" enabled="true" />
        <add mimeType="message/*" enabled="true" />
        <add mimeType="application/javascript" enabled="true" />
        <add mimeType="*/*" enabled="false" />
    </staticTypes>
</httpCompression>

As you can see anything that starts with the MIME type of text or message is GZip encoded just fine. However there is also application/javascript as a compressible MIME type, there is nothing wrong with that, because there are 3 accepted ways to set a JavaScript MIME type.

  1. text/javascript
  2. application/x-javascript
  3. application/javascript

However the problem comes in when you look at the default MIME type mappings setup, in the same ApplicationHost.config file, a little further down.

...
    <mimeMap fileExtension=".jpg" mimeType="image/jpeg" />
    <mimeMap fileExtension=".js" mimeType="application/x-javascript" />
    <mimeMap fileExtension=".jsx" mimeType="text/jscript" /
...

As you may notice the MIME type for JavaScript files is set to application/x-javascript, which is not the same as the default in the compression section above. So I added the following MIME type, application/javascript, to my Web.config thinking I had the problem licked, and all that I had to do was change the default MIME type for JavaScript files.

<system.webServer>
    <staticContent>
        <remove fileExtension=".js" />
        <mimeMap fileExtension=".js" mimeType="application/javascript" />
    </staticContent>
</system.webServer>

However that didn’t work either, and it should have because the MIME type now matched my compression MIME type. I even verified the MIME type in fiddler. So I then tried my last option to change the MIME type to text/javascript, which is the defacto standard on the internet for JavaScript MIME types.

<system.webServer>
    <staticContent>
        <remove fileExtension=".js" />
        <mimeMap fileExtension=".js" mimeType="text/javascript" />
    </staticContent>
</system.webServer>

Finally, this was the key to getting the JavaScript GZip Compression working IIS 7.0. And this didn’t require me to modify the ApplicationHost.config file get it done. Which is something I love about the new IIS 7.0, I can do my whole server configuration through FTP and my Web.config file.

Tags: , , , ,

Posted in How To | kick it on DotNetKicks.com | Bookmark | View blog reactions | 5 Comments »

June 30th, 2007

Which web server is better under load, IIS 6 or Apache?

One of the many techno-geek religious arguments that comes up a lot is which web server has a faster response time under load, IIS 6 or Apache? I am happy to say somebody actually put this to a test using what is known as the Digg-effect, basically a constant hammering of the server to keep it under load. The results may surprise some of the zealots out there and the test might be buried because of an unpopular fact. Here is the setup from the site:

This is a page to test the effect of high reddit and digg hits on two different servers one running IIS6 and the other Apache. The purpose is to see how each handles high hit loads and is the most reliable.

By using one server to load this page (not being tested) then calling a page from a dedicated IIS6 server into an iframe and a second page from a dedicated Apache server into a second iframe. The entire process is using PHP scripting and mysql data to store the results. To eliminate cache hits on both test servers, the page being returned to the iframe is dynamically created each time from a php script.

After the pages are completely loaded, an ajax call is made to the primary server to record the times back into the sql database for statistics. All three servers are the same physically and in the same rack and network. Bandwidth is not a measurement issue, since only the execution of the php script is being measured.

I have taken the liberty of making a screen shot of the following site just in case it is taken down. The screen show is dated 2007-06-30.IIS 6 vs Apache Graph

I have included the results below for the same reason.

Reddit hits 27653
Digg hits 874
Seconds to call the iframes from main page this run 0.0528259277344
Total seconds to load all pages this run 4.02603888512
Average seconds to load the iframes (both) 2.60272280153
Average seconds to load IIS 2.2937795829352
Average seconds to load APACHE 2.9116660201344

This is a very interesting study, and I am going to keep following this site for updates.

Tags: , , ,

Posted in Programming | kick it on DotNetKicks.com | Bookmark | View blog reactions | No Comments »