Summary:
I have an ASP.NET MVC website in IIS named 'Website' using an AppPool named 'WebsiteAppPool'. WebsiteAppPool is configured to allow up to 4 Worker Processes, in effect creating a 'Web Garden'. The Website is also configured, via web.config, to enable OutputCaching using CacheProfiles.
<caching>
<outputCacheSettings>
<outputCacheProfiles>
<clear />
<add name="ControllerNameActionName" duration="43200" varyByParam="*" />
</outputCacheProfiles>
</outputCacheSettings>
</caching>
My question is -
Will the AppPool's worker process' share the output cache or will each worker process have the Output Cache, therefore creating 4 cached copies across the AppPool.
Note:
My main concern is that this will debunk the benefits of having cached output and I would be better off having one WorkerProcess serving up the cached output rather than the 4.
There is no relation between the worker processes. They each have their own cache (as it is in-process cache). That said, if you make your application support the web-garden scenario (i.e. not depend on in-process state) it will be more robust and easier to scale up. It will be easier to add another server in the future and create a web-farm.
You might call YAGNI on that, but I think it is just common sense to create most web-applications in a way that supports scaling up. In your case, I really think it's OK to have 4 different caches, and having a web garden can actually improve your site's performance.
From MSDN:
Web gardens are especially screwy if you're doing in-process session state (which you hopefully aren't anyway). In my experience, I find that web gardens are rarely the benefit that people think they are.