What changes when an IIS app pool uses multiple worker processes?

Question

Rajkumar Singh · Answer

Setting an IIS application pool to use more than one worker process creates a web garden. The less obvious change is that the processes are separate copies of the application, not one shared runtime.

That matters if the app keeps state in memory. In-process session state, static fields, singleton objects, and a process-local memory cache belong to whichever w3wp.exe handled the request. A later request may reach a different worker and see different values—or no session data at all. Shared or external storage is a safer fit when requests need consistent state.

Startup behavior changes too: each worker can run application startup code and create its own background tasks. A job started this way may run once per process rather than once per application, so scheduled work usually needs coordination or a separate job runner.

Multiple workers can provide process-level separation, but they also mean more memory use, more copies of caches and connections, and more moving parts when diagnosing a problem. Check logs and monitoring for the process ID; a symptom that appears intermittent may occur only in one worker.

A web garden is therefore worth testing with the app’s session, caching, and background-work assumptions—not just its request throughput. It is not automatically a substitute for fixing a bottleneck or scaling across servers.

Ravi Misra · Answer

Setting an IIS application pool’s Maximum Worker Processes above 1 creates a web garden: multiple w3wp.exe processes run the same application pool and handle requests for its apps. IIS can distribute incoming requests across those processes. That may help an application use more than one CPU core in some workloads, but it also means requests from the same user may be handled by different processes. What to watch for In-process state is separate in each worker. ASP.NET in-process session data and an application-level memory cache aren’t shared between processes. A later request may reach a different worker and not see data stored by the first. Use an out-of-process session store or shared cache when the app needs consistent state. Memory and startup work increase. Each worker has its own application instance, memory use, and initialization. Caches may be duplicated, and startup tasks may run once per process. Diagnostics can look different. Logs and counters may be split across worker processes, so include the process ID when investigating requests or performance. Recycling still happens. IIS can recycle workers, and overlapping recycles can briefly leave old and new processes running at the same time. Don’t assume process-local data will survive or be visible to another worker. A web garden is not the same as a web farm: it uses multiple workers on one server, not multiple servers. It’s worth testing with the application’s real session, cache, and startup behavior before increasing the worker count. If the app relies heavily on process-local state, one worker is often the simpler choice.

Hemant Patel · Answer

Setting an IIS application pool’s Maximum Worker Processes above 1 creates a web garden: multiple w3wp.exe processes serve applications in the same pool on the same server. IIS can distribute requests among those processes rather than sending everything to one. This is different from adding threads. A single worker process already handles concurrent requests using multiple threads and asynchronous I/O. Multiple processes introduce separate memory spaces and separate copies of your application’s runtime state. What changes for your application? In-memory state is no longer shared. Static variables, singletons, and an in-memory application cache exist independently in each process. Updating a value in one process does not update the others. In-process sessions become unreliable across requests. With classic ASP.NET InProc session state, a user’s next request can reach a process that does not have their session data. Use a suitable out-of-process session store instead. Do not assume that requests from the same browser always reach the same worker. Process-local locks are insufficient for shared work. A C# lock protects code only within that process. Coordinating database updates, file writes, or scheduled work across workers requires an appropriate cross-process mechanism, such as database transactions or distributed locking. Application resources are multiplied. Each worker has its own runtime, caches, and typically its own database connection pools. Memory use and the total number of backend connections can increase substantially. Startup and background work can run more than once. Initialization runs separately as each application instance starts. An in-app timer or scheduler may execute the same job in multiple workers unless you explicitly coordinate ownership. Does it improve performance? Sometimes, but it is not an automatic throughput improvement. Extra workers may help when a workload has a process-specific bottleneck. They will not fix a saturated database, and additional memory consumption or contention can make performance worse. Measure throughput, latency, CPU, memory, and backend connections under realistic load. You can change the setting under Application Pools → select the pool → Advanced Settings → Process Model → Maximum Worker Processes. The default is 1; keep it there unless testing demonstrates a benefit and the application supports multiple independent instances. One troubleshooting distinction: overlapped application pool recycling can temporarily leave an old and a replacement worker running even with the limit set to 1. Seeing two worker processes briefly does not necessarily mean a web garden is configured.

forum

What changes when an IIS app pool uses multiple worker processes?

Can you answer this question?

3 Answers

What to watch for

What changes for your application?

Does it improve performance?