The maximum number of Application Pools that IIS 6 can host depends on a few different things, including (but not necessarily restricted to) the type(s) of content being served, the number of application pool running concurrently, and the identities of the application pools.  Other things like type of hardware, average load, etc. also will come into play whenever the question of load testing and performance tuning web applications comes up.  However, following are a few things to keep in mind regarding how many application pools IIS6 can handle.



Type of content being hosted

How many application pools IIS6 can host is partially affected by the type of content being hosted - static/HTML vs. dynamic/ASP vs. managed/ASPX. In general, testing shows that IIS6 can run more than approximately 4 times as many application pools that host only HTML than those that host dynamic ASPX applications.  Further, IIS6 can run more application pools hosting ASP than ASPX, but fewer hosting ASP than static HTML.  (In other words, ASP application pools fit in somewhere in the middle). These are not exact numbers, but just the general rule that you can run more app pools with static content only than with ASP, and more with just ASP than with ASPX.


If the different app pools are hosting dynamic content (ASP), you can boost performance by setting the ASPExecuteInMTA metabase key.  Setting this key will allow ASP to run on MTA instead of STA. This is discussed in the IIS6 Static and Dynamic Hosting article at


Because of the overhead memory and CPU cost of running dynamic applications, your server will reach a limit in the number of application pools it can host. With ASP content, you can mitigate this limitation on application pools by enabling ASP pages to run on multithreaded apartment (MTA) threads instead of single-threaded apartment (STA) threads. ASP is capable of running all of its threads in an MTA. If your COM components are primarily free-threaded or both-threaded, running the ASP threads as MTA can improve performance significantly. By default, the AspExecuteInMTA metabase property is set to 0, which means that ASP does not execute in MTA. Set this property to 1 at the application level to enable ASP to run in MTA.



More information on the ASPExecuteInMTA key here:  It is important to note that this will NOT affect application pools running ASPX applications. ASPX app pools are much more strictly bound to upper limits in terms of concurrent numbers than ASP.  If some of your app pools are running ASP and some are running ASPX, you will not be able to squeeze as much perf out of that scenario in terms of max # of app pools than if only ASP was being served across all the pools.




Number of Application Pools concurrently running

When considering the maximum number of application pools your server can handle, it is not necessarily the total number of application pools that is important, but rather how many pools are concurrently running. For example, you can have 1000 application pools in total, but only 200 are ever running at the same time.  The trick here is to reduce the number of application pools that are running that are idle (not handling any HTTP requests).


To reduce the number of application pools that are running when idle (that is, not currently handling requests but still taking up system resources), lower the IdleTimeout metabase value for the application pool.  You can do this in the IIS manager by lowering the pool’s "Shutdown worker processes after being idle for..." setting on the Performance tab of the application pool’s Properties.  The default is 20 minutes, but you can modify this depending on your application and business requirements.


More information on the IdleTimeout property can be found at and



Application Pool Identities

Whether your application pools use their own identities or use a shared identity (such as Network Service) will also effect how many application pools the server can host.   If an IIS6 server has more than approximately 60 separate worker processes all with their own identities, resource allocation problems may occur. On the other hand, if all of the application pools use the same account for their identity, the same resource allocation problems should not occur.


If you require your application pools to have separate identities and you do not want to run into the resource allocation problems, you can use the UseSharedWPDesktop registry key as follows:


1.       Click "Start", click "Run", type "regedit" (without the quotation marks), and then click "OK".

2.       Locate the following registry key:




3.       Right-click "Parameters", point to "New", and then click "DWORD Value".

4.       Type "UseSharedWPDesktop" (without the quotation marks).

5.       Set the value for this new key to 1.

6.       Quit Registry Editor, and then restart IIS.



More information on the topics discussed here can be found in the following article:


IIS6 Shared and Dynamic Hosting