IIS - Application pools - Asked By karur krishna madhu on 29-Nov-11 06:24 AM

i have a website with different domains (com/de/fr/tr).com is the main site and others are the sites in different languages.should i maintain single app pool or different app pools for each ? what are the pros and cons of maintaining single and different app pools?
Reena Jain replied to karur krishna madhu on 29-Nov-11 06:25 AM
hi,

Pros:
  • Applications are isolated from each other, unless IIS goes with it, an app pool locking will only take out applications in that pool
  • Ability to run applications under different ASP.NET runtimes, one pool for 1.1 another for 2.0 if needed
  • Ability to have different app pool settings for more or less critical applications. For example a corporate website in ASP.NET might want to have the shut down after __ minutes of inactivity bumped up, to prevent unloading because response is critical. Other sites might not need it.
  • Can secure pools from each other in regards to file access, great for third party, or untrusted applications as they can run under a very restrictive user account.

Cons:

  • Each application pool has its own bank of memory and its own process, therefore CAN use more resources
  • Some find it hard to debug the application as you have multiple processes
Jitendra Faye replied to karur krishna madhu on 29-Nov-11 06:26 AM

Pros:

  • Applications are isolated from each other, unless IIS goes with it, an app pool locking will only take out applications in that pool
  • Ability to run applications under different ASP.NET runtimes, one pool for 1.1 another for 2.0 if needed
  • Ability to have different app pool settings for more or less critical applications. For example a corporate website in ASP.NET might want to have the shut down after __ minutes of inactivity bumped up, to prevent unloading because response is critical. Other sites might not need it.
  • Can secure pools from each other in regards to file access, great for third party, or untrusted applications as they can run under a very restrictive user account.

Cons:

  • Each application pool has its own bank of memory and its own process, therefore CAN use more resources
  • Some find it hard to debug the application as you have multiple processes
Jitendra Faye replied to karur krishna madhu on 29-Nov-11 06:27 AM
Dedicated app pools typically will keep problems occurring in one site from effecting the others. If you share app pools across sites, you could bring down all sites on the box when an error condition exists for only a specific site (or app pool).
dipa ahuja replied to karur krishna madhu on 29-Nov-11 06:29 AM

To create a new application pool

1.

In IIS Manager, expand the local computer, right-click Application Pools, point to New, and then click Application Pool.

2.

In the Application pool name box, type the name of the new application pool.

3.

If the ID that appears in Application pool ID box is not the ID that you want, type a new ID.

4.

Under Application pool settings, click the appropriate setting. If you click Use existing application pool as template, in Application pool name box, right-click the application pool that you want to use as a template.

5.

Click OK.

Application pools allow you to apply configuration settings to groups of applications and the worker processes that service those applications. Any Web site, Web directory, or virtual directory can be assigned to an application pool.

To assign an application to an application pool

1.

In IIS Manager, right-click the application that you want to assign to an application pool, and then click Properties.

2.

Click the Virtual DirectoryDirectory, or Home Directory tab.

3.

If you are assigning a directory or virtual directory, verify that Application name is filled in. If the Applicationname box is not filled in, click Create, and then type a name.

4.

In the Application pool list box, click the name of the application pool to which you want to assign the Web site.


More
Suchit shah replied to karur krishna madhu on 29-Nov-11 08:52 AM

Dedicated app pools typically will keep problems occurring in one site from effecting the others. If you share app pools across sites, you could bring down all sites on the box when an error condition exists for only a specific site (or app pool).

Also, if you are mixing versions of ASP.Net on the same web server, you will need different app pools per ASP.Net version at a minimum, or do it per website.

I can't think of a good reason not to separate app pools, it is so easy to do.


The primary reason for combining sites in app pools is to conserve memory. There's a large memory overhead in running several w3wp.exe processes. If you have no specific reason for splitting them up, it's better to keep them together.

Also, you can designate different users (such as a Windows account) for different app pools. That enables setting up those users with different permissions in the database. That helps enhance security, and enables tracking which website/user is hitting the database, useful when tracing database performance issues.