As a Hoster, you definitely want to recycle on Memory & Time, potentially Request limits and CPU. You want to be pretty aggressive about these limits, but make sure you publish them to your clients.
Memory – 512 for an x86 box, maybe 768. For x64, you can set this much higher depending on the number of hosts per server. You just have to be careful and watch your app pool recycle events on memory issues.
Time – We typically recycle at 1 am in the morning, plus or minus (first site 1:01, second 1:11, third 1:21, just so you don’t have all recycling at the same time)
Request limit – 35,000 was the default for IIS6, but this number is quite arbitrary, and very dependant on the site in question. For small usage sites, the nightly recycle will hit long before you get 35k requests.
CPU – 95%/1 minute limit/KillW3WP, but use this carefully. My understanding of this is that if the CPU hits 95%+ over the 1 minute limit for this worker process, the worker process gets killed and is unable to restart for the remainder of the limit when Action is set to KillW3WP. You might want to try NoAction initially and just watch your event logs carefully.
Recycle Event Logs – You want to make sure you are logging app pool recycles for each event threshhold that you set – i.e. if you limit based off of requests limits, make sure that Request Limit logging is enabled.
One thing to remember is that you should set retail="true" in the <deployment> element in your machine.config:
<system.web>
<!--
<deployment
retail = "false" [true|false]
/>
-->
<deployment retail="true" />
</system.web>
Not setting this will allow a site to turn debugging on, which allows unlimited timeouts in requests – not exactly ideal for a hoster…