20

I'm looking to setup a cookie-free domain intended to serve static content for a web application, similar to the http://sstatic.net/ site that the stack exchange sites use.

My question is, what optimizations can I make to my IIS 7.5 setup for such a domain? For example, it will never be responsible for anything but serving static content, so would disabling ASP.NET integration be a good move for this site?

Any suggestions or references on setting up such a site with IIS 7.5 would be most welcome.

Edit

Just to clarify, this isn't the ONLY site on the server, so suggested optimizations should target the site level, and not the server-level config.

DanP
  • 303
  • 1
  • 3
  • 8

2 Answers2

18

There are several considerations in this, some which are handled on IIS (HTTP compression, caching headers fx), and some which are handled during the build process / before deployment (such as Javascript and CSS file concatenation & whitespace minification).

As such, it's a bit hard to give you a complete rundown in one answer, as some of it will depend on your build & release methods. In high level steps:

  • The site is "cookieless" by virtue of you using a new domain, one that is not tied to your webapplication. Since you're not setting any cookies for the domain (using f.x. .NET application code), it's then "cookieless".

  • You should absolutely enable HTTP compression for static text content such as Javascript and CSS.

  • I'm not the greatest IIS administrator, but as far as I can tell, you only need the default IIS components associated with the basic "Web Server (IIS)" server role.

  • You should absolutely enable long caching headers for the static content. The general recommendation is 31 days, but you can set it higher or lower. Remember, if you serve static content with long cache headers, then you must change the URL if you change the file, to avoid old cached content being re-used by the clients.

  • You should enable HTTP keep-alive (same docs as caching headers).

In addition to this, there are pre-deployement tasks, such as whitespace compressing the Javascript and CSS, and ideally compress PNG's better, etc. This is were your development tools and build cycle helps decide how to proceed.

When you're done, try downloading a few files from your static servers with YSlow enabled. I find that the "Classic V2" ruleset gives the biggest impact for the effort, so I would suggest check your score against this YSlow ruleset.

Of the "Classic V2" ruleset, these rules apply cleanly to your static server IIS instances & content:

3. Add an Expires or a Cache-Control Header
4. Gzip Components
10. Minify JavaScript and CSS
11. Avoid Redirects
13. Configure ETags
19. Use Cookie-Free Domains for Components
22. Make favicon.ico Small and Cacheable
  • Thanks for your comments: I've already taken care of the pre-production considerations you've noted. What I'm really after is the nitty gritty of the IIS config. Since there's nothing but static content, I assume I can remove a lot of things from the http pipeline, etc. – DanP Apr 05 '11 at 22:35
  • 1
    @DanP: There really isn't that much work in setting up IIS. Microsoft is getting good at shipping "secure by default" minimal configurations. Performance-optimization by removing IIS components that are part of the basic Server Role is IMHO premature optimization. I can almost guarantee that the performance gain won't be worth it, as static file serving usually has trivially low server load. For end user performance, the important part is getting the HTTP semantics right -- caching headers, compression, keepalive, as per the docs above. –  Apr 05 '11 at 22:46
  • The defaults are designed for static file serving - if you just add the Web Server role, you're set up with a minimal pipeline for serving static files. So, to minimize the pipeline - don't install anything else! – TristanK Apr 05 '11 at 22:50
  • @TristanK: I guess I should be more specific...this isn't the ONLY site on the IIS server, so I need to make my optimizations at the site level, not the server level. – DanP Apr 05 '11 at 23:36
  • Yeah, that's kinda key information. If you've decided that this is your chosen path, I reckon a) install a new one to compare with, b) mark any modules/handlers you want to strip out (that are not part of the default install) with precondition="AppPoolName!=StaticPool" (might have the syntax backwards there). That's pretty much it, to include/exclude modules in a given app pool. – TristanK Apr 06 '11 at 13:00
  • These are good recommendations for serving static content in general, but there not really anything here particular to IIS, which was the heart of the question. For instance, an IIS worker process takes about 60MB memory as standard - I find it hard to believe all that is required for serving static files. – UpTheCreek May 17 '11 at 14:09
9

There's a very interesting write up here where someone is using IIS to serve static files. It mainly concentrates on tweaking the IIS file caching settings to limit disk activity (which was his bottleneck). He says he's seen a 20x increase in performance.

UpTheCreek
  • 1,598
  • 10
  • 31
  • 45