When should application pools be turned into web gardens?Web gardens should only be used if the application doesn’t use in-process session variables but rather out-of-process ones (e.g. session state service or database session state). Reason is that a web garden would have at least 2 worker processes which do not share in-process (session) memory.
Drivers to using web gardens are:
- Application makes long-running synchronous requests
- Application is low in availability and crashes often
- Application creates high CPU load on worker process
Best Practices Systems Settings
- Optimum paging file size setting:
- 1.5x the RAM for 32-bit OS
- system-managed for 64-bit OS
- Disk queue length should always average less than 2
- Processor queue length should be less than the number of processors
- Network utilisation should be less than 50%
Application Isolation Policy
- Some applications should be deployed into their own application pool
- mission critical and should be highly available
- needs to be isolated for troubleshooting (e.g leaks memory)
- expected to incur high throughput/ load. putting undue stress on server resources
- has non-standard requirements (e.g. configuration)
Application Pool Settings
- Enable 32-bit Applications (WOW64) where necessary (e.g. when application uses 32-bit libraries)
- Always use Managed Pipeline Mode unless application runs into issues otherwise
- Increase Queue Length if required (especially if server hits error 503 – Service Unavailable)
- Run using Network Service as the Identity
- For HA requirement, disable Idle Timeout of the work process
- Disable Rapid Fail Protection for PRD environment
- For generating event log under the pool recycling settings, set all events to true
- Set to 0 minutes the recycling of the application pool at Regular Time Interval
IIS Configuration Settings
- Enable at least static compression
- Turn off directory browsing
Handling Session States
- Use InProc in standalone mode (where web farms are not used). This performs the best.
- Use StateServer (perferably on a different machine) to share session state in web farms. However, the performance penalty is 15% slower than InProc. A more serious consequence is that the StateServer would now be a single point of failure.
- Use SQLServer to share session state in web farms introduces 25% penalty over InProc. However, if set-up as a failover cluster, it will work reliably with HA.
- Use CustomProvider for other in-memory, distributed and equally reliable session replication. These tend to perform faster than SQLServer and almost equally fast as StateServer. Some popular providers are: Windows Server AppFabric, ScaleOut SessionServer, and memcached.
- The machineKey is used to encrypt and decrypt the following: ViewState, Forms authentication, out-of-process Session data.
- By default, the encryption and decryption keys are auto-generated by ASP.NET whenever the application pool restarts.
- For web farms, do ensure that the machineKey for all the servers in the web farm are configured to use the same values (esp. validationKey, decryptionKey). Auto-generation or inconsistent values would cause unnecessary issues.