This makes a good point in general: Don’t assume that because something has a cool-sounding name (e.g., “High Availability”) that you always want it. Failing over is great if you can actually get your servers back up quickly and if the application module instance is managing a critical transaction (such as the finalization of a purchase), but it’s a cost you should always consider for non-critical transactions, and it’s an entirely pointless cost if you’re servers won’t be back up before the user gives up and closes their browser.

Just one comment: if you’re deploying your ADF app in a High Availability configuration (i.e. “Failover Transaction State Upon Managed Release” is ticked) the state is written back to the database (default) on every page request. Strictly this is not a full passivation though, i.e. you won’t get a subsequent recycle/activation unless it would need to do that anyway for the number of concurrently active users.

Simon

Can’t thank you enough for organizing and sharing all the information related to Performance Tuning ADF applications.
Great Work !!

Thanks,
Husain