SharePoint Task Master: My Web Part Misses its Cache, and I Want to Help

Planning

This is typically where "good intentions" becomes a support nightmare.  Oftentimes I feel like I'm doing the right thing when I plan for capacity significantly greater than expected.  Of course this is usually within budget constraints and the product of a certain amount of common sense, however, the downfall comes when attempting to push the limits of a server to the maximum.  Common sense would say the best way to maximize a server's potential is to utilize memory and processor resources in parallel, thus, if I wanted to serve up pages from IIS as fast as possible I would need to remove bottlenecks and wait states to the greatest possible extent from a hardware perspective.  The plan is simple - run IIS processes in parallel while allowing each to use the most memory before recycling.  In theory, this approach will allow data to be stored in highly available RAM, allow multiple requests to be fulfilled at the same time, and each process will use my multiple processors more effectively.

Reality

While results vary (especially true on 32-bit platforms), the reflexive plan described above can actually cause more problems than it solves. Web Gardens cause situations where only one process can access the output cache and BLOB cache.  Content served up out of the other processes may be missing information, not retain session state properly, or show error messages.  We see this very well in SharePoint Task Master where we see the Cache Miss error, and Chart Plus where we see the Red 'X' instead of a nice chart. 

The recommendation is to use one worker process in each IIS Application Pool and do any of the following to increase capacity: divide webs into separate SharePoint Web Applications (which also has the benefit of allowing separate backups in the same way MOSS SSP benefits from having its own Web Application); increase the number of Web Front-End servers in an intelligent traffic-based load balanced configuration (which, yes, incurs additional cost, but is an overall better return on investment when also considering up-time and other factors); use x64 architecture with more RAM to minimize Application Pool recycling.  Multiple processor servers which are almost exclusively in use will still see the benefits as IIS worker processes spawn threads to complete tasks, and these threads will be load-balanced across the available processors.

Short version

Microsoft and others state pretty clearly that using a Web Garden for SharePoint is not recommended.  More RAM, x64 technology, and more servers are the best ways to serve up those pages as quickly and accurately as possible.  Some references that can be used are: Microsoft Technet, Eli Robillard's blog on asp.net, and the Joel Oleson blog referenced in the previous link.