Websites and Application Pools are two crucial IIS components that we shall examine. Understanding these components will improve your capacity to efficiently deploy and administer web applications.

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