Web-server – What does recycling the app pool actually do exactly

An app pool just serving up static content is less than 5Mb. Once you add the .NET framework then it will jump to over 10MB (it really varies on what is loaded). After that it's up to your application as to what it uses.

If you're wondering how much app pool overhead there is to put sites in their own app pools, it's really not much. There is the small bit of app pool overhead, and it does mean that your programming framework (i.e. asp.net) may have duplicate assemblies loaded into memory. That means that there may be as much as 15-20MB overhead per additional app pool. With memory so cheap, it's often worth it, although it can add up if you have a ton of sites.

I think that it is hard to recommend any schedule for recycling since that really depends on the business side, for example, is your site primarily US-based or is it globally accessed as well? In general I would recommend looking at your analytics and determine when its "safer" to perform the recycling.

In fact the reason IIS uses 29 hours as the default was to have more of a "sliding" time, since having a default of 24 would make it always recycle at the same time and depending on when the apppool start that could be your "top" customer time and then you would be stuck for that every day.

So really there is not a good answer other than determine for example that if your customer base tends to be low at 2:00 am then use that. And of course if you enable specific schedule, make sure that the recycling interval is set to 0.

Whatever you choose make sure you do not disable Overlapped recycling (the default) and that way the downtime is minimal since IIS will continue serving requests while getting the new AppPool ready. If you are using IIS 7.5 you could even use the Application Warmup feature (still in Beta) to warm up the apppool before it starts handling requests, that way you never have a "slow" response.