We will explore two essential components of IIS: websites and Application Pools. Gaining an understanding of these elements will enhance your ability to deploy and manage web applications effectively.
What is an IIS Site?
An IIS Site is like a container that holds your web application. It has several important properties.
- Site Name: A unique name within IIS (e.g., "MyWebApp")
- Physical Path: The folder on the server where your application files live
- Bindings: Define how users access your site (IP address, port, and optionally a hostname)
Example
- Physical Path: C:\inetpub\wwwroot\MyWebApp
- Binding: http://localhost:8080 or myapp.local
You can have multiple sites on the same server, each with different bindings and content.
What is an Application Pool?
An Application Pool (App Pool) is a container for one or more web applications. It defines how the applications run and are isolated from others.
Here’s what it does.
- Runs your web app in its own process
- Allows you to use different versions of .NET
- Provides application isolation — if one app crashes, others remain unaffected
- Manages performance settings like idle timeout, recycling, and max processes
By default, when you create a new IIS Site, IIS also creates a new App Pool for it, but you can change that if needed.
How do IIS Sites and App Pools Work Together?
An IIS Site must be assigned to an Application Pool. That pool is responsible for executing the code in the application and handling incoming requests.
- A site can use one app pool
- An app pool can serve multiple sites or applications, though it’s best to isolate apps for better reliability and security
Rule of Thumb: Use one App Pool per site unless you have a good reason to share (e.g., performance tuning or tightly coupled apps).
Rules for Configuration about Application Pool and Sites
- Valid: One App Pool → Multiple Sites
- Invalid: One Site → Multiple App Pools
Best Practices
- Use separate App Pools for each site: This helps with stability and security.
- Stick to the default settings at first: They’re good enough for most apps during development
- Give App Pools correct permissions: If your app reads/writes files, make sure the App Pool’s identity has access to those folders
- Learn to recycle App Pools: This refreshes the app and clears memory leaks. You can do this from IIS Manager or PowerShell.
- Use Preload for better performance: Set preloadEnabled=true so IIS warms up your app as soon as the server starts
Previous Series: Understanding of Internet Information Services – Series I
Next Series: Deploying a Web Application or Web Service in IIS – Step-by-Step – Series III
Join the conversation! Your thoughts help the community grow.