In the earliest versions of IIS, all of the web pages and sites on a given system ran in a single Windows process. This meant that one application, if not written well, could cause issues with other applications. An application with a memory or handle leak would eventually require a restart of the single process (or even a reboot of the server).
In later versions of IIS, Microsoft added the concept of web applications and application pools to IIS. With IIS, a web application is a set of one or more URLs (web pages). For example, the pages for the WWW2.Reskit.Org example that you created in the Configuring IIS bindings recipe are stored in C:inetpubwww2 on SRV1. You can configure IIS to run different web applications inside of independent worker processes. This means that your default website and the WWW2 site could run inside of totally different worker processes, and issues with one are not going to affect the other.
An application pool is a set of worker processes that IIS uses to run a specific application. You can run one or more applications within a given application pool, or run each application in separate application pools. Technically, a website and a web application are not the same, but in many cases, different websites end up being distinct applications.
The application pool feature provides application isolation, enabling you to run possibly unstable applications independently of others. And since you can configure an application pool to run more than one worker process, application pools provide a degree of scalability (taking use of multiple cores on modern processors).
With application pools, IIS can spawn numerous threads in each worker process that IIS runs in parallel, which takes advantage of today's multi-core processors. IIS can create and destroy worker processes on demand, adding more when the workload is higher, and destroying them when they are not needed.
You can also set up the worker processes to be recycled by IIS (that is, stop, then restart). Thus, if an unstable application contains a memory leak (something quite possible when using older ISAPI technologies, for example), recycling the process returns the leaked resources back to the OS. Thus, even a very poorly written application can run reasonably well inside IIS.
There are a variety of conditions that you can set to trigger recycling on an application pool. You can set a schedule of when to recycle; you can recycle if the private memory exceeds a predetermined value (for example, 1 GB), or after a certain number of requests (such as recycling the application pool after 1 million hits).
For fuller details, see https://technet.microsoft.com/en-us/library/cc745955.aspx.
This page relates to IIS 7, but the details are still the same for the version of IIS shipped both with Windows 10 and Server 2019. Another nice feature of application pools is that you can configure each application pool with separate credentials, which provides increased security of IIS applications. For example, an HR application could run using the credentials ReskitHRApp, while you could configure an accounting web application to run as ReskitAccountApp. You could then set up Access Control Lists on various resources (files, SQL databases, and so on) based on these user IDs.
In this recipe, you create a new IIS web application based on the WWW2 site that you created in the Configuring recipe. The recipe also creates and configures an application pool that hosts the application/website.
You need to run this recipe on SRV1, which you configured with IIS (created in the Installing IIS recipe) and with the WWW2 site (created in the Configuring IIS bindings recipe).
- Import the web administration module:
Import-Module -Name WebAdministration
- Create a new application pool:
New-WebAppPool -Name WWW2Pool
- Create a new application in the pool:
$WAHT = @{ Name = 'WWW2' Site = 'WWW2' ApplicationPool = 'WWW2Pool' PhysicalPath = 'C:inetpubWWW2' } New-WebApplication @WAHT - View the application pools on
SRV1:Get-IISAppPool
- Set the application pool restart time, as follows:
$IPHT1 = @{ Path = 'IIS:AppPoolsWWW2Pool' Name = 'Recycling.periodicRestart.schedule' } Clear-ItemProperty @IPHT1 $RestartAt = @('07:55', '19:55') New-ItemProperty @IPHT1 -Value $RestartAt - Set the application pool maximum private memory, as follows::
$IPHT2 = @{ Path = 'IIS:AppPoolsWWW2Pool' Name = 'Recycling.periodicRestart.privatememory' } Clear-ItemProperty @IPHT2 [int32] $PrivMemMax = 150mb Set-ItemProperty -Path 'IIS:AppPoolsWWW2Pool' ` -Name Recycling.periodicRestart.privateMemory ` -Value $PrivMemMax - Set the maximum number of requests before a recycle and view, as follows:
$IPHT3 = @{ Path = 'IIS:AppPoolsWWW2Pool' Name = 'Recycling.periodicRestart.requests' } Clear-ItemProperty @IPHT3 [int32] $MaxRequests = 104242 Set-ItemProperty @IPHT3 -Value $MaxRequests Get-ItemProperty @IPHT3 - Recycle the application pool immediately:
$Pool = Get-IISAppPool -Name WWW2Pool $Pool.Recycle()
In step 1, you import the WebAdministration module explicitly. This loads the IIS provider, creates an IIS: PSDrive on your system, and produces no output.
In step 2, you create a new application pool (WWW2Pool). This application pool points to the WWW2 site that you created earlier. While that site is currently just a single page, you could extend it, in which case the application would encompass all pages in the folder. This step has output that looks like this:
Once you have created the application pool, you can create a new web application to host the WWW2 site created earlier. In step 3, you create an application within the just created application pool. The output looks like this:
In step 4, you review the existing web application pools on SRV1 (including the WWW2Pool that you just created). The output for this looks like the following:
In step 5, you configure IIS to recycle the application pool at 07:55, and again at 19:55. In step 6, you configure the application to have a maximum size of 150 MB. In step 7, you specify that after a certain number of requests, IIS should automatically recycle the app pool. These three steps produce no output.
In step 7, you set the maximum requests to 100,042 to trigger an application pool recycle and view the result, which looks like this:
Finally, in step 8, you recycle the pool immediately. This produces the following output:
In step 2, you create a new application pool using the New-WebAppPool cmdlet. However, there is no Get-WebAppPool cmdlet to enable you to view the application pools. Instead, as you can see in step 4, you use the Get-IISAppPool cmdlet. That's because the Get-IISAppPool comes from the IISAdministration module—so much for consistency.
In step 4, you can see a variety of existing web pools. These show the IIS application pools created both by default, and by other recipes in this book. The application pool is an important feature to enable you to run multiple web applications on a single server and avoid application interference. As a part of deploying IIS, you might consider removing all but the necessary application pools.
In step 5, step 6, and step 7, you configure the application pool properties. You achieve this by setting the item properties within the IIS provider. Where you want to configure pool properties, you set the relevant item property on the application pool item for the pool.
These steps make use of the WebAdministration provider. The item properties that you set are translated by the provider into the XML that actually drives IIS. For more information on the WebAdministration provider, see https://technet.microsoft.com/en-us/library/ee909471(v=ws.10).aspx.