Iis – Who is responsible for maintaining IIS for web apps

iisweb-applications

IIS/Web Applications has been a tricky issue in the shops I've worked in over time.

On one hand, IIS is a service built into the server (by in large) and is typically the responsibility of the server administrators to maintain and configure. When an issue comes up, they know what needs to happen, or can at least diagnose to the point where they say, "Something is wrong with the web app" and have the developer debug their code.

However, each web application on the server is unique and has a lot of nuances that gets can be complex based on the issues at hand.

On the other hand, each web application is unique in many ways and had specific issues that need to be dealt with and the developer is the person that knows the most about the application. If the web.config file needs to be modified for debugging, or an IIS starts giving grief to the web application, the developer should know where the issue lies and fix it accordingly, either due to IIS or the application itself.

However, allowing a developer to go in and tweak with IIS on their own becomes a serious issue because some settings/optimizations can seriously muck up with the server performance and stability.

So where does the balance lie? Should the server admins be IIS gurus and handle all of those issues and I simply send the site files over deployment, or should the developer assume responsibility for the server and IIS issues and deal with them accordingly?

Best Answer

Sounds like what you really need is someone with expertise on both sides of the fence.

Related Solutions

Iis – Support 250+ concurrent users for an intranet web site

If your app is stuggling with 20 concurrent users and its not doing something very intensive like industrial-strength number-crunching, I would be inclined to take a guess that its the code that may be to blame rather than IIS.

My first suggestion is you check the codebase for bad design/logic, optimise database and data access routines and see if that has any effect. You could try using Resharper or similar to assist you in this.

IIS 7.5 Optimization for Static Content – How to Optimize IIS 7.5 for Static Content

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

Related Topic