--- title: "What changes when an IIS app pool uses multiple worker processes?" description: "What changes when an IIS app pool uses multiple worker processes?" author: "Kalin" published: 2026-10-06 updated: 2026-10-10 canonical: https://www.mindstick.com/forum/162245/what-changes-when-an-iis-app-pool-uses-multiple-worker-processes category: "Worker Process Management" tags: ["iis", "Web Garden", "Worker Processes"] reading_time: 6 minutes --- # What changes when an IIS app pool uses multiple worker processes? I came across the **Maximum Worker Processes** option while reviewing an IIS app pool. Raising it sounds like a straightforward way to use more CPU, but I’m concerned about how it affects application state. If a site keeps data in memory—such as a cache, a login session, or a background-task status—can requests land on different worker processes and see inconsistent values? Does IIS provide any affinity behavior here, or should an application using a web garden assume that every worker is independent? I’d appreciate real-world guidance on when multiple worker processes are worth considering, and what needs to be moved out of process first. ## Replies ### Reply by Rajkumar Singh 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. ### Reply by Ravi Misra 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. ### Reply by Hemant Patel 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. --- Original Source: https://www.mindstick.com/forum/162245/what-changes-when-an-iis-app-pool-uses-multiple-worker-processes Copyright © MindStick Software Pvt. Ltd. This Markdown version is provided for developers, AI systems, and offline reading.