In IIS we can impose resource limits on the Application Pool hosting our Web Applications, in this scenario we are typically hosting in-process i.e. ASP .NET, but do these limits still apply when we host a ASP .NET Core 2.0 application?
Currently we host our ASP .NET Core applications out-of-process using a reverse proxy and kestrel therefore it wasn't clear to me whether these limits would be enforced. So I wanted to take a closer look...
IIS leverages JobObjects an OS feature which allows us to manage multiple processes as a single Unit, as well as allowing us to impose limits on resource usage for these processes. In Windows 7, Windows Server 2008 R2 and below JobObjects could not be nested and we ran into issues with other out-of-process hosting solutions like the FastCGI module which also leveraged JobObjects internally to ensure that FastCGI processes are terminated when the worker process terminates. If we look at the implementation of the ASP .NET Core Module which we use for hosting ASP .NET Core Apps in IIS we can see what looks like a very similar usage of JobObjects.
It turns out that Microsoft added support for nested JobObjects in Windows 8 & Windows Server 2012 and above therefore we don't run into the same issues which we experienced with Windows 7 and Server 2008 r2 and below. Its simple enough for us to test, I setup a simple ASP .NET Core application and deployed it to a Windows Server 2016 machine on Azure. Before applying any limits we can take a look at the w3wp child process tree on the server with Process Explorer(If no worker process currently running issue at least one http request against your web application), we can see that there are 2 child processes under our w3wp worker process, we also see that there are Job limits applied to the dotnet.exe process which is hosting our .net core application - In this case it should be killed if the parent Job is closed.
To see if CPU limits are applied lets set a limit of 10% on the app pool, open IIS Manager->Application Pools->App Pool->Advanced Settings on the server. Leave the rest as default as we only want to inspect the Job limits for the process using Process Explorer.
After making the changes we can inspect the w3wp child process tree again in Process Explorer, what we can see is that the w3wp process now has a job tab which lists the Job limits for its nested Jobs, these limits are applied to this Job as well as all nested Jobs.
As we can see our CPU limits have been applied in the form of User CPU Limit and Job Time Limit.
With the upcoming ASP .NET Core 2.1 release we should also have the ability to host our applications in-process with IIS, see the following post on how to enable it for up to 4x the throughput.