People who are new to hosting web apps on IIS (Internet Information Services) sometimes struggle with the concept of application pools. What is an IIS application pool? What purpose does it serve? In this post, we’ll answer these questions—and more.
We’ll begin by offering a brief introduction to IIS itself. If you’re already well acquainted with this piece of software, then the first section isn’t for you; feel free to skip it. Those of you who choose to read it will learn a bit about IIS and the role it plays in the Microsoft stack.
After that, we’ll proceed to cover the concept of “pools” in the tech world. If you’re an IT professional—especially in the field of software development—you likely come across a reasonable number of “pools” in your day-to-day work, so it makes sense to define those as well.
Then we get to the main point of the article: IIS application pools. You’ll see the definition of the IIS application pool, understand its purpose, and learn details about the different types of pools.
IIS stands for Internet Information Services, as you’ve seen in the introduction. Formerly known as “Internet Information Server,” IIS is a web server created by Microsoft.
The paragraph above summarizes what IIS is. We could leave it at that and call it a day, if not for the “web server” part. You see, “web server” is a somewhat ambiguous term, because it can mean two different—yet related—things.
“Web server” can mean a computer (which can be both a physical machine or a virtualized computer. ) It can also mean a type of software that runs on said computer. Both the hardware and software varieties of the web servers are there for the same purpose: they take and reply to requests.
Since Microsoft is—or at least has been, for the most part of its history—a software company, it shouldn’t take you long to understand that IIS belongs to the “software” category of web servers. So, IIS is an application used to host and manage web applications/websites on Windows. It was introduced back in 1995 as a free add-on for Windows NT 3.51, and it’s been part of the Windows NT family since then.
Tech workers come across the concept of pools all the time in their works; this is especially true for software development. Since it’s such a pervasive concept, it’d make sense to dedicate a little time to define it.
According to Wikipedia:
In computer science, a pool is a collection of resources that are kept ready to use, rather than acquired on use and released afterwards.
You might think that the definition above doesn’t sound that far from caching, and you wouldn’t be far from the truth. Sure, there are differences between the concepts, but they also have a lot in common. Think of caching as storing values for later reuse, while pooling deals with resources.
The justification for adopting pools is usually performance; for instance, think about scenarios when acquiring some resources might present a high-cost. In situations like that, pooling might come in handy.
A common example would be a pool of database connections. Creating connections presents relevant costs, so it’s advantageous to keep a pool of existing connections from which programming routines can obtain them, instead of creating new connections every time one is required.
We started the post by giving an overview of IIS, proceeding to define the concept of “pools” in tech. Now we’re ready to put it all together and start answering the title question.
After learning about IIS and understanding the meaning of the pool in Computer Science, defining the “IIS application pool” should be almost trivial. An IIS application pool is a pool—i.e., a collection—that houses applications on IIS. Each application pool consists of a process called w3wp.exe that runs on the server machine. That’s pretty much it.
The question then obviously becomes: why? What is the purpose of application pools on IIS? What do you use them for? Are there implications for your apps?
As the previous section just covered, you can think of an application pool as a collection or compartment of applications. An application pool can contain n apps, and it allows you to create isolation levels for your applications. Why would that be useful?
One reason to adopt application pools might be to ensure availability for your apps. Since each pool runs in its dedicated process, an error in one app won’t take down applications in other application pools.
Additionally, you might want to use application pools to configure different levels of security for different applications. For instance, you have five applications. One of them requires a higher level of security than the other four. In this case, you could create two separate application pools for the two different groups of applications. You can configure each pool to run under a different user account, by specifying the identity for the Application Pool.
Finally, you might also want to run applications on different versions of the .NET framework. This is yet another case where the application pool might come in handy.
You can classify IIS application pools into two main categories: shared application pools and dedicated application pools.
You call an application pool “shared” if it hosts several web applications running under it. You’d typically combine many applications into a single application pool if you want to preserve the memory of the server. As we have already mentioned, each pool consists of a w3wp.exe process. If you have ten applications, each one in its own pool, that means you have ten processes in execution. On the other hand, if you host all ten applications under a single application pool, you end up with a single w3wp.exe process running.
What about a dedicated application pool? Well, that’s exactly the opposite: you say a pool is dedicated when it only has a single application running on it. Isolating each app in its own pool enables you to have a more rigid separation between them. Also, as we’ve already said, this compartmentalization prevents the crash of an app that brings other apps down as well.
Here are some of the most important advantages of having dedicated application pools over shared ones:
The disadvantage of dedicated application pools boil down to resource usage: since each pool is its own process, more resources are required.
Which type of pool should you use? It’s impossible to give a one-size-fits-all answer. Each case will be different and needs to be analyzed individually. However, we’ll give you a rule-of-thumb you can follow to identify certain scenarios for a dedicated pool. Here it goes: prefer a dedicated application pool if your application matches at least one of the following criteria:
Those are some good reasons to prefer dedicated application pools. But as we’ve said, this is only a rule-of-thumb. Don’t follow it blindly, and never forget to exercise critical judgment.
Was that all there is to know about IIS and its application pools? On the contrary: all that you’ve read is nothing but the tip of the iceberg. Now it’s up to you to consider studying and learning more. An interesting next step would be learning how to monitor IIS performance: it sort of acts as a sequence to the topic of this post.If you want to go a step further, you should start checking out tools at your disposal. For instance, take a look at Retrace, which is an application performance management system by Stackify.
Stackify's APM tools are used by thousands of .NET, Java, PHP, Node.js, Python, & Ruby developers all over the world.
Explore Retrace's product features to learn more.
If you would like to be a guest contributor to the Stackify blog please reach out to stackify@stackify.com
