Can IIS Handle Thousands of AppPools/Worker Processes?

0
votes

I am currently investigating the feasibility of an architecture where we will have potentially thousands of AppPools and therefore Worker Processes for each of our micro-services running in IIS (10+). (It is one of a few options)

I understand the overhead of each worker process. Currently my estimation would be that each worker is going to be about 20-30MB. Server resourcing should not be too much of an issue as we are likely going to be provisioning servers with 32-64GB of RAM. To add to this not all workers would be active at all times so we should gain headroom when AppPools are idle.

My question: Can IIS handle this many AppPools/Worker processes?

I don't see a reason it shouldn't given sufficient resources however have not been able to find any documentation around it after some brief searching.

1
iisarchitecturemicroservices

1 Answers

0
votes

So I'll add some answers to my own question here as I did a little bit of testing.

Server

  • Intel Xeon - X5550
  • 32GB Ram
  • Windows Server 2012 R2

Application

Created a barebones WebAPI only ASP.Net application with a single controller and action. When installed in IIS this is the observed memory footprint.

  • Memory (Idle) = ~ 5172 K
  • Memory (Running) = ~26 000 K

Prep

I created some powershell scripts (sorry can't share it as they leverage our closed source deployment scripts) to:

  • Create - Unique folder for each application to prevent possible resource sharing
  • Launch - Makes a web request
  • Cleanup - Deletes all applications, pools and folders
  • Recycle - Unloads the application, sets it back to Idle state

Test

Below are my results observed from PerfMon

Test Results

As you will note I could not get all 1000 running at once. I ran into a few things:

  • Trying to fire a call to all 1000 so they all running simultaneously is not as easy as it sounds.
  • ASP.Net temporary internet files is on the C:\ which ran out of space
  • Things began running slowly since memory was being paged.

Conclusion

It seems that IIS really has no limit on the number of processes. The core constraint is the resourcing on the machine.

What is interesting is it is unlikely all applications would be running simulationoesly and so one can take advantage of the fact that IIS will provision mem