Internet Information Services—Server Software With Request-Processing Architecture

For the last couple of weeks I’ve been talking about server software, specifically in regards to how each handles HTTP requests and connections. This is all part of an ongoing series about website performance.

Two weeks ago I talked about Apache’s multi-process modules and how they perform well until there’s a heavy traffic load. Last week I turned my attention to NGINX and its event-driven architecture and how it can be used either as a standalone server or as a reverse proxy server in front of Apache.

In the first post about Apache I briefly mentioned two other applications for running a server, Internet Information Services (IIS) and LiteSpeed. Today I’ll talk about IIS and next week I’ll close out this series with thoughts about LiteSpeed and some performance tests I’ve run for the site before and after moving to a new server with my hosting company.

Internet Information Services (IIS) Sever Software

Let me begin by saying that I’m far from an expert when it comes to IIS, having never worked with it before. Please understand that what follows is my best attempt to summarize information from a handful of different articles, leaning heavily on a few from Microsoft’s site.

I’m pretty sure I have the general idea correct, but my apologies in advance if I have any of the specifics a little off. I’ll point you to the articles I read during my research for more information about the specifics.

Internet Information Services (IIS) is proprietary software from Microsoft. It isn’t free and it’s tightly coupled to the Windows operating system. It’s also made to run with .Net services so naturally if your sever side language is ASP or ASP.NET or if you use MSSQL as your database, your obvious choice is IIS.

IIS uses a request-processing architecture. It listens for HTTP requests (as well as requests for other protocols) before creating worker processes (w3wp.exe) to handle the request.

There are different listeners for different protocols with HTTP.sys being the HTTP listener. It waits for an HTTP request and then sends the request to an IIS service for processing. When processing is complete, HTTP.sys sends the response back to the browser. HTTP.sys also has a cache and if it has the requested file in cache it can return it directly to the client browser without having to contact any IIS services for processing.

How IIS Processes HTTP Requests

That’s the overly simplified flow anyway. Here’s a little more detail starting with an image from Microsoft’s site.

  • A client browser initiates an HTTP request and HTTP.sys intercepts the request.

  • HTTP.sys contacts the Windows Process Activation Service (WAS) for configuration information.

  • WAS gets the configuration information from applicationHost.config and passes it on to the World Wide Web Publishing Service (WWW Service).

  • WWW Service uses the information to configure HTTP.sys.

  • HTTP.sys contacts WAS again and WAS starts a worker process for the application pool to which the request was made.

  • The worker process processes the request by passing it through an ordered series of modules and then returns a response to HTTP.sys.

  • HTTP.sys sends the response to the client browser.

Sounds like a lot, but if I’m not mistaken, WAS reads configuration information from the applicationHost.config file on startup, which suggests that steps 2–4 only happen once on startup and after that WWW Service drops out of the flow.

When WAS receives an HTTP request it will determine if there’s already a worker process running in the application pool that is servicing requests for the website and if so, it will pass the request to it. If not, it will create the worker process and then pass the request. Each worker process can handle multiple requests so you don’t need a new process for each and every request like you do with Apache.

Inside the worker process, an HTTP request passes through a series of ordered steps called events and at each event one or more modules may act on it.

Modules are components that can be added or removed and they offer features for processing the request. There are native IIS modules as well as an ability to add 3rd party or your own modules, making IIS extensible. They aren’t exactly the same as modules in Apache, but I think they offer similar benefits and maybe even a bit more flexibility.

IIS Application Pools

If you look back up at the image, you’ll notice something called an application pool, which is a container for worker processes. Each application pool runs isolated from others so you might have one site running in one application pool and a second site running in another. This way if something happens to one site, it shouldn’t affect the other.

By default each application pool contains a single worker process, however, more can be created and when multiple worker processes are inside a single application pool, it’s called a web garden. The idea is that a web garden can make better use of server CPU and RAM and more efficiently use resources so idle time is reduced. That’s the idea, but I’ve had a difficult time confirming if it works as advertised.

Like Apache’s worker processes, application pools and web gardens can grow out of control under a heavy load with a lot of requests.

Overall IIS is reportedly a little more memory intensive than Apache. On the other hand, it makes use of configuration wizards and a graphic interface so it can be easier to use compared to Apache’s text files configuration.

In an effort not to get too much wrong, let me stop there and point you to some other articles that can probably do a better job with the details than I can.

Additional Resources

I can’t tell you I read through every one of these articles entirely, but I did pick up a few things from most of them. The articles with the word architecture in their titles are the ones I leaned on the most.

This first group comprises information directly from Microsoft. I would assume they have the best and most accurate information about IIS.

The remaining articles are from a variety of sites. I relied more on the first four than the latter six, but that’s less to do with any of the articles and more to do with how I decided to organize this post.

Closing Thoughts

I’d guess if you choose IIS it’s less to do with IIS itself and more because you want or need to work with the .NET framework or MSSQL or are invested in Windows.

Like both Apache and NGINX, IIS has its pros and cons. The few performance tests I’ve seen would suggest it’s more resource hungry than either, but you won’t have to search for long to find lots and lots of configuration tips to make it run faster and better for your sites. Isolating applications, so what happens to one won’t affect another, is a huge plus.

There’s still one more application I want to talk about and that’s LiteSpeed, which is a drop-in replacement for Apache with better performance. I’ll talk about LiteSpeed next week and I’ll offer some performance tests on this site from before and after moving it to newer server hardware.

« »

Download a free sample from my book, Design Fundamentals.

Leave a Reply

Your email address will not be published. Required fields are marked *